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