《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > 基于μC/OS-Ⅱ的嵌入式USB控制軟件的實現(xiàn)
基于μC/OS-Ⅱ的嵌入式USB控制軟件的實現(xiàn)
現(xiàn)代電子技術
金天驕,馬 琪,毛 銳
摘要: 在此以杭州中天32位RISC CPU CK510為內核的HMl521_B芯片上,基于μC/OS-Ⅱ操作系統(tǒng),實現(xiàn)對USB設備的讀寫控制。系統(tǒng)采用嵌入式USB主機控制軟件的分層結構,著重闡述FAT32文件系統(tǒng)、USB設備枚舉和BULK-ONLY傳輸?shù)木唧w實現(xiàn)過程。為了節(jié)省硬件資源,放棄了USB協(xié)議中的繁文縟節(jié),抓住協(xié)議核心,設計了精簡高效的驅動程序。考慮到各種U盤的不同特性,增強了驅動兼容性方面的設計。整個階段都由邏輯分析儀給出實測數(shù)據(jù)抓包截圖。
Abstract:
Key words :

摘要:在此以杭州中天32位RISC CPU CK510為內核的HMl521_B芯片上,基于μC/OS-Ⅱ操作系統(tǒng),實現(xiàn)對USB設備的讀寫控制。系統(tǒng)采用嵌入式USB主機控制軟件的分層結構,著重闡述FAT32文件系統(tǒng)、USB設備枚舉和BULK-ONLY傳輸?shù)木唧w實現(xiàn)過程。為了節(jié)省硬件資源,放棄了USB協(xié)議中的繁文縟節(jié),抓住協(xié)議核心,設計了精簡高效的驅動程序。考慮到各種U盤的不同特性,增強了驅動兼容性方面的設計。整個階段都由邏輯分析儀給出實測數(shù)據(jù)抓包截圖。
關鍵詞:嵌入式USB控制;FAT32文件系統(tǒng);USB設備枚舉;Bulk-only傳輸

0 引言
    2010年USB 3.0的正式推出象征USB傳輸極速時代的到來,但是嵌入式領域由于考慮成本等各方面因素很多仍采用USB 1.1協(xié)議。同時USB協(xié)議的主體框架并沒有改變,因此研究USB 1.1協(xié)議在嵌入式系統(tǒng)上的實現(xiàn)對于USB 3.0協(xié)議的應用也是很好的鋪墊。本文在以杭州中天32位RISC CPU CK510為內核的摩托羅拉HM1521_B芯片上,基于μC/OS-Ⅱ操作系統(tǒng),實現(xiàn)對USB設備的讀寫控制。由于HM1521_B芯片只支持USB 1.1協(xié)議,所以本文實現(xiàn)的只是USB 1.1協(xié)議。USB是一種主從結構:主機Host和從機Device。所有的數(shù)據(jù)傳輸都由Host主動發(fā)起,而Device只是被動的負責應答。在USB OTG中,一個設備可以在Device和Host之間切換,用以實現(xiàn)設備與設備之間的連接,大大增加了USB的使用范圍。但USBOTG依然沒有脫離主從關系,設備之間必然有一個作為Host,另一個作為Device。標準的USB使用4根線,分別是5 V電源、差分數(shù)據(jù)線負(D-)、差分數(shù)據(jù)線正(D+)、地(GND)。USB的低速和全速模式采用電壓傳輸,高速模式則采用電流傳輸。

1 USB控制軟件的分層結構
    按照USB協(xié)議規(guī)范,USB運行首先是USB Host通過D+數(shù)據(jù)線上的電平變化檢測USB Device的插入和拔出,Host和Device依據(jù)協(xié)議規(guī)定的順序執(zhí)行一系列信息交換,這稱為枚舉部分,也是所有USB主機都必須支持的功能。Host根據(jù)獲得的Device信息判斷該Device屬于哪一類USB設備,并確定下一步選用哪個特定的程序加以支持。
    USB協(xié)議規(guī)定了HID(人機接口設備)類、Mass Storage(大容量存儲設備,如U盤)類、音頻類等各種設備類型。在嵌入式系統(tǒng)中,由于受系統(tǒng)性能和存儲空間的限制,一般只能支持某幾個類型。本文只支持Mass Storage類。

b.jpg


    圖1是本文實現(xiàn)的USB Host控制軟件的分層結構:應用層調用FAT32文件系統(tǒng)層的函數(shù);文件系統(tǒng)層通過MassStorage UFI命令與存儲設備建立聯(lián)系,實現(xiàn)U盤上文件的建立和讀寫等一系列操作;最底層的是Mass Storage驅動模塊,實現(xiàn)對U盤數(shù)據(jù)的讀寫功能。其主要函數(shù)包括:
a.jpg
    本文軟件用C語言編程,并依賴μC/OS-Ⅱ操作系統(tǒng)提供的中斷函數(shù)來調度各個函數(shù)的運行。

2 FAT32文件系統(tǒng)的實現(xiàn)
    文件系統(tǒng)的作用是對文件在介質上的存儲進行管理,并為操作系統(tǒng)提供操作函數(shù)。若把U盤看成是以扇區(qū)為單位的邏輯盤(1扇區(qū)=512 B),當一個U盤被格式化成FAT32格式的分區(qū)后,它的結構形式圖如圖2所示。

c.jpg


    引導扇區(qū)(DOS Boot Record,DBR)存儲了本分區(qū)的BPB(Bios Parameter Block)信息。主引導記錄MBR(Master Boot Record)是物理上第一個扇區(qū),絕對扇區(qū)號是0,它獨立于任何一個分區(qū)。MBR的前446B是系統(tǒng)引導程序,接著的64個字節(jié)是分區(qū)表DPT(Disk Partition Table),最后兩字節(jié)是扇區(qū)有效標志55 AA。初始化一個U盤的文件系統(tǒng),很重要的一步就是填寫引導扇區(qū)的過程。對有些關鍵字節(jié)進行分析如下所示:

e.jpg
    FAT32文件系統(tǒng)中,F(xiàn)AT表是一個數(shù)據(jù)表,以簇(cluster)的形式鏈式存放。當一個文件大于一簇(4個扇區(qū))時,每簇中存放的數(shù)據(jù)便是文件存放的下一簇地址。直到遇到簇中的數(shù)據(jù)為“FF FF”時,才表示此文件已至尾簇。數(shù)據(jù)內容不連續(xù)地存放于數(shù)據(jù)區(qū)內。文件系統(tǒng)使用設備驅動提供的4個函數(shù)獲取設備的狀態(tài)信息以及實現(xiàn)對設備的讀寫。
    f.jpg

3 USB設備枚舉的實現(xiàn)
    枚舉就是從Deveice讀取信息,通過設備描述符設備告訴Host是什么設備、如何進行通信,Host根據(jù)這些信息來加載合適的驅動程序。
3.1 枚舉過程及實現(xiàn)
    USB是一種主從的結構,所有傳輸由Host來發(fā)起。當Host發(fā)起一次傳輸時,通常包括3個包(Packets)的傳輸。Host首先是發(fā)送一個Token Packet,包含本次傳輸?shù)拿铑愋?Type)、方向(Direction)、設備的地址(Device Address)以及端點號(Endpoint);緊接著發(fā)送數(shù)據(jù)包(Da-ta Packet),包含要求Device返回描述符的命令數(shù)據(jù);最后由Device返回握手信號包(handshake packet),正確返回(ACK)命令。
    USB Host檢測到有Device插入后,進行總線復位。然后Host使用默認地址0讀取設備描述符。獲取設備描述符的USB設備請求命令結構體為:
    g.jpg
    h.jpg
    第1次讀取設備描述符時,Host首先發(fā)送setup包;之后進入主機讀取數(shù)據(jù)階段,Host發(fā)送in包,Device返回一個18 B的設備描述符,可以用一個結構體將其讀回。最后Host發(fā)送0 B的數(shù)據(jù)包作為狀態(tài)相應,設備返回ACK作為應答。用邏輯分析儀抓包,3個包如圖3所示。

m.jpg


    第1次讀取設備描述符后,Host依次進行地址分配、第2次讀取設備描述符、讀取配置描述符、讀取描述符集、設置配置、讀取配置狀態(tài)和讀取接口狀態(tài),方法和第1次讀取設備描述符的方法一樣。
i.jpg
3.2 U盤兼容性
    在設備枚舉階段將會碰到很多關于U盤兼容性的問題。
    (1)總線復位時間。不同型號的U盤對于總線復位時間的要求是不同的,比如金士頓1 GB的U盤需要的復位時間至少280 ms。在實現(xiàn)中為保險起見,給予400 ms的復位時間。
    (2)有些U盤的端點0是8 B payload的,大多數(shù)是64 B。對于8 B payload的U盤,要嚴格從第1次獲取設備描述符時返回的第8字節(jié)獲取payload,否則盡管枚舉過程仍然能通過,但是后面在分析32字節(jié)的配置描述符時候會出現(xiàn)問題,沒有收到完整的配置描述符是分析不出端點1和端點2的地址以及端點payload的。
    (3)在枚舉階段獲取字符串描述符的時候,要進行判斷。因為有些U盤不支持返回字符串描述符,用if語句判斷,如果獲取不到字符串描述符就跳過,不要返回失敗。

4 Bulk-only傳輸?shù)膶崿F(xiàn)
    枚舉結束后是對塊設備的讀寫。Bulk-Only傳輸規(guī)范是USB組織針對大容量存儲設備制定的一種塊存儲類協(xié)議,它僅僅使用Bulk端點來傳送數(shù)據(jù)/命令/狀態(tài)。

l.jpg


    圖4是數(shù)據(jù)/命令/狀態(tài)在USB總線上的傳輸流程圖。根據(jù)此圖Bulk-only傳輸?shù)臓顟B(tài)可以定義為:空閑、CBW處理、數(shù)據(jù)輸出(從Host向Device傳輸數(shù)據(jù))、數(shù)據(jù)輸入(從Device向Host傳輸數(shù)據(jù))、CSW處理、管道阻塞等6種狀態(tài)。在空閑狀態(tài)下,接收到的數(shù)據(jù)包為CBW包;在數(shù)據(jù)輸出狀態(tài)下,接收到的數(shù)據(jù)包為Host期待寫入Device的數(shù)據(jù);在數(shù)據(jù)輸入狀態(tài)下,Host請求從Device讀取數(shù)據(jù),Device將向Host發(fā)送這些數(shù)據(jù)包;在CSW狀態(tài)下,Device封裝并發(fā)送CSW包以向Host返回狀態(tài)信息。因此,任何Bulk-Only事務均是以Host向Device發(fā)送CBW包并試圖建立相應的數(shù)據(jù)傳輸開始的;而Device接收到CBW包,進行檢查并解釋,試圖滿足Host的要求,并通過CSW向主機返回狀態(tài)信息。以讀一個邏輯塊為例,填寫一個CBW包的程序如下所示:

k.jpg
    邏輯分析儀抓包結果如圖5所示。從抓包結果可以清晰的看出CBW包由31個字節(jié)組成。

n.jpg


    CBW包和CSW包正確收發(fā)后,Bulk-only傳輸就能順利實現(xiàn)。完成對扇區(qū)的讀寫,文件系統(tǒng)的掛載。上層應用程序使用文件系統(tǒng)提供的API,操作底層設備,實現(xiàn)對文件的建立、讀寫、刪除等操作。經(jīng)測試本系統(tǒng)支持長文件名和超過2 GB容量的USB設備。本設計最終實現(xiàn)了在不同型號U盤上完成對長文件名文件的新建、讀寫以及刪除操作。

5 結語
    本設計在以CK510為內核的HM1521_B芯片上,通過文件系統(tǒng)實現(xiàn)了對USB設備的讀寫操作。程序代碼放棄了USB協(xié)議中的繁文縟節(jié),抓住協(xié)議核心以達到精簡高效之目的。在大容量USB存儲設備的兼容性方面也進行了探討。經(jīng)測試本系統(tǒng)支持長文件名和超過2 GB容量的USB設備。最終實現(xiàn)了在不同型號U盤上完成對長文件名文件的新建、讀寫以及刪除操作。
    本系統(tǒng)尚需改進的地方主要是讀寫過程中的出錯應對能力。如何應對USB設備在讀寫過程中的突然拔插,以及如何提高數(shù)據(jù)傳輸出錯時的校驗能力都是本課題進一步研究的方向。

此內容為AET網(wǎng)站原創(chuàng),未經(jīng)授權禁止轉載。
主站蜘蛛池模板: 男人和女人做爽爽视频| 四虎最新紧急更新地址| 日本动态120秒免费| 亚洲精品午夜久久久伊人| 色噜噜狠狠狠综合曰曰曰| 国产精品亲子乱子伦xxxx裸| 一区二区三区四区在线观看视频 | 欧美一级高清黄图片| 免费日产乱码卡一卡| 试看60边摸边吃奶边做| 国产精品午夜国产小视频| selao久久国产精品| 日本a∨在线播放高清| 亚洲а∨天堂久久精品| 爱情岛论坛免费视频| 吃奶摸下高潮60分钟免费视频| 黄色香蕉视频网站| 国产精品香港三级国产电影| а√最新版地址在线天堂| 日日碰狠狠添天天爽五月婷| 亚洲av无码成人网站在线观看| 污污网站在线观看| 免费精品久久久久久中文字幕| 野花社区在线播放| 国产特级毛片aaaaaaa高清| 97亚洲熟妇自偷自拍另类图片| 性中国videossex古装片| 久久久久无码精品国产app| 欧美xxxxx喷潮| 亚洲欧美日韩精品久久| 精东传媒国产app| 国产一国产二国产三国产四国产五| 欧美色图你懂的| 国产精品酒店视频免费看| ririai66在线观看视频| 成人影片在线免费观看 | 久久久综合九色合综国产 | 91麻豆国产极品在线观看洋子 | 亚洲色大情网站www| 精品国产丝袜自在线拍国| 国产亚洲3p无码一区二区|