当前位置：首页 > 实用文档 > 其他范文> 基于CC/CCS的Flash文件系统设计

基于CC/CCS的Flash文件系统设计

时间：2023-03-14 08:11:25 其他范文收藏本文下载本文

基于CC/CCS的Flash文件系统设计（通用6篇）由网友“黄福瑞”投稿提供，下面就是小编给大家带来的基于CC/CCS的Flash文件系统设计，希望能帮助到大家!

基于CC/CCS的Flash文件系统设计

篇1：基于CC/CCS的Flash文件系统设计

1 概述

在开发DSP的应用程序过程中，经常需要处理一些数据文件。这些数据文件可以是实际采集到的数据集合，也可以是用模拟仿真软件产生的数据集合，一般是以文件的形式存放在主机磁盘上的。一般的开发环境（如TI的CCS和CC）都提供了ANSI C标准操作文件格式，如打开一个文件fopen(“盘符：\路径\文件名”，“打开模式”)。嵌入式系统一般都外挂Flash。我们希望能够和读写主机磁盘文件一样操作Flash读写时序等问题，使应用编程人员可以把精力用在解决实际应用问题上，从而提供一个良好的编程接口。同时，在需要键盘、串口等设备的系统中，也希望提供一个简易的API接口，如从键盘得到一个键，只需作如下操作，在执行fopen(“keyboard”,“读”)后，就可以用fread函数读入一个字符。

结合TI公司提供的DSP开发环境CC/CCS（CC针对3X系列，CCS针对5X和6X系列）和实际开发经验，提供上述问题的解决方案，并成功应用到我们的产品中。

2 CC/CCS文件操作机制

TI公司为其TMS320C3X系列DSP提供了一个开发环境Code Composer,配套的C语言编译器提供了文件的标准操作。在调试(debug)环境下，对主机(host)硬盘文件的操作是通过标准的ANSI文件操作格式与主机的通信来完成的。ANSI C I/O操作分为三个等级―high level、low level和Device level。在High level中，标准接口是Fopen和Fwrite等函数；而Low level中是Open和Write等函数。这三个等级功能用三个表来实现―文件表、流表（实质就是内存缓冲区索引）和设备表。文件的打开和关闭等基本属性在文件表中反应。当打开一个文件时，文件表中便相应增加一个描述该文件的信息单元；同样，关闭一个文件时，该文件的信息单元从文件表中被删除。流表提供了对文件的缓冲操作处理，缓冲区位置和大小等均在流表中记录。一个文件对应一个流，即缓冲区。对文件的读写就是对缓冲区的读写。当缓冲区填满时，再一次性写入Flash等设备中，避免了对Flash的频繁操作，延长了Flash的使用寿命。设备包括Flash、硬盘、键盘等在设备表中体现。多个流可以对应一个设备，例如在Flash中可以打开多个文件，但是一个设备不能对应多个流。流操作和设备操作是紧密联系在一起的。当打开一个文件时，同时给出了该文件在什么设备上操作，再分配一个流。以后对该文件的操作通过流对应的具体设备的驱动函数来完成。主机的target任何外设都可被加入进去成为设备表的成员之一。

Code Composer对HOST磁盘文件的操作最终是通过与HOST集成开发环境通信的方式来进行。TI提供的RTS.LIB提供两个函数与主机通信，writemsg函数发送数据和参数到主机。Readmsg()函数从主机读取数据到目标机。Code Composer再与主机进行交互，利用主机文件系统的支持，屏蔽了具体的物理地址读写问题。在调试阶段，当要在主机上建立文件、读取文件和存储数据时，只需用标准的ANSI C函数操作就可以，从而极大方便了编程调试。

篇2：基于CC/CCS的Flash文件系统设计

嵌入式文件系统一般有集中管理文件系统，存储空间的使用信息集中存在存储器的某个地方，如DOS的FAT，Unix的inode表。线性文件系统，又称为连续文件系统，每个文件相关的.所有信息都连续存放在存储器中。与集中式文件系统相比，实现更简单，读写更快，特别是将文件的关键系统分布存放。日志文件系统顺序写入文件系统的修改，如同日志记录一样，可加速文件写入和崩溃修复。采用Log唯一结构，Log包含索引信息、名称和数据。嵌入式系统不可能带硬盘，一般都是基于Flash存储器的。

3．1 Flash特点及其相应处理

Flash的读操作与普通RAM时序一样，但是写和擦除操作则具有自身的特点。同一地址不能同时写入两次，必须进行费时的擦除操作。执行擦除的方式有三种：一是片擦除，即一次性全部擦除所有内容（这个相当于格式化功能，在第一次使用时可以执行这种操作）；二是块擦除；三是扇区擦除。以SST39VF400A为例，块Block的大小是32KB，扇区的大小是2KB，块擦除一次擦除一个块内容；扇区类似。如果一个文件内容被改动，且改动的内容不足一个扇区的话，则更新文件时必须重写这个扇区的所有内容；在重写前必须擦除该扇区的所有内容。因此基于Flash的文件系统不能完全套用已有的文件系统，但可以在其基础上进行改动。Flash能够擦除的范围越小，对文件的改动就越小，所执行的I/O操作就越小，从而减少I/O时间，提供文件系统的实时性能。我们使用的SST39VF400A的扇区大小是2KB，也就是2048B（1K=1024）。用常数定义，#define FileUnit 2048。

3．2 Flash文件系统的层次性

与ANSI C标准相对应，我们将Flash文件系统

分为3个层次。第一层次，API层。API层是文件系统与用户应用程序之间的接口，包含一个与文件函数相关的函数库，如FS_FOpen、FS_Fwrite等，也相当于High Level层。第二层次，文件系统层，即Low Level层。该层处理文件是否存在，打开，关闭和为文件分配相应的缓存等。该层调用底层驱动。第三层是Device Level层，就是设备驱动层。Flash的实际读写操作就是在该层进行的，特定的Flash存储器对应特定的读写程序。

3.3 Flash文件信息表的设计

该表保存Flash中已有文件的属性，Flash大小和文件的属性等都在该表中反映出来。该表与Flash中的内容保持同步更新，即一个文件最小块更新完毕时，写入Flash中。

Flash的空间分配：

①Flash空间，以簇为单位，读和写都是一簇，即一个扇区单位；

②0簇给文件分配表，不被应用文件占用；

③每次文件系统初始化时，把Flash内0簇的内容读取到内存中，保存在数组FAT16[]中。

常量定义

#define CLUSTER_BLOCK_SIZE 2048 //每一簇的字节数

#define NUMBER_OF_CLUSTER_IN_FAT16 25

//在文件分配表中，一共有多少个簇

#define NUMBER_OF_FILE_BUF 10

//一共有几个文件缓冲区

#define MODE_OPEN_FILE_READ 0x01 //读取（文件打开模式）

#define MODE_OPEN_FILE_WRITE 0x02 //写入（文件打开模式）

#define MAX_SIZE_OF_FIEL 2048 //文件的最大尺寸

文件结构体：

typedef struct{

unsigned int IsLock:1;//文件是否被上锁，=0没打开；=1已被打开。此标志只在文件的第一簇使用

unsigned int status:7;//簇的状态，=0，此簇为色，没使用；=1，此簇是第一簇；=2，此簇不是第一簇

char FileName[8];//文件名，在第一簇有效

char FileExName[3]; //文件扩展名，在第一簇有效

unsigned int SizeOfFile;//文件的字节数，在第一簇有效

unsigned int NextCluster;//下一簇的簇号。当为0xffffffff时，说明这是当前文件的最后一簇

}FlashFAT;

文件句柄结构体：

typedef struct{

unsigned int Buffer[CLUSTER_BLOCK_SIZE];//文件缓冲区

unsigned int fileblock;//文件当前簇的位置

unsigned int filemode;//打开支持的模式

unsigned int filebufnum;//文件缓冲区中已被/写的字节数

unsigned int fileCurpos;//文件读写的当前位置

unsigned int filesize;//文件的大小

}FlashFILE;

3.4 Device Level驱动函数

SST39VF400A标准设备级驱动函数如下：

void Program_One_Word(WORD SrcWord,WORD far Dst){/*写入一个字*/

WORD far *Temp;WORD far*SourceBuf;WORD far*DestBuf;

Int Index;DestBuf=Dst;

Temp=(WORD far *)0xC0005555;/*设置地址为C000：555h*/

*Temp=0xAAAA; /*写数据0xAAAA到此地址*/

Temp=(WORD far *)0xC0002AAA;/*设置地址为C000：2AAAh*/

*Temp=0x5555;/*写数据0x5555到此地址*/

Temp=(WORD far*)0xC0005555;/*设置地址为C000：5555h*/

*Temp=0xA0A0;/*写数据0xA0A0到此地址*/

*DestBuf=SrcWord;/*传送字节到目的地址*/

Check_Toggle_Ready(DestBuf);/*等待TOGGLF位准备好*/

}

源代码见网站收集整理。

3．5 Flash文件系统的工作流程

在使用Flash文件系统前，先将FlashROM设备加入设备表中（最开始假设Flash中没有任何文件），读入Flash文件表。下面简述系统工作流程。

（1）加入FlashROM设备

add_device(“FlashROM”,_MSA,flash_open,flash_close,flash_read,flash_write,flash_lseek,

flash_unlink,flash_rename);

其中flash_open、flash_close、flash_read、flsh_write、flash_lseek、flash_unlink、flash_rename是最底层的

flash驱动函数名称。针对不同的Flash，需要不同的驱动函数。

int flash_open(char *path,unsigned flags,int fno);

int flash_close(int fno);

int flash_read(int fno,char *buffer,unsigned count);

int flash_write(int fno,char *buffer,unsigned count);

（2）初始化文件系统

在使用Flash前，必须初始化。初始化临时文件缓冲区，将Flash的各种信息读入到系统中，如Flash的大小，存在的文件的名称、大小、建立日期等，这样系统才能正确使用Flash.

Init_eFS();/*初始化文件系统函数*/

（3）执行各种文件操作

如果要在Flash上打开一个文件，执行fopen(“FlashROM:\路径\文件名”，“打开模式”)就可以了。当打开文件时，先检查文件表中是否存在该文件。如果没有，则在Flash文件表中查找是否存在该文件。如果存在，则打开；如果没有，则新建这样一个文件，同时打开该文件。随后就可以进行文件的读写、追加、属性修改等操作。

该Flash文件系统的几个技术关键点：

①利用RTS.LIB(TI附带有源代码RTS.SRC)的高级层文件操作功能。该库已经按照ANSI C标准处理了高层文件应用问题。我们可以如同在上位机上编程一样使用各种文件操作函数，不同的是将盘符改为FlashROM盘符。例如，将fopen(“C:\read.txt”,“r”)改为fopen(“FlashROM:\read.txt”,“r”)。用这种模式操作Flash,的繁琐时序处理和扇区擦除等重复性问题，可以将精力集中到应用编程上来。

②用自设计的Low Level级代码接管了RTS.LIB的低层处理。前述的Flash文件信息表是核心，只有通过该表才能知道Flash中究竟有什么，在哪里操作。当在API层操作文件时，高层函数将调用相应的底层处理属数，在Low Level判断文件是否打开，是否可读写等属性。同时为该文件分配一个内缓冲区，所有对该文件的操作先操作缓冲区，即流操作。当缓冲区满时，调用的操作先操作缓冲区，即流操作。当缓冲区满时，调用Device Level级函数，将数据写入Flash中。同样，读取的时候，是先读取一个扇区内容，处理完毕后再读取下一扇区内容。

操作键盘等其它外设相对Flash要简单得多，不用设计文件信息表。执行两个步骤就可以使用。一是加入设备，调用add_device(……)函数，填入设备名；二是编写设备驱动函数，将对应的函数名作为参数传入add_device()中。在这里要说明的是，不同设备、同样的操作名其实际含义是不同的。如对键盘打开一个字符，则意味着读入一个字符，因此在实际中应用灵活处理。

结语

该Flash文件系统实现了基本的文件读写功能，但是还有些不足地方：文件共享问题没有解决，在掉电的情况下可能导致文件丢失。由于我们研制这个Flash系统的目的在于方便编程、调试；同时在我们的应用领域（电力系统继电保护）中，掉电的几率非常低，存储的文件主要是整定值、控制字（修改不多）和故障滤波记录。这些数据即使丢失也不会造成灾难性的后果，故该系统在整体

上满足我们的应用需求。

篇3：嵌入式系统中的线性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直接与笔者联系。

篇4：嵌入式系统中的线性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]

篇5：车载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存储器内容会有坏块，但是由于每一块的内部结构都是相互独立的，所以只要对其状态加以识别，坏块并不影响系统对有效块的操作。

(本网网收集整理)

篇6：车载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播放系统的应用。

★ ARM7系统中实现CF卡存储的文件系统设计

★ 拖动与碰撞的应用，Flash学习

★ 大容量NAND?Flash?TC58DVG02A1F

★ ppt教学课件制作技巧有哪些