I am doing a project that could make use of an SD card to read images and sound files. These files are already in a format needed for my routines, and were created by custom software I wrote on the PC.
So I was reading over plenty of SD and FFS tutorials, and it seems that there are a lot of gotchas when using FFS and MMC. A lot of complaints about certain cards not working, and issues between FAT16 or FAT32, long or short file names, and then just the bulk of the code itself.
So I had an idea, which I will probably try no matter how crazy it sounds, but I thought I would get the opinions of fellow Freaks. My idea is this...
Since I am only wanting to read data, and I have total control over the data format (from my PC BMP/WAVE file converter), why use FAT at all? I could just put an ID string at the beginning of my file like "ATOMICZ" and then write a DWORD right after containing the length of this file in bytes and then then name as a fixed length string.
I could drop those files on the SD card through windoze and then my AVR could start at sector 0, looking for the ID of the first file. Once it finds the first file (whatever it may be), it can then return the filename. If it's not the file I want, then the length is read and then that many bytes are skipped. Then the next file is found and checked until I have the name of the file I want.
This may seem cumbersome, but in reality, once a "wrong" file is found, the AVR can skip to the next one right away based on the known size of that file. Even with 1000 files, it wouldn't be all that bad.
The benefits to this (as I see them)...
- No bulky and complex FFS library needed
- Use FAT12,16,32 or whatever from your PC
- Use any size SD card from any manufacturer
- Zero pain - always works no matter what
So my plan is basically to "embed" the file structure in each file and then sequentially read / skip until I have the file I want. On the PC side, everything seems normal to Mister Gates and his file system.
Besides the SD init code, there would not be much else to the routines. This method should be super lightweight and ultra fast. Assuming FLCK/2 (say 10MHZ) and a serial stream of 8 bits, this method should be able to reach 1MB/Sec?
Ok, now chime in and let me know why this won't work before I begin a late night of assembly coding fun!