The FatFs module is assuming following terms on portability.
AVR | H8/300H | PIC | TLCS-870/C | V850ES | SH2 | ARM7TDMI | x86 | |
---|---|---|---|---|---|---|---|---|
Compiler | WinAVR(gcc) | CH38 | C30(gcc) | CC870C | CA850 | SHC | WinARM(gcc) | VC6 |
_WORD_ACCESS | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 |
text (Full, R/W) | 12194 | 10559 | 10924 | 15229 | 7686 | 8727 | 10564 | 7342 |
text (Min, R/W) | 7988 | 6903 | 7108 | 9960 | 4884 | 5651 | 6544 | 4764 |
text (Full, R/O) | 5532 | 4753 | 5020 | 6760 | 3462 | 3777 | 4624 | 3316 |
text (Min, R/O) | 4040 | 3631 | 3736 | 5083 | 2556 | 2907 | 3284 | 2510 |
bss | D*2 + 2 | D*4 + 2 | D*2 + 2 | D*2 + 2 | D*4 + 2 | D*4 + 2 | D*4 + 2 | D*4 + 2 |
Work area (_FS_TINY == 0) | D*560 + F*544 | D*560 + F*550 | D*560 + F*544 | D*560 + F*550 | D*560 + F*550 | D*560 + F*550 | D*560 + F*550 | |
Work area (_FS_TINY == 1) | D*560 + F*32 | D*560 + F*36 | D*560 + F*32 | D*560 + F*32 | D*560 + F*36 | D*560 + F*36 | D*560 + F*36 | D*560 + F*36 |
These are the memory usage on some target systems with following condition. The memory sizes are in unit of byte, D means number of volumes and F means number of open files. All samples are optimezed in code size.
_FS_READONLY 0 (R/W), 1 (R/O) _FS_MINIMIZE 0 (Full function), 3 (Minimized function) _USE_STRFUNC 0 (Disable string functions) _USE_MKFS 0 (Disable f_mkfs function) _USE_FORWARD 0 (Disable f_forward function) _CODE_PAGE 932 (Japanese Shift-JIS) _USE_LFN 0 (Disable LFN) _LFN_UNICODE 0 (Disable Unicode API) _MAX_SS 512 (Single sector size) _FS_RPATH 0 (Disable relative path) _MULTI_PARTITION 0 (Single partition per drive) _FS_REENTRANT 0 (Disable reentrancy)
Follwing table shows which function is removed by configuration options for the module size reduction.
Function | _FS_MINIMIZE | _FS_READONLY | _USE_STRFUNC | _FS_RPATH | _USE_MKFS | _USE_FORWARD | ||
1 | 2 | 3 | 1 | 0 | 0 | 0 | 0 | |
f_mount | ||||||||
f_open | ||||||||
f_close | ||||||||
f_read | ||||||||
f_write | x | |||||||
f_sync | x | |||||||
f_lseek | x | |||||||
f_opendir | x | x | ||||||
f_readdir | x | x | ||||||
f_stat | x | x | x | |||||
f_getfree | x | x | x | x | ||||
f_truncate | x | x | x | x | ||||
f_unlink | x | x | x | x | ||||
f_mkdir | x | x | x | x | ||||
f_chmod | x | x | x | x | ||||
f_utime | x | x | x | x | ||||
f_rename | x | x | x | x | ||||
f_chdir | x | |||||||
f_chdrive | x | |||||||
f_mkfs | x | x | ||||||
f_forward | x | |||||||
f_putc | x | x | ||||||
f_puts | x | x | ||||||
f_printf | x | x | ||||||
f_gets | x |
The FatFs module supports long file name (LFN) from revision 0.07. The two different file names, SFN and LFN, of a file is transparent in the file functions except for f_readdir function. To enable LFN feature, set _USE_LFN to 1 or 2, and add a Unicode code conversion function ff_convert and ff_wtoupper to the project. This function is available in cc*.c. The LFN feature requiers a certain working buffer in addition. The buffer size can be configured by _MAX_LFN corresponding to the available memory size. The size of long file name will reach up to 255 characters so that the _MAX_LFN should be set to 255 for full featured LFN operation. When the size of working buffer is insufficient for the given file name, the file function will fail with FR_INVALID_NAME. When enable the LFN feature with re-entrant feature, _USE_LFN must be set to 2. In this case, the file funciton allocates the working buffer on the stack. The working buffer occupies (_MAX_LFN + 1) * 2 bytes so that the caller's stack must be a sufficient size considering the working buffer.
Code page | ROM size [bytes] |
---|---|
SBCS | +3721 |
932(Shift-JIS) | +62609 |
936(GBK) | +177797 |
949(Korean) | +139857 |
950(Big5) | +111497 |
When the LFN feature is enabled, the module size will be increased depends on the selected code page. Right table shows the difference in module size when LFN is enabled with some code pages. We are the Japanese, Chinese and Korean have tens of thousands of characters. Unfortunately, it requires a huge OEM-Unicode bidirectional conversion table and the module size will be drastically increased that shown in the table. As the result, the FatFs with LFN will not able to be implemented to most 8-bit microcontrollers including AVR. This is the reason why I had not been interested in implementing the LFN feature for a long time :-)
Note that the LFN feature on the FAT file system is a patent of Microsoft Corporation. When enable it on the commercial products, a license from Microsoft may be required depends on the final destination.
The file operations to the different volume can always work simultaneously regardless of re-entrancy setting. The re-entrancy to the same volume can be enabled with _FS_REENTRANT option. In this case, also the OS dependent synchronization object control functions, ff_cre_syncobj, ff_del_syncobj, ff_req_grant and ff_rel_grant must be added to the project. The sample code with documentation is available in syncobj.c.
When a file function is called while the volume is in use by any other task, the access is blocked until the task leaves file function. If wait time exceeded a period defined by _TIMEOUT, the file function will abort with FR_TIMEOUT. The timeout feature might not be supported on some RTOS.
There is an exception on f_mount and f_mkfs function. These functions are not re-entrant to the same volume. When use these functions, all other task must close the corresponding file on the volume and avoid to access the volume.
Note that this section describes on the re-entrancy of the FatFs module itself. There is no assumtion on the re-entrancy of low level disk I/O module.
FatFs module does not support the shareing controls of duplicated file access. It is permitted when open method to the file is only read mode. The duplicated open in write mode to a file is always prohibited and open file must not be renamed, deleted, otherwise the FAT structure on the volume can be collapted.
For good performance on reading/writing files on the small embedded system, application programmer should consider what process is done in the FatFs module. The file data on the disk is transferred in following sequence by f_read function.
Figure 1. Sector miss-aligned read (short)
Figure 2. Sector miss-aligned read (long)
Figure 3. Sector aligned read
The file I/O buffer means a sector buffer to read/write a partial data on the sector. The sector buffer is either file private sector buffer on each file object or shared sector buffer on the file system object. The buffer configuration option _FS_TINY determins which sector buffer is used for the file data transfer. When tiny buffer (1) is selected, data memory consumption is reduced 512 bytes each file object. In this case, FatFs module uses only a sector buffer on the file system object for file data transfer and FAT/directory access. The disadvantage of the tiny buffer configuration is: the FAT data cached in the sector buffer will be lost by file data transfer and it must be reloaded at every cluster boundary. However it will be suitable for most application from view point of the decent performance and low memory comsumption.
Figure 1 shows that partial sector data is transferred via the file I/O buffer. On long data transfer shown in Figure 2, middle of transfer data that covers one or more sector is transferred to application buffer directly. Figure 3 shows that the case of entier transfer data is aligned to the sector boundary. In this case, file I/O buffer is not used. On the direct transfer, the maximum extent of sectors are read with disk_read function at a time but the multi sector transfer never across the cluster boundary even if it is contiguous.
Therefore taking effort to sector aligned read/write accesss avoids buffered data transfer and the read/write performance will be improved. Besides the effect, cached FAT data will not be flushed by file data transfer on the tiny configuration so that it can achieve same performance as non tiny configuration with small memory footprint.
When write operation to the FAT file system is interrupted due to any accidental failure, such as sudden blackout, incorrect disk removal and unrecoverable disk error, the FAT structure can be collapted. Following images shows the critical section on the FatFs application.
An interruption in the red section can cause a cross link; as a result, the file/directory being changed may be lost. There is one or more possibility listed below when an interruption in the yellow section is occured.
Each case does not affect the files that not in write mode open. To minimize risk of data loss, the critical section can be minimized like shown in Figure 5 by minimizing the time that file is opened in write mode or using f_sync function properly.
FatFs supports OEM code set on the API in default but FatFs can also switch the code set to Unicode. For more information, refer to the description in the file name.