I've got DSP tms320vc5509a and NOR flash AT26DF321 on the board and I'm going to store named data on the flash. I don't need directory hierarchy, wear leveling (I hope system will write to flash very few times), but CRC is strongly needed. Thank you
views:
79answers:
2You could look at the ELM-Petit FAT File System Module for an good small file system implementation. Not sure that it has CRC but you can add that to your low-level hardware drivers.
On a NOR flash, especially one that also contains my boot code and application, I generally avoid the overhead of a formal file system. Instead, I store each "interesting" object starting at an erase block boundary, and beginning with a header structure that at minimum holds the object size and a checksum. Adding a name or resource ID to the header is a natural extension.
The boot loader looks for a valid application by verifying the checksum before using the block. Similarly, other resources can be confirmed to be valid before use.
It also makes it easy for a firmware update utility to validate the object before erasing and programming it to the FLASH.
A pool of small resources might be best handled by wrapping it in a container for flashing. If the runtime resources support it, I would be tempted to use ZIP to wrap the files, wrapping the image of the ZIP archive in a size and checksum header and storing it at an erase block boundary. If you can't afford the decompression runtime, it is still possible to use ZIP with uncompressed files, or to use a simpler format such as tar.
Naturally, the situation is very different for a NAND flash. There, I would strongly recommend picking an established (commercial or open source) filesystem designed for the quirks of NAND flash.