1、引言
随着嵌入式系统应用领域的不断扩大，系统复杂性也在不断提高。闪存作为广泛使用的嵌入式存储设备，其管理技术和访问方式经历了一个由开发员直接控制到由操作系统的I/O软件间接控制的过程。然而目前现有的这些闪存管理方案都不能提供一种方便、统一且移植性好的I/O软件
接口，增加了嵌入式产品的研发周期。因此，本文旨在针对一般的嵌入式应用，设计并实现一种更合理的闪存I/O软件。该软件遵循策略与机制分离的原则，采用分层的体系结构，能够更好得适应底层硬件的变化，可大大提高代码的可移植性。
2、闪存设备管理技术的现状及存在的问题
闪存设备不同于一般的非易失性存储设备，它有很多特殊的存取特性，其中主要的在执行写入操作之前必须先擦除目标单元的内容[1]。因此，闪存设备的管理基本也应该包含对读、写操作以及擦除操作的
控制。
对于那些用于工控领域的嵌入式系统，由于它们没有配置操作系统，整个系统的软件部分仅由主控程序和一些辅助功能例程构成，所以用户只能通过系统提供的闪存读写例程直接对闪存进行访问，同时擦除操作执行的时机也需要由用户自己控制。这样一来，访问闪存的应用程序就必须了解闪存的物理特性，如尺寸、擦除块的地址、大小和操作时间等，从而增加了开发难度，降低了代码的可移植性。此外，由于闪存的无结构性，应用程序还需要自己管理存储空间，并按照需要构造数据的存储格式[2]。
而对于那些配置了操作系统的复杂嵌入式系统（例如嵌入式Linux系统），闪存设备的管理则主要是通过操作系统中的I/O软件来实现。该I/O软件遵循Linux通用设备的管理方法[3]，实现了字符访问与块访问的接口，为应用程序访问闪存提供了一个通用接口。但问题是，该方案在设计软件结构时没有很好地遵循策略与机制分离的原则，从而使得软件结构的层次不够分明，模块化程度不高。
另外，在嵌入式Linux系统中还有一种与使用闪存相关的技术，即Ramdisk[4]技术。准确地说，该技术不涉及闪存的管理问题，而是一种通过将计算机的 RAM 用作设备来创建和挂装文件系统的机制。本文在此提及该技术的原因是它能够帮助只含闪存和RAM的嵌入式系统使用文件系统（主要指ext2fs类型），并且该技术的存在大大降低了嵌入式系统对闪存的访问操作，从而简化了系统对闪存的管理。但是，由于Ramdisk技术不能直接在闪存上使用文件系统，使得修改后的数据不能立刻保存到闪存中，所以在系统异常时容易造成数据的丢失。
经过分析，我们发现上述三种方法在闪存管理方面各有优缺点并各有适用范围。但是随着JFFS这种闪存专用文件系统的出现和不断完善以及嵌入式Linux操作系统应用的不断深入，越来越多的嵌入式系统开始采用第二种方式管理闪存设备。该方案在一定程度上简化了应用程序对闪存的访问操作，但由于其不清晰的软件结构造成了软件移植性能差的缺点。
3、闪存设备I/O软件的分层结构 为了解决上述第二种闪存管理软件存在的问题，我们在遵循策略与机制分离原则的基础上，设计出一种更合理的闪存I/O软件体系结构。具体内容如下（图1）。
我们设计的闪存I/O软件自下而上被划分为四个层次，分别为硬件驱动层、原始设备层、设备层以及设备节点。其中硬件驱动层代码主要负责在系统启动时驱动闪存硬件。从抽象层次上看，它是通过使用底层的硬件机制，建立了若干基本的使用闪存硬件的策略代码。具体过程由芯片探测模块和操作方法模块来实现的。其中芯片探测模块主要负责探测CFI接口闪存芯片的器件数信息[5]，包括芯片大小、芯片编程电压、编程时间、擦除时间、擦除区域分布情况等，并利用这些信息创建出描述芯片物理特性的数据结构。而操作方法模块则负责实现基本的闪存读、写及擦除例程。该模块在芯片探测模块的基础上，利用硬件的物理信息就能够实现特定闪存芯片的管理和访问方法。
接下来原始设备层代码就把闪存存储区从软件上划分为几个不同的区域，并用设备的概念对各分区进行软件上的封装，使每个分区设备都拥有包含自身信息的数据结构及设备操作例程。这样设计的原因，一方面是为了模拟硬盘的物理分区，方便系统对闪存的管理和使用；另一方面又为上层软件以字符方式和块方式访问闪存提供了基础。具体过程需要通过原始设备实现模块、设备分区实现模块来实现，而闪存配置管理模块则为开发人员根据自身需要任意划分闪存分区提供了配置接口，提高了系统的灵活性。需要说明的是这三个模块的实现具有一定的依赖关系，其中箭头的起始端模块要依赖于该箭头指向的模块。
接着闪存设备层代码在低层软件分区的基础上，用字符设备和块设备两种方式来使用闪存原始设备。具体说，该层主要实现字符设备与块设备的通用接口例程，即文件操作的通用方法，如打开、关闭、定位、读、写等。
，闪存设备节点层是为了方便应用程序以文件形式访问闪存设备而创建的设备节点。它的实现并不
需要软件代码。
4、闪存设备I/O软件的实现
嵌入式开发一般都采用主机与目标板相结合的交叉开发方式。因此我们的目标板采用的是Motorola公司基于PowerPC860T处理器的一个网络通信设备
开发板（以下简称为NE860）。NE860板上配备有4M NOR型闪存和16M RAM作为
存储器，其中闪存采用的是两片Intel TE28F160B3T的芯片。主机是一台运行Redhat 7.2 的PC机，该主机上还安装有Montavista 嵌入式Linux（以下简称MVL）作为实现闪存I/O软件的载体。具体实现过程如下：
(1) 硬件驱动层
由于NOR型闪存芯片的接口不同与一般基于端口的外部设备，不能够被清晰地划分为几个不同用途的端口寄存器；该接口只包括了几条控制
信号线，一组
数据线和一组地址线。这样一来，闪存的数据读写操作以及命令写入和状态查询操作都需要在同一组数据线上进行。同时由于完备的地址线能够让系统对芯片内的每个字节进行寻址，于是闪存的擦除、写入等基本操作就可以通过向特定地址写入特定命令序列[6]的方式来实现的。因此我们的系统在遵循各种操作的特定指令序列[6]基础上，结合特定芯片的物理信息（保存在专用数据结构struct cfi_private中）实现了闪存的读、写、擦除和同步操作。
（2）原始设备层
原始设备层的主要功能是在硬件基础上把闪存芯片抽象为设备。为了实现这一目标，系统首先要把所有的闪存芯片抽象为一个闪存主原始设备，然后再根据用户的分区划分要求（通过管理配置模块获得）把主原始设备从软件上划分为多个分区设备。这样一来，分区设备的大部分参数信息实际上都来自于主原始设备，并且分区设备的操作函数也都来自于主原始设备的操作函数。而这些操作的实现是通过调用底层的基本操作完成的。
（3）设备层
闪存设备层主要用来实现字符设备与块设备的通用接口例程，其中字符设备的各种操作都比较容易实现。这里我们着重介绍一下块设备的实现。在Linux中，由于块设备的读写请求都是基于扇区（512字节）的，而闪存设备却不存在物理上的扇区结构，只有擦出块的概念。况且在通常情况下擦除块的尺寸都小于512字节，这样一来就存在一个如何把基于扇区的读写操作映射到适当的擦除块上的问题。由于块设备主要是为了支持在闪存上创建文件系统，所以该问题的解决我们就借用了JFFS文件系统中有关的设计思想（由于篇幅所限这里不详述）。
5、系统测试及数据分析
为了验证该闪存I/O软件的可移植性和正确性，我们做如下的分析和测试。：通过统计闪存I/O软件中设备相关代码及设备无关代码的比例，说明该实现方案的可移植性；第二：通过对闪存I/O软件子系统一些典型性能指标的测试，说明该I/O软件结构设计的正确性和有效性。
（1）闪存I/O软件可移植性的验证
从理论上讲，只有硬件设备驱动层的一部分代码是与设备相关的，而原始设备层和设备层代码都是设备无关的。于是，我们得出如下（表1）的统计结果。在新的I/O软件实现方案下，闪存设备相关代码为35KB，占总代码量的24.1%；设备无关代码为110KB，占总代码量的75.9%。由此可见，我们的实现方案具有很好的移植性，能够有效地提高嵌入式产品的开发速度和质量。
（2）闪存I/O软件有效性的验证
I/O软件的一个重要性能指标是设备的数据吞吐率。当应用程序访问闪存设备文件时，由于每次读/写请求的数据度不同，使得设备的瞬时吞吐率也不同。由于我们的I/O系统实现了闪存设备的两种管理方式：字符设备和块设备，因此下面我们首先针对字符设备方式测试它的读/写吞吐率（见图2 和图3）。
通过分析图2、图3的数据我们发现，当系统从闪存设备中读取或写入小块数据时，吞吐率会随着请求数据长度的增加而增大；但是当请求数据长度超过某一临界值时，读/写吞吐率近似都稳定在一个固定值上。
为了进一步验证上述规律，我们又按照33%的写请求和67%的读请求比例，对各种请求数据长度进行了10次读/写混合操作测试，其结果如图4所示。由此可看出，在请求数据长度大于512KB之后，读写混合的数据吞吐率稳定在3.59MB/S上，这一结果与图2和图3所示结果完全一致。并且该吞吐率变化规律符合常见嵌入式应用中闪存的读、写特性，其指标也基本上能够达到应用需求。
对于块设备方式，我们主要测试基于闪存文件系统的一些典型文件操作性能。其结果如表2所示。该表的列代表了执行的文件操作，其中create和wirte代表创建文件并向该文件写入X个字节数据的操作；open和read则代表打开文件并从该文件读出X个字节数据的操作。X的大小按照表中行数值的变化而变化。测试数据表明闪存I/O软件块设备功能是正确和有效的。
6、结束语
本文在分析了嵌入式系统现有的各种闪存管理技术缺点的基础上，设计并实现了一种分层合理、模块划分清晰且移植性好的闪存I/O软件。系统的测试数据表明，该I/O软件能够实现对闪存设备的基本管理和访问，可以满足一般嵌入式系统对数据存储器的应用需要。另一方面，由于硬件平台的资源所限，我们只实现了对NOR型闪存的管理；随着性能更优的NAND型闪存的广泛使用，我们下一步的工作就是要将上述软件代码移植到NAND型闪存器件上，进一步检验该软件的性能。
