Porting of the Fatfs file system

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 the functions involved in the selection of the disk of the problem, if only one, you can not ignore thisDRVParameters.

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 sector, 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_synccommand, returned directly 0;
Get_sector_countTo get the number of all available sectors (logical addressing is the LBA addressing method)
get_block_sizeTo get the number of 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 (in the database abortexception), but a brother on the net (a brother on the OURAVR, using the SD card, the IAR compiler, Platform is STM32, has been successful, but also released the source, there is no problem AH), no problem. Analyze the meanings of these macros:

Ld_word (PTR) (WORD) (* (word*) (byte*) (PTR))It's defined in the littleendding.

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*) (PTR)), first convert this PTR to a pointer to BYTE type data(BYTE *), the pointer is converted to a pointer to a 16-bit unsigned number (WORD *), and then use a "*"Take this data out and convert it to an unsigned 16-bit data, which is, in fact, from the point of view of the C language, which is done from the point where the PTR pointer is pointing, taking out 2 bytes, taking out as a 16-bit unsigned number, and these 2 bytes are littleendding, That is, the small end mode, low byte is low 8 bits, high byte is high 8 bits.


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:

 1  WORD Ld_word (void  *PT)  2  {     3  BYTE *pt = (byte*) PT; //  Defines a pointer that assigns the value of the address to which the current pointer is pointing to PT  4  return  (WORD) (Pt[0 ]+pt[1 ]*256 ); //  calculates this 16-digit number, (low 8 bits in front, high 8 bits in the back), and a forced type to  5  //  6 } 

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,

1     Finfo->fsize = Ld_dword (&dir[dir_filesize]);    /*  */2     finfo->fdate = Ld_word (&dir[dir_wrtdate]);        /*  */3     finfo->ftime = Ld_word (&dir[dir_wrttime]);        /* */

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:

1WORD Ld_word_1 (ConstBYTE *PT)2 {3BYTE *pt = (byte*) pt;4     return(WORD) (pt[0]+pt[1]* the);5 }6 7DWORD Ld_dword_1 (ConstBYTE *PT)8 {9BYTE *pt = (byte*) pt;Ten     return(DWORD) pt[0]+ (DWORD) (pt[1]* the) + (DWORD) (pt[2]*65536) + (DWORD) (pt[3]*16777216));  One}

And later changed to:

1     Finfo->fsize = Ld_dword_1 (&dir[dir_filesize]);    /*  */2     finfo->fdate = ld_word_1 (&dir[dir_wrtdate]);        /*  */3     finfo->ftime = ld_word_1 (&dir[dir_wrttime]);        /* */

Compile, all the way OK, then write a file, come out!!!! Write the file no problem, read it! @~~~~~ 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

Porting of the Fatfs file system