在8051單片機應用系統中使用DiskOnChip

摘    要：本文以8051單片機為例探討了在8位單片機應用系統中，使用M-Systems公司的DiskOnChip作為大容量非易失數據存儲器的可行性，給出了在8051單片機應用系統中使用DiskOnChip的軟、硬件實(shí)現方案。
關(guān)鍵詞：?jiǎn)纹瑱C；嵌入式系統；DiskOnChip

前言
隨著(zhù)各種8051兼容單片機的功能和性能越來(lái)越強，其應用系統的智能化程度和復雜度也在不斷提高。在某些場(chǎng)合下對數據非易失存儲的容量要求已遠遠超過(guò)了64KB。為此，通常的解決方法是采用NOR型Flash存儲器，并采用分段式存儲器訪(fǎng)問(wèn)技術(shù)以擴展8051的尋址空間。這種方法增加了軟硬件設計的復雜性且可靠性較低，成本也較高。而DiskOnChip(簡(jiǎn)稱(chēng)DOC)是一種基于NAND型Flash存儲器的大容量固態(tài)存儲系列產(chǎn)品，在單一封裝內集成了大容量NAND Flash Memory和對Flash進(jìn)行操作的微控制器NFDC(Nand Flash Disk Controller)，其存儲容量從8MB直到1GB。各種容量均采用統一的DIP32封裝，并且管腳排列完全兼容，具有一致的外部硬件接口。如果能夠將其直接應用于8051單片機系統，則不僅擴展了DiskOnChip的應用范圍，而且對于這類(lèi)系統來(lái)說(shuō)將是一種非常理想的大容量、非易失數據存儲解決方案。為此本文探討了在8051單片機應用系統中使用DiskOnChip的可行性及軟、硬件實(shí)現方案。

硬件連接
由于DOC的外部硬件接口非常簡(jiǎn)單，以DOC 2000為例，它類(lèi)似于一個(gè)標準的SRAM，在系統中只占用8KB的地址空間，未超過(guò)8051單片機64KB的尋址范圍。因此，8051單片機可以很方便地與各種容量的DOC 2000直接連接，而無(wú)需擴展其尋址范圍。
在實(shí)際系統中，所選用的8051單片機的型號和生產(chǎn)廠(chǎng)商不限，但必須具有外部數據總線(xiàn)、地址總線(xiàn)及讀、寫(xiě)信號線(xiàn)，以便與DOC 2000連接。圖1是Atmel公司的8051兼容單片機AT89C55與一片DOC 2000連接實(shí)例的示意圖，其中DOC 2000在A(yíng)T89C55的數據存儲空間中占用8000H~9FFFH的地址范圍。
軟件移植
這是本文討論的重點(diǎn)。M-Systems公司將DOC內部Flash存儲介質(zhì)以“分區”的形式加以組織。有兩種類(lèi)型的分區：二進(jìn)制分區和文件分區。二進(jìn)制分區又稱(chēng)為BDK(Boot Developers Kit)分區，可用于存儲嵌入式操作系統的二進(jìn)制映像(Image)和其他二進(jìn)制數據，但不支持壞塊管理和損耗平衡(Wear-Leveling)技術(shù)。應用程序不能以文件形式訪(fǎng)問(wèn)BDK分區中的數據，只能通過(guò)M-Systems公司提供的BDK API讀/寫(xiě)BDK分區。BDK API以C語(yǔ)言源代碼形式提供，可由嵌入式系統的引導程序使用；文件分區又稱(chēng)為T(mén)rueFFS(True Flash File System)分區，它使應用程序可以通過(guò)操作系統的文件系統象訪(fǎng)問(wèn)磁盤(pán)文件一樣來(lái)讀/寫(xiě)DOC，并采用壞塊管理、損耗平衡等手段，實(shí)現了更高的存儲可靠性和更長(cháng)的Flash壽命。TrueFFS是純軟件技術(shù)，通過(guò)驅動(dòng)程序實(shí)現。M-Systems公司為Windows、WinCE、Linux、VxWorks等常見(jiàn)操作系統都提供了TrueFFS驅動(dòng)程序，并以C語(yǔ)言源代碼形式提供了TrueFFS SDK，供開(kāi)發(fā)者將TrueFFS移植到新的操作系統下或無(wú)操作系統的環(huán)境。
8051單片機對DOC中數據的存儲和訪(fǎng)問(wèn)類(lèi)似地也有兩種情形，一種是以二進(jìn)制形式，另一種是以文件形式。M-Systems公司提供的TrueFFS SDK實(shí)現了一個(gè)簡(jiǎn)化的文件系統FAT-Lite，可移植到無(wú)操作系統的環(huán)境。但8051單片機的程序存儲器和數據存儲器最大都只有64KB，而TrueFFS SDK比較復雜，不易移植到8051上。因此對于8051系統來(lái)說(shuō)，比較適合直接以二進(jìn)制形式來(lái)訪(fǎng)問(wèn)DOC 2000。為了在8051單片機上編程實(shí)現對DOC 2000的訪(fǎng)問(wèn)，必須了解DOC 2000的軟件接口的技術(shù)細節。如前文所述，DOC 2000在系統中占用8KB的地址空間，微處理器通過(guò)這8KB的窗口訪(fǎng)問(wèn)DOC內部的控制寄存器并進(jìn)行數據的傳輸，但M-Systems公司未公開(kāi)寄存器的定義和操作流程的技術(shù)細節，所以只能從M-Systems公司提供給應用開(kāi)發(fā)者的BDK API源代碼入手進(jìn)行移植。由于BDK API的較新版本采用了比較復雜的軟件架構，致使移植到8051難度較大，因此本文采用較早期的版本BDK 1.25，這個(gè)版本雖然只能支持128MB以下的DOC 2000和DOC Millennium(8MB)，但已可滿(mǎn)足絕大多數情況下8051應用系統對非易失存儲器的容量要求。
BDK 1.25向開(kāi)發(fā)者提供了讀/寫(xiě)BDK分區的一系列API函數，其源代碼采用ANSI C編寫(xiě)，并采用條件編譯以適應各種硬件平臺和操作系統，具有很好的可移植性。本文參考這些源代碼自行設計了一個(gè)適用于8051單片機的API函數庫，采用Keil C51編寫(xiě)，提供了對DOC 2000或DOC Millennium的基本存儲單元(塊、頁(yè))進(jìn)行讀、寫(xiě)、擦除操作的功能，實(shí)現了8051單片機以二進(jìn)制形式讀寫(xiě)DOC 2000或DOC Millennium。
由于篇幅所限，本文不詳述具體的移植過(guò)程，在此只說(shuō)明移植時(shí)主要考慮的幾個(gè)問(wèn)題：
* BDK API的源代碼缺省適用于X86處理器和DOS環(huán)境。為此需修改有關(guān)的條件編譯選項以使之適用于8051系統；
* 對源代碼進(jìn)行最大程度的簡(jiǎn)化和定制。為此修改了某些數據類(lèi)型以減小RAM占用量，簡(jiǎn)化了某些數據結構，重寫(xiě)了部分代碼，并去掉不必要的條件編譯和多余的代碼；
* 針對8051系統使用DOC的特點(diǎn)增加了若干條件編譯選項，以方便開(kāi)發(fā)者根據不同的應用需求對本API庫源代碼進(jìn)行“量身定制”，實(shí)現最小的代碼尺寸和最高的性能。例如可配置為自動(dòng)識別DOC 2000的容量等參數，以便在不修改軟件的情況下可直接更換不同容量的DOC 2000，也可配置成只適用于特定容量的DOC 2000以獲得較小的代碼尺寸。
這一API庫向應用開(kāi)發(fā)者提供如下4個(gè)API函數：
* DOC_Init —— 對DOC及有關(guān)的數據結構進(jìn)行初始化，需最先調用；
* DOC_ReadOnePage —— 讀DOC的一頁(yè)；
* DOC_WriteOnePage —— 寫(xiě)DOC的一頁(yè)，寫(xiě)之前必須先擦除該頁(yè)所在的塊；
* DOC_Erase —— 擦除DOC的一塊或多塊。
這些API函數在讀寫(xiě)DOC時(shí)支持EDC/ECC和寫(xiě)校驗等特性(可通過(guò)條件編譯選項使能或禁止這些特性)，從而可保證數據存儲具有很高的可靠性。此外本函數庫也包含了讀寫(xiě)每頁(yè)的16個(gè)“extra”字節的代碼，若需要可以調用。由于這些API函數直接讀寫(xiě)DOC的塊和頁(yè)，因此DOC在被連接到8051系統中之前無(wú)需用DFORMAT等工具進(jìn)行格式化，如果是已格式化的DOC，則在使用本API庫對其訪(fǎng)問(wèn)后原有的分區結構將被破壞。在實(shí)際應用中，開(kāi)發(fā)者還可以根據實(shí)際需求為DOC定義特定的分區格式及文件系統，在這4個(gè)API函數的基礎上實(shí)現對DOC更靈活的訪(fǎng)問(wèn)形式，例如以文件形式讀寫(xiě)DOC中的數據。
本API庫不支持M-Systems公司的壞塊管理、損耗平衡等技術(shù)，有興趣的讀者可參考TrueFFS SDK源代碼在本API庫的基礎上實(shí)現類(lèi)似的機制。
如前文所述，一片8051單片機可連接多片DOC，在這種情形下，每次訪(fǎng)問(wèn)不同的DOC之前都需要針對該DOC重新調用一次API函數DOC_Init(參數為該DOC的窗口地址)。
本API庫可用Keil C51 6.0以上版本編譯，適用于Keil C51所支持的各種8051兼容單片機。實(shí)際上，只要對源代碼稍作修改甚至不需修改就可以將本API庫移植到除8051之外的其他提供C語(yǔ)言編譯器的單片機上(當然該單片機在硬件上必須符合與DOC連接的條件才能真正訪(fǎng)問(wèn)DOC)。

軟件實(shí)測性能
本設計從代碼尺寸、RAM需求、對DOC的訪(fǎng)問(wèn)速度三方面對本API庫的性能進(jìn)行了實(shí)測。測試環(huán)境為：?jiǎn)纹瑱C選用AT89C55，晶振頻率為22.1184MHz，DOC選用DOC 2000 16MB(型號為MD2200-D16)，見(jiàn)圖1所示。
代碼尺寸：本API庫源代碼約一千余行，當使用 Keil C51 6.20c編譯并采用缺省代碼優(yōu)化級別時(shí)，在不同的條件編譯選項下，編譯后的庫目標代碼尺寸最小約為3.3KB，最大約為11.7KB。
RAM需求：DOC 2000本身占用8KB的數據存儲空間，本API占用約400B的RAM。此外由于DOC的最小擦除單元為8KB，因此在實(shí)際應用中如果需要隨機寫(xiě)DOC，還需要至少8KB的外部RAM用于數據緩存。
根據M-Systems公司提供的規格，對DOC 2000的持續讀、寫(xiě)速度分別可達1.4MB/s和500KB/s，但當DOC 2000應用于8051系統時(shí)，由于8051本身速度慢所造成的瓶頸，使對DOC 2000的實(shí)際訪(fǎng)問(wèn)速度有所降低，實(shí)測速度為：讀一頁(yè)約需8ms、寫(xiě)一頁(yè)約需9ms、擦除一塊約需4ms。當本API庫采用不同的條件編譯選項時(shí)，對DOC的訪(fǎng)問(wèn)速度略有差異。另外，對不同型號的DOC的訪(fǎng)問(wèn)速度也略有差異。通過(guò)提高8051的晶振頻率或采用增強型的高速8051(如DS80C320)可在一定程度上提高對DOC的訪(fǎng)問(wèn)速度。

結語(yǔ)
在以8051為代表的8位單片機應用系統中使用M-Systems公司的DiskOnChip作為大容量非易失數據存儲器，具有硬件連接簡(jiǎn)單、成本低、可靠性高等諸多優(yōu)點(diǎn)，是一種值得推廣的方案，同時(shí)也擴展了DiskOnChip的應用范圍。本文介紹的軟、硬件實(shí)現方案適用于在8051系統中使用128MB以下的DOC 2000或DOC Millennium(8MB)，現已成功地應用于實(shí)際產(chǎn)品中。除8051之外，對于其他8位或16位單片機應用系統也可以參考本方案的思路和方法來(lái)實(shí)現對DOC的訪(fǎng)問(wèn)?！?/P>

參考文獻
1  M-Systems,DiskOnChip 2000 DIP Data Sheet,2002.7
2  M-Systems,DiskOnChip Boot Developers Kit,2001.1
3  M-Systems,TrueFFS Software Development Kit (SDK) Quick Reference Guide,2002.11