嵌入式Linux下USBGadget驅(qū)動框架研究_圖文

1、Dec 12006 Vol 124, No . 6航 天 控 制 Aer os pace Contr ol嵌入式 L i n ux 下 USB Gadget 驅(qū)動框架研究3李傳偉 胡金春清華大學智能技術與系統(tǒng)國家重點實驗室 , 北京 100084 摘 要 為更好地應用嵌入式 L inux 系統(tǒng)下的 US B , 介紹了 US B 的相關概念及其設備驅(qū)動模型 US 構 , 以 Ethernet Gadget 驅(qū)動程序的整體思路 , 最后總結(jié)了 US B 。 關鍵詞 L Gadget 驅(qū)動框架 設備驅(qū)動程序 . 89文獻標識碼 :A 10063242(2006 0620051205Study on

2、 USB Gadget D r i ver Fram ework i n Em bedded L i n uxL i Chuan wei Hu J inchunState Key Laborat ory of I ntelligent Technol ogy and Syste m s,Tsinghua University, Beijing 100084, ChinaAbstract To apply the US B Gadget driver F ram e w ork in e m bedded L inux syste m m uch better , US B basickno w

3、 ledge and its d riverm odel a re introduced, then the m ain data structures of Gadget d river are analyzed . A s a result, w riting Gadget driver HOW 2TO is de m onstrated by the E thernet Gadget driver . The li m itations of this fram e w ork are poin ted out and i m prove m ents are m ade finally

4、 .Key words L inux syste m US B Gadget driver fram e w ork D evice driver 3973資助項目 (51323010323 收稿日期 :2006205216作者簡介 :李傳偉 (1980- , 男 , 河南通許人 , 碩士研究生 , 主要研究方向為嵌入式系統(tǒng) ; 胡金春 (1972- , 男 , 江蘇淮 安人 , 副教授 , 主要研究方向為飛行控制 、 信號處理等 。1 引 言通用串行總線 (US B 是主機和外設之間一種重要的連接方式 , 它以單一類型總線連接各式各樣的 設備 , 接口簡單統(tǒng)一 、 支持熱插拔 、 易于安裝和

5、擴展 , 最多可連接 127個外設 , 目前 US B2. 0版本最高速 率可以達到 480Mbp s 。由于其眾多優(yōu)點 , US B 成為 主機與外設進行數(shù)據(jù)交換的必備接口 。L inux 以其開源 、 易于移植和可裁剪性 , 越來越多地被應用于嵌入式系統(tǒng) 。 L inux 內(nèi)核支持 2種主要類型的 US B 驅(qū)動程序 :主機側(cè)和設備側(cè)驅(qū)動程 序 。 主機側(cè) US B 驅(qū)動程序 (US B Device D river 控制 與其連接的 US B 設備從而使用設備的功能 ; 設備側(cè) US B 驅(qū)動程序 (US B Gadget D river 控制設備如何與主機通信從而使其對主機表現(xiàn)出特定的

6、功能 1, 此 時的設備應理解為運行 L inux 的嵌入式系統(tǒng) 。迄今 為止對于 L inux 系統(tǒng)中 US B 設備驅(qū)動開發(fā)的研究非 常豐富 , 但是主要討論主機側(cè)驅(qū)動程序的實現(xiàn)機制 , 本文將著重分析設備側(cè) US B Gadget 驅(qū)動框架 。 15航 天 控 制 2006年2 USB 總線數(shù)據(jù)交換特點US B 采用樹形拓撲結(jié)構 。主機側(cè)和設備側(cè)的 US B 控制器分別稱為主機控制器 (Host Contr oller 和 US B 設備控制器 (UDC , 每條總線上只有一個主機控制器 , 負責協(xié)調(diào)主機和設備間的通信 , 而設備不 能主動向主機發(fā)送任何消息 。主機控制器通過 UDC 的

7、端點 (Endpoint 與設 備進行通信 , 端點由端點號和傳輸方向確定 , 僅能單 向傳輸數(shù)據(jù) 。 US B 端點有 4種類型 , 分別對應 數(shù)據(jù)傳輸方式 : 控制 (Contr ol :, 種可靠 、 批量 (Bulk :, 但時 間要求不嚴格 。中斷 (I nterrup t :以固定速率傳送少量數(shù)據(jù) 。 等時 (Is ochr onous :以恒定速率實時傳輸數(shù)據(jù) 流 , 但對正確性并無要求 。其中 0號端點是所有 US B 設備的缺省端點 , 支 持控制傳輸 。 在設備連接到 US B 總線 、 被供電并接 收到總線復位信號之后 , 主機側(cè)驅(qū)動程序通過 0號 端點初始化并操縱 US

8、 B 設備 。在 US B 協(xié)議中 , 接口 (I nterface 由多個端點組 成 , 代表一個基本的功能 , 是 US B 設備驅(qū)動程序控 制的對象 , 一個功能復雜的 US B 設備可以具有多個 接口 。 配置 (Configurati on 是更高層的邏輯概念 , 由 多個接口組成 , 一個 US B 設備可以具有多個配置 ,不同的配置使設備表現(xiàn)出不同的功能組合 2。 US B 設備的邏輯組織如圖 1所示。 圖 1 US B 設備邏輯組織3 L i n ux 下 USB 驅(qū)動的整體框架L inux 對主機側(cè)和設備側(cè) US B 驅(qū)動程序的開發(fā)都提供了良好的支持 , 整體框架如圖 2所示

9、 。在主 機側(cè) , L inux 內(nèi)核 US B Core 子系統(tǒng)負責 US B 驅(qū)動管 理和協(xié)議處理的主要工作 US B Core 子系統(tǒng)功能 包括 :、 宏和功能函數(shù) , 向上 , US B 主機控制器 完成設備熱插拔控制 、 總線數(shù)據(jù)傳輸3。圖 2 L inux 下 US B 設備驅(qū)動整體框架L inux 內(nèi)核中 US B 設備側(cè)驅(qū)動程序分為 3個層次 :UDC 驅(qū)動程序 、 Gadget AP I 和 Gadget 驅(qū)動程序 。 UDC 驅(qū)動程序直接訪問硬件 , 控制 US B 設備和主機間的底層通信 , 向上層提供與硬件相關操作的回調(diào) 函數(shù) 。 當前 Gadget AP I 是 UD

10、C 驅(qū)動程序回調(diào)函數(shù) 的簡單包裝 。 Gadget 驅(qū)動程序具體控制 US B 設備 功能的實現(xiàn) , 使設備表現(xiàn)出“ 網(wǎng)絡連接 ” 、 “ 打印機 ” 或 “ US B Mass St orage ” 等特性 , 它使用 Gadget AP I 控 制 UDC 實現(xiàn)上 述 功 能4。 Gadget AP I 把 下 層 的UDC 驅(qū)動程序和上層的 Gadget 驅(qū)動程序隔離開 , 使得在 L inux 系統(tǒng)中編寫 US B 設備側(cè)驅(qū)動程序時能夠 把功能的實現(xiàn)和底層通信分離 。4 Gadget 驅(qū)動框架分析L inux 系統(tǒng)中 Gadget 驅(qū)動程序框架見圖 3。設備側(cè)驅(qū)動程序使用 struct

11、 usb_gadget描述 UDC, 使用 struct usb_ep描述端點 , Gadget AP I 通過這 2個結(jié)構實現(xiàn)對 UDC 硬件的抽象 。struct usb_gadgetconst struct usb_gadget_ops op s; /3UDC 操作函數(shù)集指針 3/25第 24卷 第 6期 李傳偉等 :嵌入式 L inux 下 US B Gadget 驅(qū)動框架研究 struct usb_ep 3ep0; /30端點指針 3/struct list_head ep_list;/3其他端點鏈表 3/struct device dev;/3用于 L inux 驅(qū)動模型 , 暫不

12、討論 3/3省略一些屬性域 3/;struct usb_ep const struct usb_ep_ops 3op s; /3端點操作函數(shù)集指針 3/struct list_headep_list;/3/ ;struct usb_gadget_ops 是 UDC 操作函數(shù)集 , 參見圖 3, 函數(shù)的主要功能為 :返回 UDC 當前數(shù)據(jù)幀 、 喚 醒與設備相連接的主機 、 設置或清除設備自供電特 征 、 UDC 電源管理等 。struct usb_ep_ops 是 UDC 端點操作函數(shù)集 , 參 見圖 3, 函數(shù)的主要功能為 :配置端點是否可用 、 為 端點分配或釋放緩沖區(qū) 、 為端點分配或釋

13、放請求對 象 、 向端點提交或取消一個特定請求 、 設置端點的停 止特征等 。設備側(cè)驅(qū)動程序使用 struct usb_request描述一 個 I/O請求 , 與主機側(cè)的 URB (US B Request B l ocks 結(jié)構類似 :struct usb_requestvoid buf; /3數(shù)據(jù)緩沖區(qū) 3/unsigned length; /3數(shù)據(jù)長度 3/void (3comp lete (struct usb_ep3ep, struct usb_request3req ;/3usb_request被處理后的回調(diào)函數(shù) 3/struct list_head list;/3用于將 usb

14、_request組織成鏈表 3/int status;/3usb_request請求的狀態(tài) 3/ ;編寫 UDC 驅(qū)動程序的主要任務就是配置 struct usb_gadget結(jié)構 、 實現(xiàn) struct usb_ep_ops 和 struct usb _gadget_ops 相關的函數(shù)。圖 3 Gadget 驅(qū)動框架Gadget AP I 層為 Gadget 驅(qū)動程序開發(fā)定義了一組接口函數(shù) , 和主機側(cè)的 US B Core 地位類似 , 但功 能僅限于向上提供編程接口 , 這些接口基本上是對 上述 UDC 操作函數(shù)和端點操作函數(shù)的包裝 , 分別是 usb_gadget _3和 usb _e

15、p _35。比 較 特 殊 的 是Gadget 驅(qū)動程序注冊函數(shù) usb_gadget_register_driv2er, 它由 UDC 驅(qū)動程序直接提供 , 用于將 Gadget 驅(qū)動程序綁定到 UDC (usb_gadget 。Gadget 驅(qū)動程序使用結(jié)構 struct usb _gadget_driver 描述 :struct usb_gadget_driverenu m usb_device_speed s peed; /3設備最高速度 3/int (3bind (struct usb_gadget3 ; /3將驅(qū)動與設備綁定 3/int (3setup (struct usb_ga

16、dget3, const struct usb_ctrlrequest3 ;void (3sus pend (struct usb_gadget3 ; struct device_driverdriver; ;函數(shù) bind 負責完成 Gadget 驅(qū)動和下層設備控 制器的關聯(lián) , 并開啟設備的功能 。 Gadget 驅(qū)動通過 上述 Gadget AP I usb_gadget_register_driver注冊自己 對應的 usb_gadget_driver結(jié)構 , 而 usb_gadget_regis 2ter_driver函數(shù)是 UDC 驅(qū)動程序的重要組成部分 , 它調(diào)用參數(shù) usb_g

17、adget_driver的 bind 函數(shù) , 把 Gadget 驅(qū)動程序和 UDC 描述結(jié)構綁定在一起 。 Xxx_udc_35航 天 控 制 2006年irq 是 UDC 設備的中斷處理函數(shù) , 它處理設備及其 端點的中斷請求 , 并調(diào)用各個端點上已完成傳輸請求 usb_request的回調(diào)函數(shù) comp lete 。以下以 Ethernet Gadget 驅(qū)動程序為例展示編寫 Gadget 驅(qū)動的要點 。5 Ethernet Gadget 驅(qū)動程序Ethernet Gadget 驅(qū)動程序使主機和 US B 設備可以通過 US B 總線實現(xiàn) Ethernet 互連 。 L inux 主機側(cè)

18、 的驅(qū) 動 屬 于 Co mmunicati ons Device Class (W indo ws 主機側(cè)的驅(qū)動遵循 RND I S 側(cè) , L inux Ethernet Gadget 為了簡化討論 , 系統(tǒng)的 情況 。, 兩側(cè)的驅(qū)動程序分別虛擬 出一個以太網(wǎng)絡設備 , 主機和設備即可通過虛擬網(wǎng) 絡設備建立連接 , 如圖 4所示。 圖 4 Ethernet Gadget 虛擬網(wǎng)絡層次關系在 Ethernet Gadget 驅(qū)動程序中 , 使用自定義結(jié) 構 struct eth_dev完整地描述 Ethernet Gadget 設備 :struct eth_devstruct usb_gad

19、getgadget; /3Gadget 綁定的 UDC 3/struct usb_request3req;struct usb_ep3in_ep,3out_ep,3status_ep;struct list_headtx_reqs,rx_reqs;/3發(fā)送和接收請求 usb_request鏈表 3/struct net_device3net; /3網(wǎng)絡設備描述結(jié)構 3/u8host_macET H_ALEN;/3網(wǎng)絡設備 MAC 地址 3/ ;Ethernet Gadget 驅(qū)動程序被配置為 :static struct usb_gadget_drivereth_driver=. bind =

20、eth_bind,. setup =eth_setup,. sus pend =eth_suspend,;Gadget 驅(qū) 動 程 序 模 塊 的 init 函 數(shù) 調(diào) 用 usb _gadget_register_driver( 完成驅(qū)動注冊 。 函數(shù)調(diào)用 eth Gadget 驅(qū)動程Gadget 設備描述 并注冊網(wǎng)絡設備驅(qū)動程序 , 同時將 驅(qū)動程序 (usb_gadget_driver 和 UDC 描述結(jié) 構 (usb_gadget 關聯(lián)起來 。int eth_bind(struct usb_gadget3gadget struct eth_dev3dev; struct net_dev

21、ice3net; struct usb_ep 3ep;net =all oc_etherdev(sizeof 3dev ; dev =net p riv; dev net =net;net hard_start_xm it =eth_start_xm it;net open =eth_open;net do_ioctl =eth_ioctl;/3為網(wǎng)絡設備描述結(jié)構和 Gadget 設備描述結(jié)構分配內(nèi)存并進行相關配置 3/dev gadget =gadget; set_gadget_data(gadget, dev ; gadget ep0 driver_data=dev; /3將 Gadget

22、 驅(qū)動和 UDC 描述結(jié)構綁定 3/register_netdev(dev net ; /3注冊網(wǎng)絡設備驅(qū)動程序 3/eth_start_xm it 是網(wǎng)絡設備驅(qū)動程序的數(shù)據(jù)發(fā)送函數(shù) , 它將從內(nèi)核接收到的套接字緩沖區(qū) struct sk_buff 3skb 中的數(shù)據(jù)組織成 US B 協(xié)議下的 struct usb _request,通過 Gadget AP I usb_ep_queue發(fā)送出去 。int eth_start_xm it (struct sk_buff3skb, struct net_device3net 45第 24卷 第 6期 李傳偉等 :嵌入式 L inux 下 US B

23、 Gadget 驅(qū)動框架研究struct eth _dev 3dev =(struct eth _dev 3 net p riv;struct usb_request3req =NULL;req =container_of(dev tx_reqs . next, struct usb_request,list ;list_del(&req list ;req buf =skb data;req context =skb;req comp lete =tx_comp lete;/3數(shù)據(jù)發(fā)送完成后由 UDC數(shù)調(diào)用 co mp lete 函數(shù) ,req, GFP_ATOM 2 I C ;/3向 I

24、N 端點提交數(shù)據(jù)發(fā)送請求 3/eth_open( 是網(wǎng)絡設備的 open 函數(shù) , 它調(diào)用 rx _submit 函數(shù)開始等待接收 US B 主機發(fā)送的數(shù)據(jù) 。 rx_subm it 為請求 usb_request分配接收緩沖區(qū) , 并把 緩沖區(qū)組織成 struct sk_buff的形式 , 然后向 OUT 端 點 (主機 設備 提交接收請求 。int rx_subm it (struct eth _dev3dev, struct usb _re 2 quest 3req, int gf p_flagsstruct sk_buff3skb;size_tsize;size =(sizeof (s

25、truct ethhdr +dev net m tu +RX_EXTRA ;size +=dev out_ep maxpacket-1; size -=size %dev out_ep maxpacket;skb =all oc_skb(size, gfp_flags ;/3分配 struct sk_buff作為 struct usb_request的 接收緩沖區(qū) 3/req buf =skb data;req length =size;req comp lete =rx_complete;/3設置數(shù)據(jù)接收完成時的回調(diào)函數(shù) 3/req context =skb;usb_ep_queue(dev

26、 out_ep,req, gfp_flags ; 接收完成后即可通過 netif_rx ( 通知網(wǎng)絡子系 統(tǒng)讀取數(shù)據(jù) , 這一工作是在回調(diào)函數(shù) rx_complete 中 完成的 。void rx_complete (struct usb_ep3ep, struct usb_re 2 quest 3req struct sk_buff3skb =req context;struct eth_dev3dev ep driver_data;dev net;ocol =eth_type_trans(skb, dev ;/3將接收緩沖區(qū)配置為 struct sk_buff結(jié)構 3/ status =n

27、etif_rx(skb ;/3通知網(wǎng)絡子系統(tǒng)讀取接收到的數(shù)據(jù) 3/if (req rx_submit (dev, req, GFP_ATOM I C ;/3把剛完成的 usb_request 再次提交給特定端 點 , 以便不斷地接收 US B 主機發(fā)送的數(shù)據(jù) 3/ 6 Gadget 驅(qū)動框架的不足與改進Gadget 框架是在 2. 4. 23版內(nèi)核中才引入的 , 現(xiàn) 在仍不十分完善 。從整體上看 , 框架使用 struct usb _gadget描述 UDC 及其驅(qū)動程序 , 使用 struct usb _ gadget_driver 描述 Gadget 驅(qū)動 程序 , 通過 Gadget A

28、P I 為 Gadget 驅(qū)動提供編程接口并將其和 UDC 驅(qū) 動隔離 。 這種層次關系和主機側(cè) US B 驅(qū)動框架基 本相同 , Gadget AP I 層和主機側(cè)的 US B Core 地位類 似 , 但僅對 UDC 驅(qū)動程序操作函數(shù)進行了簡單的包 裝 。 Gadget AP I 層并沒有真正使 UDC 驅(qū)動程序和 Gadget 驅(qū)動程序隔離 , 無論在關鍵的描述結(jié)構上還 是在接口函數(shù)上都存在耦合 。首先 , struct usb_gadget_driver結(jié)構直接依賴于 struct usb_gadget結(jié)構的定義 , 這導致上層種類繁多 的 Gadget 驅(qū)動程序直接依賴于下層 UDC

29、 驅(qū)動程序 的模型 , UDC 驅(qū)動模型的改變必然要求 Gadget 驅(qū)動 程序大規(guī)模改寫 。這使 Gadget AP I 的存在失去其 主要意義 。其 次 , Gadget 驅(qū) 動程 序注冊 函數(shù) usb _gadget_ (下轉(zhuǎn)第 60頁 5 560 Environment ( GATE A . 2005. I N GNSS 2005. O 航 天 控 制 Sep t . GPS/ GNSS 2003, Sep t 2003: 1953 1964. . 2006 年 6 Dellago R , Piep lu J M , Stalford R. The Galileo System A r

30、chitecture at the End of the Design Phase A . GPS/ GNSS 2003, Sep t 2003: 978 990. . 7 廖春發(fā) . 2004 年歐洲伽利略計劃的若干重要進展 J . I N O 4 B lomenhofer H , Ehret W , Leonard A , B lomenhofer E. GNSS/ Galileo Global and Regional Integrity Performance Analysis A . 2168. 5 Ganguly S, Jovancevic A , B rown A. Open A

31、 rchitecture Development System for GPS and Galileo A . I N O I N GNSS 17 th International Technical O M eeting of the Satellite D ivision, Sep t 2004: 2158 . 中國航天 , 2005 ( 3 : 29 30. 8 石衛(wèi)平 . 國外衛(wèi)星導航定位技術發(fā)展現(xiàn)狀與趨勢 J . 航天控制 , 2004 , 22 (4 : 30 35. (上接第 55 頁 register_driver直接由 UDC 驅(qū)動程序?qū)С?, 使得下層 UDC 驅(qū)動程序直接

32、依賴于上層的 Gadget驅(qū)動模型 . 7 結(jié)語 L inux系統(tǒng)中 USB Gadget驅(qū)動程序建立在 UDC 同時也意味著在 L inux設備側(cè)驅(qū)動框架下每個 USB 設備只能有一個 UDC,雖然這能夠滿足當前大多數(shù) 設備的要求 ,但從發(fā)展的角度看 ,并不明智 . 為解決上述問題 ,減少 UDC 驅(qū)動程序和 Gadget 驅(qū)動程序之間的耦合 , 增強對復雜 USB 設備的支 持 ,需要對 Gadget驅(qū)動程序框架進行如下改進 : ( 1 將 Gadget AP I擴充為 Gadget Core 子系統(tǒng) , 其功能包括 UDC 驅(qū)動和 Gadget 驅(qū)動的注冊與管 理, 為編寫 UDC 驅(qū)動和 Gadget驅(qū)動提供 AP I等 . ( 2 改寫 struct usb_gadget_driver和 struct usb_ gadget使其僅依賴于 Gadget Core 子系統(tǒng) . ( 3 依照 USB 協(xié)議 ,為 Gadget Core 子系統(tǒng)定義 標準的接口和配置描述結(jié)構 , 并提供管理和操縱這 些結(jié)構的 AP I . ( 4 在改進后的 Gadget驅(qū)動框架中 , Gadget驅(qū) 動程序僅依賴于其下層 Gadget Core 子系統(tǒng) , UDC 驅(qū) 動程序僅向其上層 Gadget Core 子