在8051單片機(jī)應(yīng)用系統(tǒng)中使用DiskOnChip

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

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

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

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

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

參考文獻(xiàn)
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