On Fri, Jan 23, 2004 at 04:43:04PM +0100, Georg Ritter wrote:
> Hello,
>
> I'm aware of the wearing problem of FAT and I don't think it's very
> suitable format at all nor for data logging - that is what I want to do.
For compatibility I think using FAT is the best compromise. Unburden your
users the headache installing romfs in winxp, our some special software to
access the MMC at low level (maybe forbidden for non admin users) ;-). Very
shrinked FAT routines can be used. You have one always present 8.3 file in
the root directory for the logging data. The routines just have to search
the root directory, then search that file in the root directory, and then
get the start of the FAT chain. Now data can be written to the free clusters
adressed by the FAT. Its easy to find new free clusters and mark them used.
After finishing the directory entry have to be updated. I think this needs
only some bytes in Ram and some kbytes Rom. I hope buffering of one complete
512 bytes sector is not necessary. Just write the data as slow as they
arrive (serial - with increasing adresses) into the MMC (I hope the MMC does
not have any timeout!?). Well to modifying one sector (the FAT or directory
entry) you need the 512 buffer ;-(. To avoid this, the space of the file
should already be allocated. This would also reduce code size (writing to the
FAT and the directory not necessary).
As far as I know M$ only want money for FAT32, and in some years the patents
for fat32 are outdated. In the meantime using FAT16 should be sufficient.
The application software at PC side have to do:
- format the mmc with FAT16 (umhh what was the max drive size for FAT16?)
- create one large file data.abc filled with FF in the root directory
Matthias
