The FAT and THIN file systems were designed for very different target environments.
FAT is a feature rich high performance FAT file system – and even though it is a complete solution its resource requirements remain reasonable.
THIN on the other hand was designed with limited resource microcontrollers in mind. Typically those with a few Ks or less of RAM and little ROM. Crafting code to work efficiently in such environments mean that sacrifices are made – you still cannot get something for nothing!
This table summarizes the main functional differences and similarities between the two systems:
|
Property
|
THIN
|
FAT
|
|
Code Size |
5K-20K
|
25-35K
|
|
Ram Size |
<1K minimum |
3K Minimum 10-20K gives good performance |
|
API
|
Full standard |
Full Standard |
|
RTOS Support |
Yes
|
Yes |
|
Supported Media |
Only devices with 512 Byte sector size: SD cards, CF cards and most USB Pendrives. |
All FAT compatible Media |
|
Sample Drivers Included |
SD, SDHC, CF, MST |
SD, SDHC, MST,CF, HDD |
|
FAT12
|
Yes
|
Yes
|
|
FAT16
|
Yes
|
Yes
|
|
FAT32
|
Yes
|
Yes
|
|
Media Error Handling |
No
|
Yes
|
|
Long Filenames |
Yes |
Yes
|
|
Unicode
|
No |
Yes
|
|
Caching Options |
No |
Yes
|
|
Fast Cluster Search |
Yes (requires more RAM) |
Yes
|
|
Directories
|
Yes
|
Yes
|
|
Multiple Volumes |
No |
Yes
|
|
Multiple Users |
Yes
|
Yes
|
|
Dynamic read update while writing |
No
|
Yes
|
|
ANSI C |
Yes
|
Yes
|
|
Microcontroller Independent |
Yes
|
Yes
|
|
Proven on DSPs |
Yes
|
Yes
|
|
Test Suite |
Yes
|
Yes
|
|
Comprehensive User Guide |
Yes
|
Yes
|
The TINY and SafeFLASH file systems were designed for very different target environments.
SafeFLASH was designed from the ground up as a completely failsafe file system which will work with just about any flash device.
TINY was designed with the idea that certain limited resource microcontroller systems would benefit from being able to use a failsafe file system – and this would be possible within certain design constraints – the primary design constraint is that it only works with flash which has small erasable sectors. This constraint means that the system can be designed without any regard to fragmentation issues and as a result can work with a tiny resource requirement.
This table summarizes the main functional differences and similarities between the two systems:
|
Property |
TINY |
SafeFLASH |
|
Code Size |
< 10K |
25-40K |
|
Ram Size |
<1K minimum |
Flash dependent From 10K to 1MB |
|
API |
Full standard |
Full Standard |
|
RTOS Support |
Yes |
Yes |
|
Flash Types Supported |
Only flash devices with small erasable sectors are supported, Typically <2K. |
All NOR, NAND and serial flash types. Can also be used on other media types |
|
Failsafe |
Yes |
Yes |
|
Error Recovery |
No |
Yes |
|
Long Filenames |
Partial |
Yes |
|
Unicode |
No |
Yes |
|
Directories |
Yes |
Yes |
|
Multiple Volumes |
No |
Yes |
|
Multiple Users |
No |
Yes |
|
Dynamic read update while writing (1) |
No |
Yes |
|
CRC on Files (2) |
No |
Yes |
|
ANSI C |
Yes |
Yes |
|
Microcontroller Independent |
Yes |
Yes |
|
Proven on DSPs |
No |
Yes |
|
Test Suite |
Yes |
Yes |
|
Comprehensive User Guide |
Yes |
Yes |
(1) This feature means that if a user has a file open for read and another for write then when some data is appended to the file the user who has the file open for read can access the new data.
(2) This is an optional feature which allows all files to have their own checksum.
File systems are very useful in many embedded systems designs - but the problem is how to ensure that it is reliable.
The most commonly used file system on embedded targets is FAT - however, this system is not failsafe which means that if the system crashes unexpectedly, or power is lost, parts or all of the system can be left in an unpredictable state. There are many other embedded file systems on the market offering degrees of reliability though few that are genuinely designed and tested to handle unexpected reset cleanly. Since on most embedded designs there is no possibility for a user to run a checkdisk program, and make corrections as required, the system is effectively lost.
In our view this is unacceptable in an embedded design. This is why we developed our SafeFLASH and TINY file systems to give embedded developers a much higher level of product reliability.
There are a few times when you must accept a non-failsafe file system - for example if you want your file system to be recognized over USB Mass Storage - but if the option is available we strongly recommend using a genuinely failsafe design.
Standard FAT file system implementations have a number of weaknesses which mean that if the system is reset unexpectedly then the file system may suffer corruption. To give a few examples:
1. when a file is modified its directory entry containing its length field is in a different location to the data being written – one operation must be done first (for performance reasons this is normally the data) and so if power is lost then the file length field will not be consistent with amount of data and the number of clusters in the files’ cluster chain.
2. a directory entry may span a sector boundary (with long filenames) and so if one sector is written and the other is not then an inconsistency can arise and some of the directory entries cannot be used anymore.
3. when you seek into a file and modify data the normal FAT process overwrites the existing data – so if the system resets then parts of the file maybe modified before a new consistent image has been built. Additionally there is no way to return to the original data.
4. If a directory entry (can be either file or directory) is deleted then either the attached chain must be removed first or the entry itself must be removed first. With an unexpected reset in the first case there may be a directory entry pointing to a cluster chain which does not exist, or in the second case there may be a cluster chain with no reference to it resulting in lost clusters.
5. Deleting a cluster chain is problematical since there are no backward pointers on a cluster chain. There are two options – you can delete from the beginning to the end – in which case unexpected power loss will result in lost chains or you can delete from the end which is very inefficient on large files because there are no back pointers. Again lost cluster chains may result.
There are many more issues with conventional FAT implementations – this is to give a flavor of the issues involved. The current answer to this is checkdisk or another special utility to run – which can correct some of these problems with user intervention – but it is not certain (can never be sure which the last byte written to a file was for instance – or restore overwritten data) – and is also not normally a practical option for an embedded system.
All HCC's SafeFLASH file systems handle these situations cleanly and efficiently.
This text is our view of the situation and should be used for guidance only. In all cases you should contact your lawyers to understand the issues. We are sorry - we did not design the system.
In both the FAT and THIN products we have a definition which allows the developer to enable the use of long filenames. If this is enabled, according to Microsoft, you are required to buy a license from them to use the long filenames. As we understand it there is an initial charge for the right to their technology plus a per unit royalty (0.25c in volume?) to a maximum of 250K USD.
HCC have discussed this issue with Microsoft and, on request, can supply our customers with the necessary legal contact in Microsoft to follow this through.