转一篇比较详细介绍FatFs文件系统移植的文章.docxVIP

 HYPERLINK /jjldc/190030/message.aspx 转一篇比较详细介绍FatFs文件系统移植的文章 FatFs文件系统的移植 ??? 因为需要，又不想自己写，所以就移植了一个文件系统。 ??? 说下我的硬件和开发工具：接成 TRUE IDE 模式下的CF卡（也就是相当于一块硬盘了），三星S3C2440的ARM9,开发工具是很老很老的D版的ADS1.2。 ??? 我在网上看到的嵌入式系统上面常用的文件系统有UCOSII公司的UC/FS，支持CF卡，硬盘，SD/MMC卡，还有NAND FLASH等等，比较多，不过是商用的，需要银子的，有周立功的用于教学用（为什么说是用于教学用的，呵呵，等下就说）的ZLG/FS，还找到了开源、免费的两个，其中一个叫做 efsl ，另一个叫做 FatFs 。 ??? 现在先不考虑版权的问题，选择一个比较合适的文件系统。第一个UC/FS文件系统没得什么说的，UCOSII那个公司开发的，稳定性，兼容性应该都不会差。第二个是ZLG/FS。周立功的很多的开发板上面都送了这个文件系统的源代码的，在网上找到一个现成的读写硬盘的，只是是基于LPC2200系列的处理器的。第三个是efsl，是一个开源的项目，免费，只需要提供读扇区和写扇区2个函数。第四个是FatFs，跟efsl一样，也是一个开源的项目，移植的时候比efsl多几个简单的函数。 ??? 这里补充一下CF卡和硬盘的简单的资料，CF卡有三种模式，其中有一个叫TRUE IDE，接成这个模式以后，就跟他的模式名字一样，他就是一个硬盘，对他进行读写，也就相当于对一个硬盘进行读写。当引脚OE（好像是叫OE，具体参考 CF卡文档）在上电的时候检测到拉低，那么CF卡就进入TRUE IDE模式。读写硬盘的时候，在只写一次LBA，只发送一个命令（读或者写）的情况下，最多可以读或者写256个扇区（当然也可以读一个扇区，读或者写多 少个扇区在扇区计数器count里面），其中，发一个读或者写命令，读或者写256个扇区所需要的时间，比分256次去读写这些扇区所需要的时间要短得多，效率要高得多，我现在需要的是一个读写的速度比较快，效率比较高的文件系统，因此，底层的读写扇区必须要每写一个命令就可以读写多个扇区，读写扇区的函数必须要有扇区计数器（前面的count）这个参数，才可能满足要求。 ??? UC/FS也是在网上搜了个代码，看了下，很标准的几个层，什么硬件层，文件系统层，API层，等等（具体参见UC/FS的文档），跟UCOSII一个公 司的，稳定性应该不错，需要提供的函数也是读扇区，写扇区等等几个。但是底层的读写扇区的函数不需要提供扇区计数器count这个参数，也就是说，这个文 件系统不能在只写一个读或者写命令的情况下，读或者写多个扇区，本来效感觉不错的一个文件系统，效率就大大的降低了。 ??? 然后看了下efls这个文件系统，开源的项目，免费的项目，好东西，移植也很简单，同样移植的时候也是提供读写扇区等几个函数，但是面临的跟UC/FS同样的问题，每次读写的时候也只能读写一个扇区。 ??? 绝望之余看到了周立功的文件系统，大概看了下（没有仔细阅读源代码），硬件驱动上面能够在发一次读命令的情况下，读写多个扇区，而且感觉上比较简单，同 样，层次也很清楚，移植需要做的事情也是修改后面的读写扇区等等几个函数。于是就开干了。功夫不负苦心人，过了几天，CF卡能够读写了，拿到电脑上面看写 的数据，没问题。从CF卡里面读文件出来，打印到超级终端，也没有问题，以为就万事OK了，想了下，我们需要的，最关心的，第一是速度，然后就开始测试速 度，不测不知道，一测吓一跳！太“快”了，TMD，才5，6个K Bytes 每秒！！！！！（我的驱动已经测试了，上M字节每秒的）?? 于是跟踪到写里面去，发现一个很，十分，非常严重的问题：ZLG/FS提供了读一个字节的函数，忘了叫做啥，这里暂时叫 ReadOneByte（***），然后读多个字节，或者说读大块字节的函数用的是啥，呵呵， for（i=0；i N ; i++） ReadOneByte（***），这种机制，不慢才怪事！！！于是伤心的抛弃了ZLG/FS，这东东，学习还是可以的，商用的话，差太远了！！！ ??? 我那点东西，文件系统可以不上，但是必须有个文件存储协议，或者说叫做自己的文件系统，自己写个简单的存储协议，试过，很麻烦。但是如果上文件系统，自己 写的话，写要累死人的，写出来的不一定效率就高，速度就快，所以，还是在网上漫无目的的找，觉得应该有效率很高的文件系统的。 ??? 还是那句话，功夫不负苦心人，终于让我找到了，也就是现在所用的，FatFs，开源，免费，高效！（说一下这里几个文件系统都有的一个缺点，由于微软的FAT版