DOS/Win Compatible FAT File Systems
What are the typical ROM requirements of the TargetFAT file system?
The size of the TargetFAT library is 81K.
What are the typical RAM requirements of the TargetFAT file system?
TargetFAT's RAM footprint includes two arrays whose size is determined at compile-time. The Files Array holds the file control blocks used by open files and is shared by all TargetOS file systems (TargetFFS, TargetRFS, etc.) present in the build. Its size in bytes is:
(FOPEN_MAX + 1) * sizeof(FILE) = (FOPEN_MAX + 1) * (64 + FILENAME_MAX)
The FatGlob Array has one entry for each volume that may be added to TargetFAT. Its size in
NUM_FAT_VOLS * sizeof(FatGlob) = NUM_FAT_VOLS * (244 + FILENAME_MAX)
The above symbols are defined in "posix.h". The effective size of FILENAME_MAX is rounded
up to a multiple of 4 bytes.
TargetFAT also allocates memory at run-time. The Fat->num_clusts and Fat->sects_per_fat
values used below are only determined when a volume is mounted. Their values can be read
via the vstat() call. The notation "Fat->" represents a pointer to a specific volume's FatGlob entry.
Does the TargetFAT file system support SD cards?
Yes. Numerous customers around the world are using TargetFAT with SD cards on cell phones and other platforms.
Have you done any benchmarks on the file system for reading and writing to SD cards?
Benchmarks are meaningless unless done on relevant hardware. Blunk provides the full TargetFAT source code for 30-day evaluations, after signing of our simple eval agreement, so
that you can perform benchmarks on your own hardware.
What SD Card modes does the TargetFAT file system support (1-bit, 4-bit, SPI, etc.)?
The SD card mode is not visible to TargetFAT. The TargetFAT driver interface, documented in Chapter 4 of the user's manual, is basically a write_sectors()/read_sectors() interface. All SD card dependencies are handled in the driver layer.
Is the TargetFAT file system designed to run on specific targets? If so, which ones?
All of our system software is designed for 32-bit processors, not 8 or 16. TargetFAT is currently being used on a variety of 32-bit processors, including ARM, ColdFire, and Power Architecture.
Does the TargetFAT file system include routines to support RAM drives?
TargetFAT is shipped with a RAM driver that allows you to verify and test your file system integration before addressing the driver layer. Also, with each of our file system products, we include a RAM based file system, TargetRFS, that calls malloc() and free()
as files are created/grown or deleted.
The first option (RAM driver) gives you a fixed-size footprint for the RAM volume you create. The second option (TargetRFS) starts with a 0 footprint that grows/shrinks according to your application use. Depending on your requirements, one may be preferable over the other.
Robustness of the FAT file system (power down, hot (un)plug of a flash card) is becoming important for us. Your documentation states "Robust, performs automatic power-fail recovery during mount." What exactly does you implementation guarantee? For instance, does it guarantee that directory entries and FATs are consistent?
TargetFAT implementation does guarantee that directory and FAT entries are consistent. We use two FAT tables to achieve this. One is always in a consistent state, the other is the active one. Much like TargetFFS, there are sync points at which the two FAT tables are synced up. After a sync, both tables are in consistent state. We keep track of whether a FAT
table is in a consistent state or not in a standard way - flipping the MSB of the first FAT entry in the table. At any one point, one of the FAT tables is guaranteed to be in a consistent state.
Upon power up, if either of the two FAT tables is not in a consistent state, an automatic power fail recovery for FAT is triggered. This consists of always reverting to the consistent FAT table and also performing a full volume scan to ensure directory entries' consistency as well. As you can imagine, depending on the size/contents of the volume, this is a much longer operation than its FFS equivalent. However, the end result should be the same: the file system is in a consistent state. The only data lost would be the one that was modified since the last sync point.
This recovery mechanism works only if the interrupted FAT volume hasn't been modified outside TargetFAT after the interruption point but before the power fail recovery algorithm has a chance to run.
Have you ported to other OSs?
We have our own RTOS, TargetOS. We keep the code strict ANSI and provide a porting guide that makes it simple to bring up TargetFAT with any RTOS. TargetFAT has been ported other RTOSs, including pSOS/Nexperia.
How is your product licensing structured?
Standard license for TargetFAT is a Platform License. A Platform License comes with full source code and one year of technical support. This license also allows release of derived executable code on a specified product, and distribution is without royalty.