SD Card FAT support issues (dosfs, fatfs,fatlib)

Peter Dickerson · 2006-09-05T09:38:32+00:00

OK, firstly I should say that I'm aware there has been recent discussion ofembedded FAT here. I have looked at Lewin Edwards' DOSFS 1.01, FatFS R0.02aand Sham's Fatlib v2.0.I have an ARM7 based instrument that already is in production but would liketo a support for external memory cards to store measurement data andconfiguration. The system only has 128K RAM and 4 MByte Flash internally(plus 32K RAM in the CPU). Much of the RAM is used but can probably find afew K, maybe 6K. There is already a file system in part of the Flash thatcan store 'files' - about 2.5 MB, the rest of the flash is the code imagethat runs directly. The file system is a simple one of my own design.Now, it would be nice if could optionally use a SD card to store this data,or at least be able to backup and restore from it. To do this though I wouldneed to map the SD Card FAT system to match my API or at least pull the twotoward each other. I suspect that I use too much functionality though. I canopen, read, write and seek in files. I can create, delete and rename files &directories (including moving in the tree), also inumerate directories.There is a current working directory. File names are up to 31 characters,including spaces and upper and lower case - but not Unicode.First problem. None of the three FAT modules above support long file names.So, the first question is how easy might this be to add, or is there codeout there code available that can do this.Next, Fatlib seems to be far to limited. The API allows opening files,reading and writing. No enumeration, delete, rename etc. So I have discardedthis for now.Next, DOSFS has much more - enumerate directories, seek, delete,multi-volume, but no rename (though I suspect that should be to hard to addat least for in situ). However, the first test I tried was to build theemulation that uses a disk image but this produced an error. I created thedirectory MYDIR1 required for the test on the real card before taking theimage. Before the test the...

Sep 05, 2006 41 Replies

Rate this thread:

David Brown 19 years ago

Just to balance the bias here, that kind of problem occurs with *all* types of licences. The only difference is that with open source, it is harder to hide - with closed source development, you can cheat more easily.

Vote

Peter Dickerson 19 years ago

code

May, may not. One side does not fit all. The solution, if it does, is to not modify the code, or not use it.

easily.

I agree that this has nothing to do with open source. In the embedded world nobody outside the development group ever sees the software as software but as a board or a component or a product. If you want to cheat, use open source outside its license terms or reuse code written for a previous employer, you can probably hide the fact easily. Both are bad. If you don't like the terms, don't use it.

Peter

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required