摘要：在此以杭州中天32位RISC CPU CK510為內核的HMl521_B芯片上，基于μC／OS-Ⅱ操作系統，實現對USB設備的讀寫控制。系統采用嵌入式USB主機控制軟件的分層結構，著重闡述FAT32文件系統、USB設備枚舉和BULK-ONLY傳輸的具體實現過程。為了節省硬件資源，放棄了USB協議中的繁文縟節，抓住協議核心，設計了精簡高效的驅動程序。考慮到各種U盤的不同特性，增強了驅動兼容性方面的設計。整個階段都由邏輯分析儀給出實測數據抓包截圖。
關鍵詞：嵌入式USB控制；FAT32文件系統；USB設備枚舉；Bulk-only傳輸
0 引言
2010年USB 3．0的正式推出象征USB傳輸極速時代的到來，但是嵌入式領域由于考慮成本等各方面因素很多仍采用USB 1．1協議。同時USB協議的主體框架并沒有改變，因此研究USB 1．1協議在嵌入式系統上的實現對于USB 3．0協議的應用也是很好的鋪墊。本文在以杭州中天32位RISC CPU CK510為內核的摩托羅拉HM1521_B芯片上，基于μC／OS-Ⅱ操作系統，實現對USB設備的讀寫控制。由于HM1521_B芯片只支持USB 1．1協議，所以本文實現的只是USB 1．1協議。USB是一種主從結構：主機Host和從機Device。所有的數據傳輸都由Host主動發起，而Device只是被動的負責應答。在USB OTG中，一個設備可以在Device和Host之間切換，用以實現設備與設備之間的連接，大大增加了USB的使用范圍。但USBOTG依然沒有脫離主從關系，設備之間必然有一個作為Host，另一個作為Device。標準的USB使用4根線，分別是5 V電源、差分數據線負(D-)、差分數據線正(D+)、地(GND)。USB的低速和全速模式采用電壓傳輸，高速模式則采用電流傳輸。
1 USB控制軟件的分層結構
按照USB協議規范，USB運行首先是USB Host通過D+數據線上的電平變化檢測USB Device的插入和拔出，Host和Device依據協議規定的順序執行一系列信息交換，這稱為枚舉部分，也是所有USB主機都必須支持的功能。Host根據獲得的Device信息判斷該Device屬于哪一類USB設備，并確定下一步選用哪個特定的程序加以支持。
USB協議規定了HID(人機接口設備)類、Mass Storage(大容量存儲設備，如U盤)類、音頻類等各種設備類型。在嵌入式系統中，由于受系統性能和存儲空間的限制，一般只能支持某幾個類型。本文只支持Mass Storage類。
圖1是本文實現的USB Host控制軟件的分層結構：應用層調用FAT32文件系統層的函數；文件系統層通過MassStorage UFI命令與存儲設備建立聯系，實現U盤上文件的建立和讀寫等一系列操作；最底層的是Mass Storage驅動模塊，實現對U盤數據的讀寫功能。其主要函數包括：
本文軟件用C語言編程，并依賴μC／OS-Ⅱ操作系統提供的中斷函數來調度各個函數的運行。
2 FAT32文件系統的實現
文件系統的作用是對文件在介質上的存儲進行管理，并為操作系統提供操作函數。若把U盤看成是以扇區為單位的邏輯盤(1扇區=512 B)，當一個U盤被格式化成FAT32格式的分區后，它的結構形式圖如圖2所示。
引導扇區(DOS Boot Record，DBR)存儲了本分區的BPB(Bios Parameter Block)信息。主引導記錄MBR(Master Boot Record)是物理上第一個扇區，絕對扇區號是0，它獨立于任何一個分區。MBR的前446B是系統引導程序，接著的64個字節是分區表DPT(Disk Partition Table)，最后兩字節是扇區有效標志55 AA。初始化一個U盤的文件系統，很重要的一步就是填寫引導扇區的過程。對有些關鍵字節進行分析如下所示：
FAT32文件系統中，FAT表是一個數據表，以簇(cluster)的形式鏈式存放。當一個文件大于一簇(4個扇區)時，每簇中存放的數據便是文件存放的下一簇地址。直到遇到簇中的數據為“FF FF”時，才表示此文件已至尾簇。數據內容不連續地存放于數據區內。文件系統使用設備驅動提供的4個函數獲取設備的狀態信息以及實現對設備的讀寫。
3 USB設備枚舉的實現
枚舉就是從Deveice讀取信息，通過設備描述符設備告訴Host是什么設備、如何進行通信，Host根據這些信息來加載合適的驅動程序。
3．1 枚舉過程及實現
USB是一種主從的結構，所有傳輸由Host來發起。當Host發起一次傳輸時，通常包括3個包(Packets)的傳輸。Host首先是發送一個Token Packet，包含本次傳輸的命令類型(Type)、方向(Direction)、設備的地址(Device Address)以及端點號(Endpoint)；緊接著發送數據包(Da-ta Packet)，包含要求Device返回描述符的命令數據；最后由Device返回握手信號包(handshake packet)，正確返回(ACK)命令。
USB Host檢測到有Device插入后，進行總線復位。然后Host使用默認地址0讀取設備描述符。獲取設備描述符的USB設備請求命令結構體為：
第1次讀取設備描述符時，Host首先發送setup包；之后進入主機讀取數據階段，Host發送in包，Device返回一個18 B的設備描述符，可以用一個結構體將其讀回。最后Host發送0 B的數據包作為狀態相應，設備返回ACK作為應答。用邏輯分析儀抓包，3個包如圖3所示。
第1次讀取設備描述符后，Host依次進行地址分配、第2次讀取設備描述符、讀取配置描述符、讀取描述符集、設置配置、讀取配置狀態和讀取接口狀態，方法和第1次讀取設備描述符的方法一樣。
3．2 U盤兼容性
在設備枚舉階段將會碰到很多關于U盤兼容性的問題。
(1)總線復位時間。不同型號的U盤對于總線復位時間的要求是不同的，比如金士頓1 GB的U盤需要的復位時間至少280 ms。在實現中為保險起見，給予400 ms的復位時間。
(2)有些U盤的端點0是8 B payload的，大多數是64 B。對于8 B payload的U盤，要嚴格從第1次獲取設備描述符時返回的第8字節獲取payload，否則盡管枚舉過程仍然能通過，但是后面在分析32字節的配置描述符時候會出現問題，沒有收到完整的配置描述符是分析不出端點1和端點2的地址以及端點payload的。
(3)在枚舉階段獲取字符串描述符的時候，要進行判斷。因為有些U盤不支持返回字符串描述符，用if語句判斷，如果獲取不到字符串描述符就跳過，不要返回失敗。
4 Bulk-only傳輸的實現
枚舉結束后是對塊設備的讀寫。Bulk-Only傳輸規范是USB組織針對大容量存儲設備制定的一種塊存儲類協議，它僅僅使用Bulk端點來傳送數據／命令／狀態。
圖4是數據／命令／狀態在USB總線上的傳輸流程圖。根據此圖Bulk-only傳輸的狀態可以定義為：空閑、CBW處理、數據輸出(從Host向Device傳輸數據)、數據輸入(從Device向Host傳輸數據)、CSW處理、管道阻塞等6種狀態。在空閑狀態下，接收到的數據包為CBW包；在數據輸出狀態下，接收到的數據包為Host期待寫入Device的數據；在數據輸入狀態下，Host請求從Device讀取數據，Device將向Host發送這些數據包；在CSW狀態下，Device封裝并發送CSW包以向Host返回狀態信息。因此，任何Bulk-Only事務均是以Host向Device發送CBW包并試圖建立相應的數據傳輸開始的；而Device接收到CBW包，進行檢查并解釋，試圖滿足Host的要求，并通過CSW向主機返回狀態信息。以讀一個邏輯塊為例，填寫一個CBW包的程序如下所示：
邏輯分析儀抓包結果如圖5所示。從抓包結果可以清晰的看出CBW包由31個字節組成。
CBW包和CSW包正確收發后，Bulk-only傳輸就能順利實現。完成對扇區的讀寫，文件系統的掛載。上層應用程序使用文件系統提供的API，操作底層設備，實現對文件的建立、讀寫、刪除等操作。經測試本系統支持長文件名和超過2 GB容量的USB設備。本設計最終實現了在不同型號U盤上完成對長文件名文件的新建、讀寫以及刪除操作。
5 結語
本設計在以CK510為內核的HM1521_B芯片上，通過文件系統實現了對USB設備的讀寫操作。程序代碼放棄了USB協議中的繁文縟節，抓住協議核心以達到精簡高效之目的。在大容量USB存儲設備的兼容性方面也進行了探討。經測試本系統支持長文件名和超過2 GB容量的USB設備。最終實現了在不同型號U盤上完成對長文件名文件的新建、讀寫以及刪除操作。
本系統尚需改進的地方主要是讀寫過程中的出錯應對能力。如何應對USB設備在讀寫過程中的突然拔插，以及如何提高數據傳輸出錯時的校驗能力都是本課題進一步研究的方向。