前言

随着各种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占用量，简化了某些数据结构，重写了部分代码，并去掉不必要的条件编译和多余的代码；