Developer page about implementing the FAT filesystem or some alternative
FAT alternatives
Raw device
It is possible to log without FAT implementation, or with a lightweight readonly FAT16. Readonly means it is not able to create new files, but it is still able to tell the block position of files (and therefore write to any file preallocated on the MMC on PC. RAM requirement for full FAT is high, estimated 600..1000 bytes (even that is possible).
Pros of filesystem:
- the same card can be efficiently shared with other uses, like a digital camera, mp3 storage or transportation of files
Cons:
- burns SRAM (which there is still plenty free of) for the location of next blocks in the file, also some CPU
Alternative is just support writing to the Nth (1..4) partition, that should be fine. It means that the partition used for logging cannot be used for storing photos, mp3-s at the same time. But who cares? Many motec has just 1 Mbyte for logging, so wether one uses 30% or 100% of a cheap 256Mbyte MMC for logging VEMS runtime data, he'll be satisfied.
Reading raw data is no problem on quality OS-es. A partition on a device can be directly written to. It can simply be read on linux.
Most likely works on win32 too (in the worst case a big file is created on the empty device that spans the whole device).
Other filesystems
Tiny OS has a simple file system for Atmel AT45DB041 serial flash (MMC can be max a buffering harder). (Simply byte-)Logger and FS are both useful in writing data to the flash.
FAT16 implementations
Important note: surprisingly, read-only FAT filesystem works for logging: even an ro interface must be able to find out the location of Nth (or next) block of file "xxx". Read-only means it cannot allocate new dirs/files/blocks. But it's not hard to create 1 or 2 files beforehand. Definitely, we want to store the start of sessions in a way that is easy to find without reading through 200Mbytes of data: separate file, or special purpose area at the file beginning.
- http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2000/peterdan/final.htm an mp3 project: note the added parallel-port MMC programmer too
- http://ccrma.stanford.edu/courses/250a/docs/avrlib/files.html
- http://hubbard.engr.scu.edu/embedded/avr/avrlib/ read-only
- http://www.mcselec.com/avr-dos.htm Should we order the 99 Euro licence from ? Jason, maybe you could order from the VEMs paypal account if you aggree. I think it's >30% that we'll use it (from C, of course).
- http://www.prllc.com/prllc_homemainFlash.htm These guys have a C library which handles MMC/SD and FAT 12/16. Looks almost ideal to me, the only downsides are the licensing (single user for sourcecode) and it's not built for GCC "out of the box". Still, there's no reason the objects can't be precompiled and linked, and PRLLC says their code can be ported. The functions themselves are defined in their published docs, so if we added appropriate #ifdef MMC or similar, we could make that work. Cost for the sourcecode package is $139 USD.
- [an LPC ARM] uc with FAT licence. Not sure when it is useful: integration with this costs almost as much as integrating FAT code from somewhere else. Seems to use LPC2219 processor (maybe else, but LPC22.. for sure)
- Yampp MP3 player
- FAT, long filenames:
See also