Dumb FAT questions
You’re questions aren’t dumb at all!
I think that the properties of FreeRTOS+FAT are quite comparable with Chan’s FatFs.
FreeRTOS+FAT: the sources are set-up in clear modules, and the source is easy to understand and easy to debug: errors are encoded in a 32-bit value that contains module/function/errno.
It has an interface which is 100% compatible with the standard stdio.h, except for the ff_ prefix:
FF_FILE *ff_fopen( const char *pcFile, const char *pcMode );
size_t ff_fread( void *pvBuffer, size_t xSize, size_t xItems, FF_FILE * pxStream );
size_t ff_fwrite( const void *pvBuffer, size_t xSize, size_t xItems, FF_FILE * pxStream );
int ff_fclose( FF_FILE *pxStream );
It also handles multiple volumes, e.g. an SD-card, a USB drive, plus a RAM disk can all be mounted and mapped onto the root directory:
/usb/film.mp4 <= USB stick
/ram/init.h <= RAM disk
/websrc/favicon.ico <= SD-card, default volume
So there is no driver number like in FatFS ( e.g. "2:/init.rc" ), and it does support relative file and directory names ( "../etc/network" )
The volume label is set during formatting, and read while mounting, although it needs a small change.
Adding setVolumeLabel()/getVolumeLabel() would be an easy thing to do.
It does not (yet) support exFAT, for files longer than 64GB. It does support drives larger than 64 GB though, see e.g. the Xilinx Zynq project.
When using FreeRTOS+FAT, you don’t have to worry about flushing data. All is flushed at the moment a file is closed, or when it needs free sector buffers.
If you want earlier, forced flushes, the function FF_FlushCache() can be called.
It also supports Long File Name in ANSI/OEM or Unicode. It has many optimisations, like special caching for directory paths, and hash tables for long directories.
FreeRTOS+TCP is thread-safe using FreeRTOS mutexes, but it can be ported to a different OS ( see ff_locking.c ).