首页 > 范文大全

嵌入式系统中的线性Flash文件系统设计

时间：2025年01月27日

来源：在此一方

编辑：本站小编

收藏本文

下载本文

下面是小编收集整理的嵌入式系统中的线性Flash文件系统设计，本文共6篇，仅供参考，希望能够帮助到大家。本文原稿由网友“在此一方”提供。

篇1：嵌入式系统中的线性Flash文件系统设计

嵌入式系统中的线性Flash文件系统设计

作者： WuYJ@263.net.cn

摘要：设计一种能够在典型嵌入式环境下应用的线性文件系统，为嵌入式系统Flash空间的管理提供一种非常有效的手段。它包装和通用文件系统类似的API接口，设计的实现独立于实时操作系统（RTOS）和具体的Flash典型，可方便移植到不同的嵌入式应用中。

在嵌入式系统中，为了便于对闪存（Flash）空间进行管理，会采用文件的形式来访问Flash。目前，可以购买到的Flash文件系统一般都是兼容DOS的文件系统（Flash File System，FFS），这对需要一个具有复杂的目录层次，并且DDS文件兼容的系统来说是必要的；但是对大多数的嵌入式应用来说，这种文件系统太过奢侈。笔者在参与嵌入式系统项目的时候，设计了一种线性文件系统，它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力；二是文件系统的设计独立于实时操作系统（RTOS），这样可以很容易移植到不同的嵌入式应用中；三是设计统一的底层接口，适应不同的Flash类型。本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。

1 线性文件系统

线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和（CRC32）等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性；文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read、write()、open、close()、stat()和seek（）等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中（当然受物理空间限制），但不能跨片存储。

图1 Flash文件系统空间

在第一个文件创建之前，必须进行初始化，将所有分配给文件系统的`Flash空间擦除。当创建第一个文件时，起始位置从文件系统的起始地址开始，文件头指针指向下一个空文件的起始位置（链表尾部）；第二个文件的位置从当前的链表尾部开始，同时文件头中的链表指针指向新的尾部。删除文件时，仅仅是简单地把文件头的标识位中的活动文件标识位置0，表示删除。这样，在经过多次删除之后，就有必要运行碎片整理模块来进行文件系统Flash空间的碎片整理。碎片整理模块还需要在文件系统Flash空间尾部留一个扇区来数据备份，以便当碎片整理被打断时（如下电或者复位）可以恢复文件系统。这个保留的扇区称空闲扇区。它必须放在文件系统空间之后，这样可以保证文件系统的所有文件在所占用的Flash空间是连续的。整个文件空间的分配如图1所示。

阴影部分是文件头，数据结构如下：

struct hdr{

unsigned short hdrsize; /*文件头字节数*/

long filsize; /*文件头版本*/

long filsize; /*文件大小*/

long flags; /*描述文件的标识*/

unsigned long filcrc； /*文件数据的CRC32的值*/

unsigned long hdrcec; /*文件的最后修改时间*/

struct hdr *next; /*指向下一个文件头的指针*/

char name[NAMESIZE]; /*文件名*/

char info[INFOSIZE]; /*文件描述信息*/

};

碎片整个记录区包含两种数据类型：碎片整理文件头信息表defraghdr和文件区扇区整理前后的CRC值备份表sectorcre。具体的地址分配从空闲扇区的起始地址减1开始，往前分配文件系统扇区数乘以4字节作为sectorcrc的空间；从sectorcrc起始地址减1开始，往前分配活动文件个数乘以64字节作为碎片整理文件头信息表。这两个结构定义如下：

struct defraghdr{

struct hdr *ohdr; /*文件头的原始位置指针*/

struct hdr *nextfile; /*指向下一个文件的指针*/

long filsize; /*文件大小*/

unsigned long crc; /*这个头的CRC32值*/

unsigned long ohdrcrc; /*原始文件头CRC32值的拷贝*/

long idx; /*碎片整理表头的索引*/

long nesn; /*新的文件尾的扇区号*/

long neso; /*新的文件尾的扇区偏移量*/

char *nda; /*新的文件起始地址*/

char fname[NAMESIZE]; /*文件名*/

};

struct sectorcrc{

unsigned long precrc; /*碎片整理前扇区数据CRC32的值*/

unsigned long postcrc; /*碎片整理后扇区数据CRC32的值*/

}；

从上面介绍可知，除了文件数据之外，文件系统还需要如下4种额外的开销。

①文件头：这是每个文件必须的开销，如果文件名和信息域各24字节，那么整个文件头共76字节。

②碎片整理文件头信息表：每个活动（非删除）的文件在进行碎片整理时在这个表里创建一个表项，每个表项64字节。

③碎片整理前后的扇区CRC32值表：保存文件整理前后的CRC32值，总的字节数约为文件所占扇区数的4倍。

④空闲块：用来在碎片整理过程中备份当前整理扇区数据。它必须不小于文件系统其它所有扇区。

可以用下面方程计算系统开销的总和：

overhead=(FTOT*(HDRSIZE+64))+SPARESIZE+(SECTORCOUNT*8)

其中：

FTOT是总的文件数；

HDRSIZE是文件头字节数（目前为76字节）；

SPARESIZE是空闲块的大小；

SECTORCOUNT是分配给文件系统的Flash扇区数，不包括空闲块。

图2 文件碎片整理

2 碎片整理

创建新文件需要占用文件系统空间；但是，由于Flash的底层技术不允许Flash中的任意地址空间被删除，而是按照扇区为单位删除，为此在删除一个文件的时候，暂时没有把整个文件所占的空间删除，仅仅是在文件头的标识里作一个删除标识，并保留在Flash中。这样，被删除文件积累到一定的数量时，就会占用相当大的空间。因此，需要整理文件系统Flash空间，使被删除文件占用的空间重新使用。图2显示了碎片整理过程。文件F1、F2和F5已经被删除，并且在碎片整理之后从Flash中被清除。

进行碎片整理的方法可以有多种。对于嵌入式系统来说，选择哪种方法，衡量的依据是复杂性和功能之间的平衡。下面讨论两种不同的方法：第一种方法相当简单，但是有缺陷；第二种方法功能强大得多，笔者在线性文件实现中即采用这种方法。当然，存在更加复杂的解决办法，但通常的情况是，所添加的复杂性会使整个文件系统的实现更加复杂。目标是保持文件存储的简单和线性，保证所有的文件都是以连续的空间存储在Flash中。

最简单的方法是将活动的文件备份在RAM中，删除分配给文件系统的Flash空间，然后将RAM中备份的所有文件拷贝回Flash。这种方法很简单，并且不需要分配一个扇区作为空闲区；但问题是，需要有一整块和分配给文件系统的空间一样大的RAM来完成这项工作。更糟的是，如果此时系统被复位，或者在删除扇区内容却还没有将文件拷贝回Flash的时候被断电，文件系统将会崩溃。因为RAM中的内容会随之选择，文件内容会被破坏掉。

我们在文件系统实现设计了一种碎片整理方法，可以防止在碎片整理过程中系统复位导致文件崩溃的情况。采用这种方法，不需要大块的RAM，但是需要预选先分配给碎片整理过程一个Flash扇区作为备份区。这个扇区的字节数不小于任何分配给文件系统的扇区。在整个文件系统中，这个扇区位于分配给文件系统最后一个扇区的下一个扇区。因为扇区可能比需要分配给非删除文件的备份的空间要小，所以它必须逐个扇区进行处理，而不是一下就把所有的碎片整理完。采用备份扇区的好处是，在碎片整理过程中，无论断电或者复位都不会破坏文件系统。当下次系统重新恢复时，会根据在碎片整理前记录的每个扇区碎片整理前后CRC值，来判断当前的文件碎片整理状态。如果上次文件整理没有完成，就会继续上次的整理。这种技术的一个缺陷是空闲扇区的擦写次数会较多。这样空闲扇区就可能因为达到擦写寿命而失败。达到这一点的关键依赖于使用的Flash、所分配给文件系

统的扇区数、文件删除和重建的频率。一个可行的解决办法采用电池备份的RAM来替换空闲扇区，可以增加Flash的整体寿命，但是对那些预算紧张的应用来说太过奢移。

具体的碎片整理过程是，首先建立碎片整理区。①为每个扇区建立2个CRC32表项；第一个CRC32是这个扇区在碎片整理前的CRC值；第二个CRC32值是计算出来的碎片整理后的CRC32值。这些CRC是当碎片整理过程被打断时，用来重新恢复整理用的。②创建碎片整理文件头信息表，每个活动的文件占用一个表项。③计算①和②的CRC值，并保存。①～③的数据保存在图1中的碎片整理记录区。第二步是文件重定位；遍历文件系统的每个扇区，处理重新定位后存储空间和该扇区相覆盖的文件。在每个扇区被重写之前，扇区原来的信息被保存在空闲扇区里。第三步，擦除Flash；遍历未使用的扇区，确认所有的扇区被删除。第四步，完整性检测：对新的文件进行检测，保证所有重定位的文件都是完整的。

3 应用分析

Flash的扇区有最大擦写次数。当前的Flash芯片一般支持10万～100万次的擦除。文件系统的应用各不相同，所以这里不能下结论说采用线性文件系统Flash的寿命会有多长。下面解释文件系统访问Flash的方法。这样用户可以根据应用来判断Flash的预期寿命。

我们所设计的线性文件系统并不进行扇区删除次数均衡，以延长Flash的使用寿命。如果所需要的文件系统频繁修改并需要扇区删除次数均衡，可以购买现成的Flash文件系统。扇区删除均衡算法大大增加了底层实现的复杂性，并且超出本文的讨论范围。一般来说，通过文件系统来管理Flash的需求远大于对Flash扇区擦写次数均衡的需求，特别是现在越来越多的Flash扇区都支持100万次的擦写。

如上面所提到的，文件系统本身提供给编程者的接口API与标准OS提供的接口类似。这可能误导开发者认为文件系统可以看作是一个硬盘，以任意的频率进行读写操作。事实并不是这样，线性文件系统碎片整理同制并没有进行擦写次数均衡，这意味着空闲扇区可能会是最早损坏的Flash扇区。因为在碎片整理过程中，空闲扇区被用作其它所有扇区的暂时存放扇区。例如在设计里，有13个扇区Flash用来作线性文件系统区，有1个扇区作为空闲扇区。假设对于最坏情况的碎片整理（13个扇区都影响到），如果每天进行1次碎片整理，对于100 000次擦写次数的Flash而言，可用期能够超过（100 000/13/365=21）。20年是基于每天进行1次碎片整理，并且所有扇区都影响到的情况。碎片整理的频率和整理所影响到的扇区数受应用程序使用文件的限制。用户可以根据文件系统的应用来估算Flash扇区的磨损情况，并作相应的处理。

下面讨论文件系统是如何使用扇区的。Flash扇区仅仅在碎片整理时候才被擦除。当删除文件的时候，只是简单地作一个标识（文件头的一个位）。如果一个存在的文件以写的方式打开，实际的修改步骤是，删除原有的文件，并在当前文件系统的最后一个文件之后重写该文件。最后，这个过程会使文件系统的Flash空间被耗尽，这要就需要运行碎片整理程序。碎片整理程序会使已被删除文件所占用的空间被清除，所有活动的文件在Flash中的位置以连续的方式存放。每个扇区的整理过程是，扇区被拷贝到空闲扇区作备份，然后原来的扇区被删除，计算出该扇区在文件整理后的内容，写入扇区，之后删除空闲扇区的备份。文件系统从头到尾每个扇区重复这样作。在碎片整理时，如果一个扇区不需要进行碎片整理，碎片整理程序就不会动这个扇区因此，受碎片整理程序影响的扇区数目依赖于当前被文件系统占用的Flash扇区数和被删除文件在Flash中的位置。

在一个典型的嵌入式应用里，文件系统中的可执行文件本身就是应用程序。可执行文件一般是最大的文件，也是最不可能经常改变的文件。这意味着执行文件所占用的空间是相对固定的，将会减少空闲扇区因为碎片整理而进行的擦写次数。另外一方面，如果有任何文件需要定期改动，碎片整理将会更加频繁运行。

结语

本文所设计的线性文件系统已经成功应用在笔者参加的嵌入式系统的产品，并且在实践中证明是一种比较有效的管理Flash的方式。当然，线性文件系统不是解决所有嵌入式应用管理Flash空间问题的答案，但是它对于那些不能判断是否要购买现成的Flash文件系统的项目提供了一个非常有用的选择方案。有关线性文件系统实现的C源代码，可以通过E-Mail:WuYJ@263.net.cn直接与笔者联系。

篇2：嵌入式系统中的线性Flash文件系统设计

嵌入式系统中的线性Flash文件系统设计

作者： WuYJ@263.net.cn

线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力；二是文件系统的设计独立于实时操作系统（RTOS），这样可以很容易移植到不同的嵌入式应用中；三是设计统一的底层接口，适应不同的Flash类型。本文设计的`线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。

1 线性文件系统

线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和（CRC32）等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性；文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read()、write()、open（）、close()、stat()和seek（）等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中（当然受物理空间限制），但不能跨片存储。

图1 Flash文件系统空间

在第一个文件创建之前，必须进行初始化，将所有分配给文件系统的Flash空间擦除。当创建第一个文件时，起

[1] [2] [3]

篇3：车载MP3中Flash文件系统的设计与应用

摘要：基于Flash存储器的特点，详细介绍适合地车载MP3的Flash文件系统（包括Flash存储管理系统和FAT文件系统）的具体设计。利用Flash文件系统实现对Flash存储器的较好的操作管理功能。

关键词：车载MP3 Flash存储管理系统 FAT 文件系统

引言

目前车载播放器基本上采用的是CD播放器、MD播放器以及磁带播放器等。由于这类播放器内部具有一些机械式传动部件，再加上装在汽车这个特定的环境中，经常会由于机械传动或者光头、磁头受震动发生跳音或绞带现象，从而影响音质。

Flash存储器由于具有存储容量大、掉电数据不丢失、何种小以及可多次擦写等许多优点，正逐步取代其它半导体存储器件而广泛应用于移动电话、PDA以及数码相机等移动电子产品中。其作为存储数据和应用程序的存储体，可以将大量数据方便、快捷地移动和交换。

基于上述两点设计了一个车载MP3系统。该系统采用Flash作为外存储器，并且由全固态器件组成，播放时不会出现跳音或绞带现象，音质也很好。由于Flash存储器在应用过程中可能会出现坏损单元，影响车载MP3播放器的性能，因此本文针对Flash存储器自身的物理特性，设计了一个文件系统，对Flash存储器中的数据内容进行基于文件名或者文件号的存储管理以及应用透明的坏损管理。该系统优化了存储速度和存储空间，提高了车载MP3播放系统的可靠性。

1 Flash存储器特点

Flash内部分为多个存储单元块（block），每个存储单元块又由多个页（page）组成。存储单元块是可擦除的最小单位，页是写入数据的最小单位。

Flash存储器读取数据与一般的存储器类似，可以实现随机读取，读出的速度也很快。而Flash存储器的写操作则和一般的存储器有所不同，Flash的写操作必须先按存储块擦除（写入0xff到要擦除的存储单元块中），再按页顺序写入。由于Flash存储器擦除耗时较长，所以Flash存储器写入的时间主要在于Flash存储器内部的擦除操作等。

Flash存储器第一块一定是有效块，而其它块可能会在使用前就是坏块或者在使用过程中变成坏块（invalid block）。Flash存储器对内部坏块的判定是，根据其每一个单元存储块中的第3区中的第6 Cloumn内容是否为0xff来定。虽然Flash存储器内容会有坏块，但是由于每一块的内部结构都是相互独立的，所以只要对其状态加以识别，坏块并不影响系统对有效块的操作。

(本网网收集整理)

篇4：车载MP3中Flash文件系统的设计与应用

本文在Flash存储的基础上设计了一个Flash存储管理系统来对Flash进行物理管理。而在Flash存储管理系统基础上又建立了一个FAT文件系统来对文件操作进行管理，由Flash存储管理系统和FAT文件系统共同组成了Flash文件系统。该文件系统完全支持文件名管理、自动坏损管理等通用文件系统所具有的功能；同时，针对车载MP3播放器系统特殊的应用环境，设计改进了该文件系统的可靠性，即使在恶劣的条件下也不会影响音质。Flash文件系统的具体结构如图1所示。

2.1 Flash存储管理系统

Flash存储器的操作是以块为单位的，而FAT文件系统则是建立在以扇区（sector）为单位的磁盘操作基础上（通常为512字节/扇区）。因此，本文设计了一个特殊的Flash存储管理系统，来解决以块为单位的Flash物理特性和以扇区为单位的文件系统接口之间的矛盾，以使得Flash的物理地址和FAT操作的逻辑地址之间能够对应。同时，由于Flash的其它特点，Flash存储管理系统还实现了各块之间的擦写次数均衡和坏块管理等工作。

（1）物理地址到逻辑地址的映射

为了在Flash物理地址和FAT操作的'逻辑地址之间建立一个好的映射关系，对Flash的存储空间在逻辑上进行了重新定义。结合Flash特点，将每个存储单元块内部分成若干物理扇区，每个物理扇区由512字节+16字节=528字节组成。其中Main Area的512字节为有效数据空间，而Spare Area的16字节用于存放其它信息。

由上述定义便可以确定Flash物理扇区和绝对地址之间的对应关系：

绝对地址=Flash基地址+物理扇区号×528

在建立了物理地址和逻辑地址之间的映射关系之后，但可以很好地将车载系统对音频文件的操作转换成系统直接Flash的编程或者擦除操作。例如，在该系统中要进行ReadFile操作，便可以根据其对应关系，通过执行Flash存储管理系统中的sectorread()操作来实现。

（2）可靠性设计

由于该车载系统采用汽车供电，因此当汽车处于不太平衡的环境中，可能会由于颠簸千万播放系统的异常断电，所以提高车载MP3播放系统的可靠性非常重要。本文通过将Spare Area的16字节定义为逻辑扇区号、扇区当前状态、坏块信息等来提高播放系统的可靠性。其中Spare Area的具体定义如下：

逻辑扇区号扇区当前状态坏块信息保留字节第1～3字节第4～5字节第6字节第7～16字节

由以上定义可以看到，Spare Area的第4～5字节用于存储扇区当前状态。这样在Flash写操作过程中，如果突然断电，便可以根据此状态进行掉电数据恢复。该系统中设定扇区当前状态有3种：扇区为空（0xfff）、扇区数据无用（0x0000）、扇区数据有效（0x00ff）。这样定义以后，系统便可以在Flash写操作异常终止时能够对当时的状态进行及时的保存，以便下次系统开启后能够判断出上次系统中存在的问题并作出相应的处理。

（3）坏块管理

由于Flash内部会有坏块，因此Flash存储管理系统需要对Flash进行坏块管理。本文对坏块的管理分以下两种情况：

①初始坏块处理。Flash存储器在使用前可能会有坏块，而且这些坏块是随机分布的。所以，Flash文件管理系统在系统执行读写操作之前先建立一个坏块表，然后对Flash存储器进行初始化扫描以发现坏块，并将坏块标记为不可用，加入到坏块表中。

②操作过程中坏块处理。在擦除或者编程过程中发生错误时，Flash文件管理系统将该块中其它页的数据重新拷贝到一个新的空块中，然后再将该块标记为坏块，加入到坏块表中。在这个处理过程中，由于对Flash的擦除或者编程操作都会使得Flash存储单元块的内容改变，所以Flash文件管理系统一旦发现Flash存储器的存储单元块成为坏块后便不再对该块进行擦除或编程操作，以免将坏块标志位数据清除掉，而是将该块标记为坏块，并将其加入坏块表中。

Flash文件管理系统在进行上述坏块管理后，坏块单元对用户应用是完全透明的。这大大方便了用户的使用，也达到了车载MP3播放系统的目的。

（4）均衡擦写次数

由于Flash有一定的使用寿命，一般可擦除的次数为10～100万次，所以随着使用次数的增加，会有一些单元逐渐变得不稳定或失败。因此，要尽量避免频繁地对同一块地址操作，以免造成局部单元提前损坏；同时，由于擦除操作耗时较多，也应减少擦除操作，应该尽量达到擦写次数均衡。为此，本文设计了Flash更新算法和磨损程度检测算法。

Flash更新算法是将Flash中要更新的数据直接写入一个空块中，降低由于Flash先擦除后写入的特性带来的对块的频繁擦除；同时，也提高了Flash的使用效率，加快了操作速度。磨损程度检测算法是在对Flash进行写入前必须先对Flash进行坏块扫描，以确保不会将数据写入坏块从而此起数据的丢失。这样设计也是为了提高车载MP3播放系统的可靠性。

2.2 FAT设计

在Flash文件管理系统的基础上，还建立了FAT文件系统来对文件操作进行管理。将FAT文件系统具体分为以下四部分：

（1）FAT的引导区

该引导区存放代码所需的信息及最重要的文件系统信息。这些信息包括了Flash存储器的类型、容量以及划分成多少个簇；每个簇包含多少扇区、FAT表数目、保留扇区数、根目录的首簇号及根目录入口数、版本信息等等。引导扇区是在格式化Flash时生成的。

（2）FAT的文件分配表

文件分配表存放文件所占用的存储空间族链以及Flash存储器的占用和空闲空间的情况，非常重要。为了防止文件分配表损坏而引起文件的丢失，该系统中保存了两个相同的文件分配表FAT1和FAT2，以改善其安全性。在文件系统的操作中，程序对FAT表结构的两个备份进行顺次修改，以此确保Flash存储器上总是存有一整套完好的文件分配表。

系统对FAT表的访问原理如下：访问文件时先从要目录中找到该文件的目录项，从中读出首簇号。然后，目录中找到该文件的目录项，从中读出首簇号。然后在FAT中找到从该首簇号开始的簇链，簇链上的簇号即为文件在逻辑扇区中占用的扇区号链，这样便可以进行数据读写了。

（3）FAT的根目录区

FAT的根目录区是固定大小的紧跟在FAT表后的区域。本文将从FAT区之后紧跟的32个扇区作为根目录区，可以保存512个目录项。每个目录项记录了该文件的文件名、文件属性、文件大小、文件创建的日期和时间以及文件在数据区中所占的首簇号，即该文件在FAT表中的入口等数据。

（4）FAT的数据区

数据区存在文件的数据内容。文件系统对数据区的存储空间是按簇进行划分和管理的。该系统中，定义1Cluster=32sector，一个文件总是占用若干个整簇，文件所使用的最后一簇剩余空间就不再使用。

由图1可以看出，该FAT文件系统提供文件的格式化，文件的打开、删除、关闭，文件的读写、查找等基本的功能。通过Flash文件系统对文件的操作进行管理后，该车载播放系统便可以实现选曲、添加删除歌曲、下载歌曲、音量调节等一系列功能了。

3 应用

通过这样的设计，Flash的存储性能有了较大的改善，而且系统的可靠性也很好。即使在Flash写操作异常终止频发的最恶劣工作条件下，也不会丢失数据，更不会损坏非常重要的文件分配表结构而造成系统的崩溃；因此，本文所设计的Flash文件系统能很好地适合于车载MP3播放系统的应用。

篇5：嵌入式操作系统VxWorks中TFFS文件系统的构建

嵌入式操作系统VxWorks中TFFS文件系统的构建

摘要：目前的嵌入式系统多使用FLASH作为主存，因此，如何有效管理FLASH上的数据非常重要。文章以MX29LV160BT芯片为例，讨论了在VxWorks操作系统下NorFlash上建立TFFS文件系统的一般步骤，从而为FLASH上的数据管理提供了理想的选择方式，同时也为开发者和用户升级程序提供了方便。

关键词：VxWorksFlashMTDTFFS文件系统

嵌入式系统正随着Internet的发展而在各个领域得到广泛的应用，作为一个优秀的操作系统，VxWorks实现了比其他实时操作系统更好的有效性、商用性、可裁减性以及互操作性，广泛应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。

如今越来越多的嵌入式操作系统中，通常都使用FLASH作为主存介质。许多开发者和用户为了方便以后升级用户程序，通常在FLASH上建立TFFS文件系统，建立文件系统后，我们就可以象在windows操作系统下对硬盘操作一样，进行数据的拷贝、删除以及文件的建立等操作。

NOR和NAND是现在市场上两种主要的非易失闪存技术。Intel于1988年首先开发出NORflash技术，彻底改变了原先有EPROM和EEPROM一统天下的局面。NOR的特点是芯片内执行XIPexecuteInPlace，这样应用程序可以直接在flash闪存内运行，不必再把代码读到系统RAM中。NOR的传输效率很高，在1～4MB的小容量时具有很高的成本效益，因此在嵌入式系统得到广泛的应用。

一、TFFS文件系统结构简介

Tornado的TrueFFS是和VxWorks兼容的一种M-SystemsFlite实现方式，版本为2.0。它为种类繁多的flash存储设备提供了统一的块设备接口，并且具有可重入、线程安全的特点，支持大多数流行的CPU构架。有了Tornado的TrueFFS，应用程序对flash存储设备的读写就好象它们对拥有MS-DOS文件系统的磁碟设备的操作一样。

如图1所示，TrueFFS由核心层（corelayer）和三个功能层，翻译层（translationlayer），MTD层（MTDlayer），socket层（socketlayer）组成。

核心层（Corelayer）：核心层主要起相互连接其他几层的功能。同时它也可以进行碎片回收、定时器和其他系统资源的维护。通常WindRiver公司将这部分内容以二进制文件提供。

翻译层主要实现TrueFFS和dosFs之间的高级交互功能。它也包含了控制flash映射到块、wear-leveling、碎片回收和数据完整性所需的智能化处理功能。目前有三种不同的翻译层模块可供选择。选择哪一种层要看你所用的flash介质是采用NOR-based,还是NAND-based,或者SSFDC-based技术而定。

Socket层则是提供TrueFFS和板卡硬件（如flash卡）的接口服务。其名字来源于用户可以插入flash卡的物理插槽。用来向系统注册socket设备，检测设备拔插，硬件写保护等。后面将详细讲解它的.功能。

MTD层（MemoryTechnologyDrivers）功能主要是实现对具体的flash进行读、写、擦、ID识别等驱动，并设置与flash密切相关的一些参数。TrueFFS已经包含了支持Intel,AMD以及samsung部分flash芯片的MTD层驱动。新的芯片需要新的MTD支持，你可以使用一个标准的接口来加入这些驱动。

以上四部分，我们通常要的工作就是后两层。

当在VxWorks下配置TrueFFS时，你必须为每一层至少包含一个软件模块。后面我们将详细讨论。

二、MX29LV160BT芯片上建立TrueFFS文件系统

1、配置相关文件

在此，我以NorFlashMX29LV160BT为例，开发工具为Tornado2.2forPPC。要在VxWorks映像中包含TrueFFS文件系统，首先必须在config.h文件中定义INCLUDE_TFFS。这使得VxWorks的初始化代码调用tffsDrv()来创建管理TrueFFS所需的结构和全局变量，并为所有挂接了的flash设备注册socket组件驱动。在链接的时候，通过解析与tffsDrv()相关联的符号（symbols）可以将TrueFFS所必需的软件模块链接到VxWorks映象中。

为了支持TrueFFS，每一个BSP目录下都必须包含一个sysTffs.c文件。它将TrueFFS所有的层（翻译层，socket层和MTD层）链接到一起并和VxWorks绑定。因此，我必须编辑这个文件并决定哪一种MTD和翻译层模块应该包含到TrueFFS中。即：

#defineINCLUDE_MTD_MX29LV/*MX29LV160BTMTDdriver*/

#defineINCLUDE_TL_FTL/*FTLtranslationlayer*/

#defineFLASH_BASE_ADRS0x2a10000/*Flashmemorybaseaddr

ess*/

#undefFLASH_SIZE

#defineFLASH_SIZE0x001f0000/*Flashmemorysize,2M(parameterblock)*/

其他无关的MTDdriver包含头都#undef掉，同时定义Flash在系统中的基地址和大小。另外，还必须编辑sysLib.c中的sysPhysMemDesc[]数组，将Flash基地址和大小加入到MMU中，以供将来访问Flash，否则访问Flash会失败。如果BSP目录下没有sysTffs.c文件，那么我们可以从其他BSP目录下拷贝一个即可，然后做上述修改，其他的内容基本可以不用修改。

接下来需要修改tffsConfig.c文件，为了方便管理，通常我们将src/drv/tffs/目录下该文件拷贝到我们BSP目录下，然后再做出修改。在MTDidentifyRoutinemtdTable[]表中加入如下语句：

#ifdefINCLUDE_MTD_MX29LV

mx29lvMTDIdentify,

#endif/*INCLUDE_MTD_MX29LV*/

并在该文件开头声明。

#ifdefINCLUDE_MTD_MX29LV

FLStatusmx29lvMTDIdentify(FLFlashvol);

#endif/*INCLUDE_MTD_MX29LV*/

最后就是将我们的flash相关MTD驱动加入到makefile中。即：

MACH_EXTRA=mx29lvMtd.o

为了方便我们调试MTD驱动，应该在重新编译VxWorks映象前将诸如格式化flash、创建TrueFFS块设备、绑定此块设备到dosFs所必要的功能包含到VxWorks映像中。比如如下定义：

#defineINCLUDE_TFFS

#ifdefINCLUDE_TFFS

#defineINCLUDE_TFFS_DOSFS

#defineINCLUDE_TFFS_SHOW

#defineINCLUDE_DOSFS/*dosFsfilesystem*/

#defineINCLUDE_SHOW_ROUTINES/*showroutinesforsystemfacilities*/

#defineINCLUDE_TL_FTL

#defineINCLUDE_IO_SYSTEM

#defineINCLUDE_DISK_UTIL

#endif/*INCLUDE_DOSFS*/

2、MTD驱动简介

做了上述配置后，进入VxWorks操作系统后，我们在shell上利用tffsShow工具来显示flash的信息。TffsShow函数最终会调用MTD驱动中的mx29lvMtdIdentiy()函数，在mx29lvMtdIdentiy()函数主要是通过读取MX29LV160BT芯片的设备和厂商ID来识别它，然后对FLFlash结构成员进行初始化，最主要的几个参数是：

type

Flash内存的JEDECID号。

erasableBlockSize

Flash内存的擦除块大小（字节）。设置这个值时应考虑到interleaving。因此，通常通过如下方法来设置它的大小。

Vol.erasableBlockSize=MX29LV_MTD_SECTOR_SIZE*vol.interleaving;

对于MX29LV160BT，MX29LV_MTD_SECTOR_SIZE为64K字节。

chipSize

使用来构建TrueFFS文件系统的flash实际大小（字节）。

noOfChips

使用来构建TrueFFS文件系统的flash实际片数。

interleaving

Flash内存交叉因子（interleavingfactor）。即扩展数据总线的设备数。比如，一个32位数据总线上，我们可以使用4片8位或2片16位的设备。

map

指向flash内存映射（map）函数。该函数将flash映射到内存区。

read

指向flash内存的读函数。在MTD驱动识别函数中，这个成员函数已经被初始化为缺省的读函数。通常情况下，我们不需要再初始化它，否则还需要修改很多相关的函数。

write

指向flash内存的写函数。这个成员必须初始化，这是我们要做的一个重要工作。

erase

指向flash内存的擦除函数。这个成员必须初始化，这也是我们要做的一个重要工作。

针对FLFlash结构成员，我们所关心的两个函数就是写和擦除函数。在mx29lvMtdIdentiy()函数中必须有如下定义：

vol.write=mx29lvWrite;

vol.erase=mx29lvErase;

在mx29lvWrite()函数中主要是实现将数据写到flash中。首先需要对扇区进行解锁，然后写入写命令，之后才能进行数据的写入。最后需要判断数据是否写完。为了确保操作成功，我们应该在写完每个数据后进行数据的比较，比较正确后方能进行下一个数据的操作。

在mx29lvErase()函数中主要是实现f

lash扇区的擦除。如今的flash一般都是按照扇区进行擦除操作的。在擦除操作之前也应该首先对扇区进行解锁，然后写擦除建立和扇区擦除命令。擦除成功后，flash中的内容应该是0xffff。所以为了确保成功，我们还是应该在擦除后进行比较，比较正确后方能进入下一个扇区的擦除操作，否则返回擦除错误标志。

所以，对于MTD驱动的调试，基本上就是调试写和擦除两个函数。在调试过程中，我们可以在这两个函数相应位置加入打印语句来调试。为了能调试这两个函数，我们通过在shell上输入命令tffsDevFormat来格式化flash，tffsDevFormat最终会调用mx29lvErase和mx29lvWrite函数，如果成功就会返回0，否则返回-1。当然也可以调用tffsDevCreate函数来验证我们的写和擦除函数的正确性。图2说明了tffsDevCreate调用过程。

在shell上利用tffsShow来验证mx29lvMtdIdentiy。

ètffsShow

0:socket=RFA:type=0x2249,unitSize=0x10000,mediaSize=0x1f0000

value=49=0x31=“1”

说明已正确识别到MX29LV160BT设备，设备号为0x2249。

三、建立TFFS设备

1、挂接设备名

MTD驱动调试成功后，我们就可以给flash设备挂接上dos设备名，如下操作：

格式化：

ètffsDevFormat

value=1

èusrTffsConfig0,0,”/tffs0”

value=0

然后通过devs来查看挂接的设备名。

èdevs

drvname

0/null

1/tyCo/0

1/tyCo/1

5host:

6/pty/rlogin.S

7/pty/rlogin.M

3/tffs0/

8/vio

value=25=0x19

看到/tffs0/说明挂接设备已经成功，接下来就可以利用dosFs文件系统相关命令来操作flash了。如，ls、copy等。

2、从Flash中启动并下载VxWorks映像

要从flash中下载VxWorks映像，首先需要把VxWorks映像拷贝到flash中，在shell中的操作命令为copy“VxWorks”,”/tffs0/VxWorks”，然后修改config.h文件中引导行，如下：

#defineDEFAULT_BOOT_LINE\\

“tffs=0,0(0,0)host:/tffs0/VxWorksh=192.168.0.153e=192.168.0.154u=targetpw=targeto=cpm”

修改完后，重新编译生成bootrom_uncmp.bin，并把它烧写到flash中（注意：该flash与上面建立TFFS文件系统的flash不一样，它并没有建立文件系统）。然后重新启动，即可看到如下启动画面：

bootdevice:tffs=0,0

unitnumber:0

processornumber:0

hostname&

nbsp;:host

filename:/tffs0/VxWorks

inetonethernet(e):192.168.0.154

hostinet(h):192.168.0.153

user(u):target

ftppassword(pw):target

flags(f):0x0

other(o):cpm

AttachingtoTFFS...done.

Loading/tffs0/VxWorks...894304

Startingat0x10000...

DevelopmentSystem

VxWorksversion5.5.1

KERNEL:WINDversion2.6

CopyrightWindRiverSystems,Inc.,1984-

CPU:MotorolaADS-PowerPC860.Processor#0.

MemorySize:0x1000000.BSPversion1.2/5.

WDBCommType:WDB_COMM_END

WDB:Ready.

到此，说明引导成功。flash整个TFFS文件系统就已经建立成功。

四、结论

VxWorks操作系统中支持TFFS文件系统，我们将VxWorks映像作为文件放到flash上，这就有利于开发者和用户更新应用程序而不需要影响bootrom，直接更新VxWorks映像或者将应用程序直接copy到flash中，然后装载到RAM中运行。

参考文献

1VxWorks5.5Programmer’sGuide.

篇6：嵌入式操作系统VxWorks中TFFS文件系统的构建

嵌入式操作系统VxWorks中TFFS文件系统的构建

摘要：目前的嵌入式系统多使用FLASH作为主存，因此，如何有效管理FLASH上的数据非常重要。文章以MX29LV160BT芯片为例，讨论了在VxWorks操作系统下Nor Flash上建立TFFS文件系统的一般步骤，从而为FLASH上的数据管理提供了理想的选择方式，同时也为开发者和用户升级程序提供了方便。

关键词：VxWorks Flash MTD TFFS 文件系统

嵌入式系统正随着Internet的发展而在各个领域得到广泛的'应用，作为一个优秀的操作系统，VxWorks实现了比其他实时操作系统更好的有效性、商用性、可裁减性以及互操作性，广泛应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。

NOR和NAND是现在市场上两种主要的非易失闪存技术。Intel于1988年首先开发出NOR flash技术，彻底改变了原先有EPROM和EEPROM一统天下的局面。NOR的特点是芯片内执行XIP execute In Place，这样应用程序可以直接在flash闪存内运行，不必再把代码读到系统RAM中。NOR的传输效率很高，在1～4MB的小容量时具有很高的成本效益，因此在嵌入式系统得到广泛的应用。

一、 TFFS文件系统结构简介

Tornado的TrueFFS是和VxWorks兼容的一种M-Systems Flite实现方式，版本为2.0。它为种类繁多的flash存储设备提供了统一的块设备接口，并且具有可重入、线程安全的特点，支持大多数流行的CPU构架。有了Tornado的TrueFFS，应用程序对flash存储设备的读写就好象它们对拥有MS-DOS文件系统的磁碟设备的操作一样。

如图1所示，TrueFFS由核心层（core layer）和三个功能层，翻译层（translation layer），MTD层（MTD layer），socket层（socket layer）组成。

核心层（Core layer）：核心层主要起相互连接其他几层的功能。同时它也可以进行碎片回收、定时器和其他系统资源的维护。通常WindRiver公司将这部分内容以二进制文件提供。

Socket层则是提供TrueFFS和板卡硬件（如flash卡）的接口服务。其名字来源于用户可以插入flash卡的物理插槽。用来向系统注册socket设备，检测设备拔插，硬件写保护等。后面将详细讲解它的功能。

MTD层（Memory Technology Drivers）功能主要是实

[1] [2] [3] [4] [5]

嵌入式系统中的线性Flash文件系统设计.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档