I used about 1.4K RAM and 10K ROM. My goal was to design a very low power flash disk using standard UART, SPI and I2C interface. The disk should use simple commands, such as "OpenFile", "SendData", "SaveData" to log data or to communicate with its host. Therefore, measurement tools like multimeter can use the disk with minimum changes in their S/W and minimum effect on battery life.
The following functions/features have been achieved: 0.)Identify card, existing file system and essential card parameters 1.)Create new folder (limited to one level only) 2.)Change into a folder (limited to one level only) 3.)Create new file (in both root and subdirectories) 4.)Open file to read 5.)Open file to write (for both new and existing file) 6.)Save file (limit: file size is calculated as "sectors x bytes/sector", not exact number of bytes) 7.)Check and expand cluster 8.)Get next cluster for reading 9.)Get new cluster for writing 10.)Format disk (FAT16 only) 11.)Delete file 12.)List files in a folder 13.)Search file (limited in root and the 1st level subdirectory only) 14.)Very low power: less than 3.3v...@100ua MCU+CF Card for idle, about 30-75mA(64MB-1GB) for R/W. LIMITS ON USER'S ASPECT: 0.)Level of subdirectories: 1 1.)Use 8.3 format for folder/file name only 2.)Do not accept low case folder/filename 3.)Read/write 512 bytes a time (2-10 milliseconds apart depending on speed) 4.)Support one file only with MSP430F148 5.)Maximum supported CF disk: 2GB for efficient use of media IMPLEMENTATION Draw back: Low speed and more read/write operations but can be improved. For example, you can allocate more clusters a time if you know there will be more data coming to save folds of time to update FATs. If you do concern the wearing issue, for most CF Cards the offset for the FAT16 volume is about 32 or larger, which means you have the potential to move your FATs to the offset area. Advantage: very small footprint. Portable for ohter platforms. My tip: 1.)RAM usage: Allocate one 512 bytes for data exclusively. Another 512 bytes for maintaining the FAT16 file system, such as search volume, updating FATs and file entries and so on(that is the draw back, you have to do one sector a time!). Other general uses include buffer dsk parameters, file structure(s) ... 2.)ROM usage: non-specific. The reason I chose the MSP430F device is low power, good number of registers and excellent free tools. 3.)The more RAM space, the better performance and can do more files simultaneously. My message is a little long, sorry for that. Also please understand I can't release the code at least for now. Thanks, Hecheng Hu ----- Original Message ----- From: "Stokes, Mark" <[email protected]> To: [email protected] Subject: RE: [Mspgcc-users] Re: Compact Flash interface Date: Thu, 14 Apr 2005 09:04:14 -0400 > > I'm not sure what opportunity you have had in FAT16 implementing, > but I have seen a > couple of implementations and none were less than about 30k ROM > space not to mention the > RAM requirements. While 30k is not that big, it's huge when you > consider the entire ROM > I'm using is the largest available (80k), you can't easily have an > external RAM, and my > code already sits at ~44k. If all I was doing was an MP3 player so > similar, then fine, > but most embedded systems have the card as a secondary function to > some very large > primary embedded function. > > Please, let us know the implementations you are speaking of. > One last problem with FAT16 is the constant writing/re-writing to > the FAT area, thereby > "wearing out" the bytes near the beginning. I realize the card automatically > compensates for this w/ "extra" bytes at the end of the card, but > those will eventually > run out also. > > -Mark > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of N. Coesel > Sent: Thursday, April 14, 2005 2:58 AM > To: [email protected] > Subject: Re: [Mspgcc-users] Re: Compact Flash interface > > At 15:17 13-04-05 -0500, you wrote: > > Stokes, Mark wrote: > >> What about releasing the code for the FAT16? This has been a discussion > here and for > >> the most part space limits the ability to maintain a working FAT16. > One suggestion was > >> to format the card and place one file on the card that is the same size > as the card. > >> Then, save the card as an ISO image. Once the starting location for > that file is > >> determined, the embedded system can then begin writing to that location > with out knowing > >> about (or worrying with) the actual file system. There are obvious > drawbacks to this. > >> > >> Thanks! > >> -Mark Stokes > >> > > romfs is a lot simpler. google romfs > > Garst > > > > FAT16 is not so difficult to implement and shouldn't take much memory either. > > Nico Coesel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
