Porting of the Fatfs file system

Because of the need, and do not want to write their own, so the transplant a file system.

Next to my hardware and development tools: TRUE IDE mode CF card (that is, the equivalent of a hard disk), Samsung s3c2440 ARM9, development tools are very old and very old D version of the ADS1.2.

I see on-line embedded system above commonly used file system has ucosii company's uc/fs, support CF card, hard disk, SD/MMC card, and NAND flash and so on, more, but commercial, need silver, have ucos for teaching use (why say is used for teaching, hehe , and so on the ZLG/FS, also found open source, free two, one of which is called EFSL, the other is called Fatfs.

Now let's not consider the issue of copyright, choose a more appropriate file system. The first uc/fs file system has nothing to say, ucosii that company developed, stability, compatibility should not be poor. The second one is zlg/fs. Ucos a lot of the development boards above have sent this file system source code, found on the Internet a ready-made read and write hard disk, but is based on the LPC2200 series of processors. The third is EFSL, is an open source project, free, only need to provide read sector and write sector 2 functions. The fourth one is fatfs, like EFSL, is also an open source project, porting more than EFSL a few simple functions.

Here to add a simple CF card and hard disk data, CF card has three modes, one of which is called true IDE, after this mode, and the same as his pattern name, he is a hard disk, read and write to him, it is equivalent to a hard disk to read and write. When the pin OE (as if it is called OE, the specific CF card document) is detected when power up, then the CF card enters True IDE mode. When reading and writing the hard disk, in the case of only write once LBA, only send a command (read or write), can read or write 256 sectors (of course, you can read a sector, read or write how many sectors in the sector counter count), where, send a read or write commands, Read or write 256 sectors required time, the score 256 times to read and write these sectors need to be much shorter, more efficient, I now need is a read and write faster, more efficient file system, so the underlying read and write sector must be written every command can read and write multiple sectors, The function of the read-write sector must have a sector counter (the preceding count) to be able to satisfy the requirement.

Uc/fs also in the online search a code, looked under, very standard several layers, what hardware layer, file system layer, API layer, and so on (see Uc/fs document), with Ucosii a company's, stability should be good, need to provide function is read sector, write sector and so on several. However, the underlying read-write sector function does not need to provide a sector counter count this parameter, that is, the file system can not write only one read or write commands, read or write multiple sectors, the effect of a good sense of a file system, the efficiency is greatly reduced.

And then looked at the next Efls. This file system, open source projects, free projects, good things, porting is also very simple, the same time the transplant also provides read and write sectors, such as a number of functions, but faced with uc/fs the same problem, each read and write can only read and write a sector.

Desperate to see the Ucos file system, probably looked under (not carefully read the source code), the hardware driver can read the command in the case, read and write multiple sectors, and feel relatively simple, the same, the level is also very clear, the transplant needs to do is to modify the following read and write sectors and so on several functions. So he started to dry. Kung Fu not negative painstaking people, after a few days, CF card can read and write, get the computer above read the data, no problem. From the CF card read the file out, print to HyperTerminal, there is no problem, thought on everything OK, think of the next, we need, the most concerned about, the first is the speed, and then began to test the speed, accidents do not know, a test scare jump. Too "fast", TMD, just 5, 6 K Bytes per second .... (My driver has been tested, on M bytes per second) so trace to write inside, found a very, very, very serious problem: ZLG/FS provides a read a byte function, forget what is called, here temporarily called readonebyte (* * *), and then read multiple bytes, or the function of reading chunks of bytes is what, hehe,

For (I=0;i < N; i++) Readonebyte (* * *), this mechanism, not slow only strange ... So sad abandoned zlg/fs, this east, study or can, commercial words, poor too far ...

My stuff, file system can not, but must have a file storage protocol, or called their own file system, write a simple storage protocol, tried, very troublesome. But if the file system, write their own words, write to tired people, write out not necessarily high efficiency, speed is fast, so, or in the online search for no purpose, feel that there should be a high efficiency of the file system.

Or that sentence, Kung Fu does not bear the painstaking people, finally let me find, that is now used, FatFs, open source, free, efficient. (say some of the file system here a drawback, due to Microsoft's Fat copyright issue, FATFS,ZLG/FS,EFSL only support DOS 8.3 file name, that is, 8-byte file name, a ".", and then 3-byte extension, I found that the uc/fs is not supported, Do not know in the updated version of the support is not, see which day is free, to change that fatfs, let him support, hehe). The bottom of the FatFs can write commands once, read and write multiple sectors. Fatfs design of reading and writing ideas is very good, small pieces of data, I went through the buffer to store, large chunks of data, I directly access, that speed, a lot more efficient, look at the picture:

The structure of the Fatfs file system is also very clear, also look at the picture:

To add, the author of FatFs wrote two, one is the authentic FatFs, more suitable for large RAM devices, the other is fatfs/tiny, more suitable for small RAM systems, such as single-chip microcomputer, fatfs/tiny occupy smaller RAM, The cost is slower read and write speeds and fewer API functions. However, all two support the Fat12,fat16,fat32 file system.

Download down the Fatfs Fatfs there are two folders, one is doc, fatfs description, including features, system functions, as well as some possible problems, the other is the source code folder SRC, a total of 8 files, DISKIO.C and diskio.h are hardware layers, FF.C and ff.h are Fatfs's file system layer and the FileSystem's API layer, INTEGER.H is the definition of the data type used by the file system, TFF.C and tff.h are tiny's file system layer and the file system API layer, and a 00re Adme.txt a brief introduction to the Fatfshe Fatfs/tiny, including the APIs they support, how to configure, and so on.

Porting problem, the first is the data type, in the Integer.h to define the type of the good data. The second, is the configuration, open ff.h (I use the fatfs, not tiny), _mcu_endian, choose your CPU is the big end of the storage (da endding) or small side storage (little endding), the general use of small end storage, 1 is the small end, 2 is big-endian. This is very important, and we'll talk about it in a moment. Other, according to their own needs to configure, explain the document is clear enough, I will not say anything more.

The third thing is to write the underlying driver functions, including:
Disk_initialize-initialize disk drive Disk_status-get disk status Disk_read-read sector (s) disk_write-write sector (s) Disk_ioctl-control device dependent features Get_fattime-get current time

All functions involve the choice of the first few disks, and if you use only one, you can ignore the DRV parameter.

Disk_initialize, if you don't need it, just return 0.

Disk_status, it's okay, just go back to 0 right now.

Disk_read-read sector (s)
Disk_write-write sector (s)
Read and write sectors, note the parameters Oh.

Disk_ioctl needs to respond to ctrl_sync,get_sector_count,get_block_size three commands and correctly returns 0 that is
RES_OK, returning Res_error incorrectly.
All commands are read from CTRL, the return value simply returns whether the operation is valid, and the data that needs to be passed back in the buff
Inside, here's my:
Ctrl_sync command, direct return 0;
Get_sector_count, gets the number of all available sectors (logical addressing is the LBA addressing method)
Get_block_size, how many bytes per sector, such as * ((dword*) buff) = 512;
Other command, return Res_parerr

Disk_ioctl This function is used only at the time of formatting, when debugging read and write, this function directly let him return 0 OK.

Get_fattime-Get the system time, format please see the documentation. If not, return to 0 on the line.

This transplant, but also basically succeeded, but on my board is not alive, each time a few macro definitions such as
Ld_word (PTR) (WORD) (* (word*) (byte*) (PTR)) produces a data termination exception (the "Database Abort exception"), but a brother on the net (a brother on the Ouravr, with an SD card, the IAR compiler, the platform is STM32, has succeeded, also announced the source code, here No problem AH), no problem. Analyze the meanings of these macros:

Ld_word (PTR) (WORD) (* (word*) (byte*) (PTR)) is defined in the little endding

Ld_word (PTR), LD is load,word in Integer.h defined is a 16-bit unsigned number, the need to do is to load a 16-bit number, or 2 bytes, the following PTR is a parameter. (WORD) (* (word*) (byte*)), first converts this PTR to a pointer to byte type data (BYTE *), converts the pointer to a pointer to a 16-bit unsigned number (WORD *), and then takes the data out with a "*", Converted to an unsigned 16-bit data, this is only from the C language point of view, in fact, this is done from the position of the PTR pointer point, take out 2 bytes, as a 16-bit unsigned number out, and these 2 bytes is little endding, that is, the small end mode, low byte is low 8 bits, The high byte is 8 bits high.


Since this is the case, test the next, define a byte buf[512], define a word type ZZ, with a pointer pt, let PT point to
Buf[0], call Ld_word (PTR), Zz=ld_word (PT); no problem, point pt to Buf[1], hehe, the problem immediately came out, the data terminated abnormally, and then tested the pointer to buf[3],buf[5] and so on odd number, is such a problem, I was depressed ah, TMD, compiler problem .... But fortunately, to find a problem, you can solve the problem, in the ff.h inside the macro definition inside this is an east to comment out, and then in the FF.C inside the several macro definition as a function, here paste one out:
WORD Ld_word (void *pt)
{
BYTE *pt = (byte*) PT; Defines a pointer that assigns the value of the address to which the current pointer is pointing to PT
Return (WORD) (pt[0]+pt[1]*256); Calculate this 16-digit number, (low 8 bits in front, high 8 bits in the back), and a forced type to go
Change, and return
}
It is important to note that the Ld_word returned must be word. In doing so, most of the compiler can also be compiled, but ads is a pass, there are 3 places,
Finfo->fsize = Ld_dword (&dir[dir_filesize]); /* Size */
Finfo->fdate = Ld_word (&dir[dir_wrtdate]); /* Date */
Finfo->ftime = Ld_word (&dir[dir_wrttime]); /* Time */
Where dir is defined as: const BYTE *dir, compiler error is type mismatch, so here are a few ld_word and Ld_dword rewrite, defined as a consistent type:
WORD ld_word_1 (const BYTE *PT)
{
BYTE *pt = (byte*) PT;
Return (WORD) (pt[0]+pt[1]*256);
}

DWORD ld_dword_1 (const BYTE *PT)
{
BYTE *pt = (byte*) PT;
Return (DWORD) pt[0]+ (DWORD) (PT[1]*256) + (DWORD) (pt[2]*65536) + (DWORD) (pt[3]*16777216));
}

And later changed to:
Finfo->fsize = Ld_dword_1 (&dir[dir_filesize]); /* Size */
Finfo->fdate = Ld_word_1 (&dir[dir_wrtdate]); /* Date */
Finfo->ftime = Ld_word_1 (&dir[dir_wrttime]); /* Time */

Compile, all the way OK, then write a file, wow, haha haha .... Finally came out .... It's okay to write a file, and it's no problem to read. @~~~~~ tests common functions, all without problems, including formatting (F_MKFS, if your disk_ioctl is not a problem), test
The next speed, read 12.5M MP3, about 3 seconds, write this 12.5M MP3 about 6.5 seconds, barely meet the requirements, and then optimize the drive over there can be faster. ~~~~~~~

Send a FATFS official website http://elm-chan.org/fsw/ff/00index_e.html

Summing up the transplant, the almost failure lies in the compiler pointer conversion problem, write out, I hope brothers and sisters in the transplant will not encounter this problem.