在8051单片机应用系统中使用DiskOnChip

前言
　　随着各种8051兼容单片机的功能和性能越来越强，其应用系统的智能化程度和复杂度也在不断提高。在某些场合下对数据非易失存储的容量要求已远远超过了64KB。为此，通常的解决方法是采用NOR型Flash存储器，并采用分段式存储器访问技术以扩展8051的寻址空间。这种方法增加了软硬件设计的复杂性且可靠性较低，成本也较高。而DiskOnChip(简称DOC)是一种基于NAND型Flash存储器的大容量固态存储系列产品，在单一封装内集成了大容量NAND Flash Memory和对Flash进行操作的微控制器NFDC(Nand Flash Disk Controller)，其存储容量从8MB直到1GB。各种容量均采用统一的DIP32封装，并且管脚排列完全兼容，具有一致的外部硬件接口。如果能够将其直接应用于8051单片机系统，则不仅扩展了DiskOnChip的应用范围，而且对于这类系统来说将是一种非常理想的大容量、非易失数据存储解决方案。为此本文探讨了在8051单片机应用系统中使用DiskOnChip的可行性及软、硬件实现方案。

硬件连接
　　由于DOC的外部硬件接口非常简单，以DOC 2000为例，它类似于一个标准的SRAM，在系统中只占用8KB的地址空间，未超过8051单片机64KB的寻址范围。因此，8051单片机可以很方便地与各种容量的DOC 2000直接连接，而无需扩展其寻址范围。

　　在实际系统中，所选用的8051单片机的型号和生产厂商不限，但必须具有外部数据总线、地址总线及读、写信号线，以便与DOC 2000连接。图1是Atmel公司的8051兼容单片机AT89C55与一片DOC 2000连接实例的示意图，其中DOC 2000在AT89C55的数据存储空间中占用8000H~9FFFH的地址范围。

软件移植
　　这是本文讨论的重点。M-Systems公司将DOC内部Flash存储介质以“分区”的形式加以组织。有两种类型的分区：二进制分区和文件分区。二进制分区又称为BDK(Boot Developers Kit)分区，可用于存储嵌入式操作系统的二进制映像(Image)和其他二进制数据，但不支持坏块管理和损耗平衡(Wear-Leveling)技术。应用程序不能以文件形式访问BDK分区中的数据，只能通过M-Systems公司提供的BDK API读/写BDK分区。BDK API以C语言源代码形式提供，可由嵌入式系统的引导程序使用；文件分区又称为TrueFFS(True Flash File System)分区，它使应用程序可以通过操作系统的文件系统象访问磁盘文件一样来读/写DOC，并采用坏块管理、损耗平衡等手段，实现了更高的存储可靠性和更长的Flash寿命。TrueFFS是纯软件技术，通过驱动程序实现。M-Systems公司为Windows、WinCE、Linux、VxWorks等常见操作系统都提供了TrueFFS驱动程序，并以C语言源代码形式提供了TrueFFS SDK，供开发者将TrueFFS移植到新的操作系统下或无操作系统的环境。

　　8051单片机对DOC中数据的存储和访问类似地也有两种情形，一种是以二进制形式，另一种是以文件形式。M-Systems公司提供的TrueFFS SDK实现了一个简化的文件系统FAT-Lite，可移植到无操作系统的环境。但8051单片机的程序存储器和数据存储器最大都只有64KB，而TrueFFS SDK比较复杂，不易移植到8051上。因此对于8051系统来说，比较适合直接以二进制形式来访问DOC 2000。为了在8051单片机上编程实现对DOC 2000的访问，必须了解DOC 2000的软件接口的技术细节。如前文所述，DOC 2000在系统中占用8KB的地址空间，微处理器通过这8KB的窗口访问DOC内部的控制寄存器并进行数据的传输，但M-Systems公司未公开寄存器的定义和操作流程的技术细节，所以只能从M-Systems公司提供给应用开发者的BDK API源代码入手进行移植。由于BDK API的较新版本采用了比较复杂的软件架构，致使移植到8051难度较大，因此本文采用较早期的版本BDK 1.25，这个版本虽然只能支持128MB以下的DOC 2000和DOC Millennium(8MB)，但已可满足绝大多数情况下8051应用系统对非易失存储器的容量要求。

　　BDK 1.25向开发者提供了读/写BDK分区的一系列API函数，其源代码采用ANSI C编写，并采用条件编译以适应各种硬件平台和操作系统，具有很好的可移植性。本文参考这些源代码自行设计了一个适用于8051单片机的API函数库，采用Keil C51编写，提供了对DOC 2000或DOC Millennium的基本存储单元(块、页)进行读、写、擦除操作的功能，实现了8051单片机以二进制形式读写DOC 2000或DOC Millennium。

　　由于篇幅所限，本文不详述具体的移植过程，在此只说明移植时主要考虑的几个问题：

　　* BDK API的源代码缺省适用于X86处理器和DOS环境。为此需修改有关的条件编译选项以使之适用于8051系统；

　　* 对源代码进行最大程度的简化和定制。为此修改了某些数据类型以减小RAM占用量，简化了某些数据结构，重写了部分代码，并去掉不必要的条件编译和多余的代码；[page]

　　* 针对8051系统使用DOC的特点增加了若干条件编译选项，以方便开发者根据不同的应用需求对本API库源代码进行“量身定制”，实现最小的代码尺寸和最高的性能。例如可配置为自动识别DOC 2000的容量等参数，以便在不修改软件的情况下可直接更换不同容量的DOC 2000，也可配置成只适用于特定容量的DOC 2000以获得较小的代码尺寸。

　　这一API库向应用开发者提供如下4个API函数：
* DOC_Init —— 对DOC及有关的数据结构进行初始化，需最先调用；
* DOC_ReadOnePage —— 读DOC的一页；
* DOC_WriteOnePage —— 写DOC的一页，写之前必须先擦除该页所在的块；
* DOC_Erase —— 擦除DOC的一块或多块。

　　这些API函数在读写DOC时支持EDC/ECC和写校验等特性(可通过条件编译选项使能或禁止这些特性)，从而可保证数据存储具有很高的可靠性。此外本函数库也包含了读写每页的16个“extra”字节的代码，若需要可以调用。由于这些API函数直接读写DOC的块和页，因此DOC在被连接到8051系统中之前无需用DFORMAT等工具进行格式化，如果是已格式化的DOC，则在使用本API库对其访问后原有的分区结构将被破坏。在实际应用中，开发者还可以根据实际需求为DOC定义特定的分区格式及文件系统，在这4个API函数的基础上实现对DOC更灵活的访问形式，例如以文件形式读写DOC中的数据。

　　本API库不支持M-Systems公司的坏块管理、损耗平衡等技术，有兴趣的读者可参考TrueFFS SDK源代码在本API库的基础上实现类似的机制。

　　如前文所述，一片8051单片机可连接多片DOC，在这种情形下，每次访问不同的DOC之前都需要针对该DOC重新调用一次API函数DOC_Init(参数为该DOC的窗口地址)。

　　本API库可用Keil C51 6.0以上版本编译，适用于Keil C51所支持的各种8051兼容单片机。实际上，只要对源代码稍作修改甚至不需修改就可以将本API库移植到除8051之外的其他提供C语言编译器的单片机上(当然该单片机在硬件上必须符合与DOC连接的条件才能真正访问DOC)。

软件实测性能
　　本设计从代码尺寸、RAM需求、对DOC的访问速度三方面对本API库的性能进行了实测。测试环境为：单片机选用AT89C55，晶振频率为22.1184MHz，DOC选用DOC 2000 16MB(型号为MD2200-D16)。

　　代码尺寸：本API库源代码约一千余行，当使用 Keil C51 6.20c编译并采用缺省代码优化级别时，在不同的条件编译选项下，编译后的库目标代码尺寸最小约为3.3KB，最大约为11.7KB。

　　RAM需求：DOC 2000本身占用8KB的数据存储空间，本API占用约400B的RAM。此外由于DOC的最小擦除单元为8KB，因此在实际应用中如果需要随机写DOC，还需要至少8KB的外部RAM用于数据缓存。

　　根据M-Systems公司提供的规格，对DOC 2000的持续读、写速度分别可达1.4MB/s和500KB/s，但当DOC 2000应用于8051系统时，由于8051本身速度慢所造成的瓶颈，使对DOC 2000的实际访问速度有所降低，实测速度为：读一页约需8ms、写一页约需9ms、擦除一块约需4ms。当本API库采用不同的条件编译选项时，对DOC的访问速度略有差异。另外，对不同型号的DOC的访问速度也略有差异。通过提高8051的晶振频率或采用增强型的高速8051(如DS80C320)可在一定程度上提高对DOC的访问速度。

结语
　　在以8051为代表的8位单片机应用系统中使用M-Systems公司的DiskOnChip作为大容量非易失数据存储器，具有硬件连接简单、成本低、可靠性高等诸多优点，是一种值得推广的方案，同时也扩展了DiskOnChip的应用范围。