通用串行總線(USB)作為一種中高速的數據方式，已經很普遍地應用于外設與主機的通信中。VxWorks是當今十分流行的實時操作系統，在通信、國防、工業控制、醫療設備等嵌入式實時應用領域。很多VxWorks系統中都有USB設備，可是關于USB的驅動實現并沒有相關的資料可以參考，給實際工作帶來了難題。本文通過詳細地分析VxWorks下的USB驅動棧，具體提出了其實際應用的方法，為USB在應用VxWorks的嵌入式系統的開發掃清了技術障礙。
2、VxWorks簡介
VxWorks是WindRiver公司開發的具有工業領導地位的高性能實時操作系統(Real Tim Operation System，RTOS)內核，具有先進的網絡功能。VxWorks的開放式結構和對工業標準的支持，使得開發人員易于設計高效的嵌入式系統，并可以很小的工作量移植到其它不同的處理器上。
作為一種先進的實時操作系統，它具有以下特點：
可裁剪微內核結構。
高效的任務管理：
① 多任務，具有256個優先級。
② 具有優先級排隊和循環調度。
③ 快速的、確定性的上下文切換。
靈活的任務間通訊：
① 三種信號燈：二進制、計數、有優先級繼承特性的互斥信號燈。
② 消息隊列。
③ 套接字(Socket)。
④ 共享內存。
⑤ 信號(Signals)
微秒級的中斷處理。
支持POSIX 1003.1b實時擴展標準。
支持多種物理介質及標準的、完整的TCPIP網絡協議。
靈活的引導方式。支持從ROM、flash、本地盤(軟盤或硬盤)或網絡引導。
支持多處理器并行處理。
快速靈活的l／O系統。
支持MS-DOS和RT-11文件系統。
支持本地盤，flash，CD-ROM 的使用。
完全符合ANSI C標準。
多個系統調用。
3、 USB驅動程序的結構概述
圖1提供了一個USB主驅動棧結構的簡單概括。圖2顯示了USB主驅動棧的各模塊之間的功能聯系。
圖1 USB主驅動棧結構簡單模型
圖2 USB主驅動棧各模塊之間的功能聯系
在棧的部是USB主控制器(USB HC， 即USB Host Controller)， 這是主系統中控制每一個USB設備的硬件部分。
目前，市場上主要有兩大類USB主控制器，一種是支持由ime1公司提出的通用主控制器接口(Universal Host Controller Interface，簡稱UHCI)，另一種是支持由微軟、康柏和國家半導體公司聯合設計提出的開放主控制器接口(Open Host Controller Interface，簡稱OHCI)。硬件廠商一般根據這兩個規范設計他們的USB主控制器。
對于每一類型的主控制器都有一個與硬件獨立的USB主控制器驅動(Host Controller Driver，簡稱HCD)。WindRiver提供了兩個驅動：usbHcdUhciLib (UHCI 主控制器庫)和usbHedOheiLib (OHCI主控制器庫)。USB主驅動(USB host driver，簡稱USBD)和HCD之間的接口允許一個或超過一個的底層主控制器。而且，WindRiver的USBD能夠同時連接多個USB HCD。這樣的設計特點可以使開發者建立復雜的USB系統。
USBD是在HCD之上的與硬件獨立的模塊。USBD管理每一個與主機相連的USB設備， 向更高層次提供了可與USB設備通信的路徑。它還負責自動處理USB電力管理以及USB帶寬管理。而且，USBD還管理USB hub，Hub功能是一個驅動能否對USB正確操作的評價之一。因此WindRiver的USBD設計者要使USBD透明地處理hub的功能。這意味著，USBD 還能處理USB hub和設備的動態插拔。
USB Client模塊在USB主驅動棧的頂端。USB類驅動(USB Class Driver)是Client模塊的典型例子。USB類驅動負責管理連接到USB上的不同類型的設備； 它們依靠USBD來提供與每個設備的通信路徑。USB client模塊的其他例子就是那些利用USBD與USB設備通信的應用程序。
4、 USBD驅動詳解
這一部分將要描述USBD(USB Host Driver)的典型應用。例如初始化，client注冊，動態連接注冊，設備配置，數據傳輸，同時還探討了USBD內部設計的關鍵特性。這部分是VxWorks下USB驅動的核心。
4.1 初始化USBD：分為兩步
(1)必須至少調用一次函數usbdInitialize()。在一個給定的系統中，usbdlnifialize()初始化內部USBD數據結構，并依次調用其它USB驅動棧模塊的入口。usbdinitialize()可以在啟動時調用一次，也可以對每一個設備各調用一次。USBD 自己記錄了調用usbdInitialize()(‘+’)和usbdShutDown()(‘-’)的次數。只有大于等于1時才是真正初始化了，而等于0是關閉了。
(2)用USBD 的lisbdHedAttaeh()函數來把至少一個HCD連接到USBD上。這一過程既可以在VxWorks啟動時，也可以在運行時把HCD 連接到USBD 上去。后一種機制可以支持“熱插拔”，而不用象前一種那樣需要重新啟動。
4.2 HCD的連接(attaching)與斷開(detaching)
當HCD連接到USBD 時，調用者為usbdHedattaeh函數傳遞HCD執行入口(表HCD_EXEC_FUNC)和HCD連接參數(HCD attach parameter)。USBD用HCD FNC ATYACH 服務請求依次激活HCD的執行入口，傳遞同樣的HCD attach參數。
需要強調雖然可以改變用HCD定義的參數，但是不應該有所改變。對于WindRiver提供的UHCI和OHCI的HCD，HCI attach參數是一個指向結構PCI_CFG_HEADER (定義在pciConstants.h) 的指針。
該結構用UHCI和OHCI主控制器的PCI配置頭來初始化，而HCD用這個結構中的信息來定位，管理特定的主控制器。典型的，調用者用usbPeiClassFind ()和usbPciConfigHeaderGet()來得到想要的主控制器的PCI配置頭- 這兩個函數定義在usbPciLib 中(stubUsbarchPciLib.h中)。如果有UHCI或OHCI要連接到USBD，就要調用這些函數來獲得每一個主控制器的PCI_CFG_HEADER。然后利用usbdHedAttaeh來激活已鑒別出的每一個主控制器。
注意：底層BSP可能不支持USB的HCD斷開，因為當中斷向量表重新使能時，如果還應用的是過期的向量表，會導致錯誤。
4.3 啟動順序
必須在所有USBD函數前執行函數usbdInitialize()。存在以下兩種調用方式：
(1)傳統的“啟動”初始化。執行順序與其意義如下：
a．usbdInitialize()；
b．usbdPciClassFind()：定位一個USB主控制器；
c．usbdPeiConfigHeaderGet()：讀USB主控制器配置頭；
d．usbdHedAttaeh()：連接HCD，將其作為特定的主控制器：
e．調用USB class driver初始化入口點；
f．USB class driver調用usbdlnitialize()。
(2)“熱插拔”調用。執行順序與其意義如下：
Boot Code里調用：
a．USB class driver初始化入口點；
b．USB class driver調用usbdlnitialize()；
Hot-Swap code調用：
c．Hot-Swap 鑒別USB主控制器的連接或斷開；
d．Usbdlnitialize()；
e．UsbdPciConfigHeaderGet()：讀USB主控制器配置頭；
f．UsbdHedAttaeh()：連接HCD，將其作為特定的主控制器。
因為熱插拔可以在任何時刻發生，所以USBD和其Client都必須被寫成可以動態識別USB設備被插入還是被拔出。當主控制器連接到系統時，USBD 自動地鑒別與其相連的設備，并通知相關的client；同樣，拔出設備時，也要通知相關設備。重要的是，USBD 的client，比如USB class driver，在client初始化時，從不設想特定的設備已經出現；而在其他時候，這些驅動隨時檢查設備是否已經連接到系統上。
4.4 總線任務
對每一個連接到USBD 的主控制器，例如插入或拔出設備，USBD都會產生一個總線任務，來監控總線事件。一般情況下，這些任務是休眠的(不消耗CPU)，只有當USB hub報告它的一個端口有變化時，它們才被喚醒。每一個USBD總線任務有VxWorks任務名：UsbdBus。
雖然HCD委托USBD來管理，但有可能HCD 親自監視主控制器事件。例如WindRiver提供了UHCI和OHCI的HCD來創造這樣的任務。對于WindRiver的UHCI模塊(usbHcdUheiLib)，后臺任務只是被周期地喚醒，目的是為了檢查超時IRP(用一個中斷來通知OHCI根hub發生改變)。
用以在USBD和USB之問進行通信的client模塊，除了調用usbdlnitialize()外，必須調用usbClientRegister()使其在USBD注冊。當一個client注冊到USBD時，USBD把每一個以后將要用到的client的數據結構定位，并跟蹤那個client的請求。
對于每一個client，在client注冊過程中，USBD還創建了一個callback任務。在成功注冊client后，USBD返回一個句柄USBD_CLIENT_HANDLE。以下對USBD的調用，將會用到這個句柄。當所有句柄都不需要時，可以調用usbdClientUnregister()來釋放每一個client的數據結構和callback任務。注意：此時所有client要求的任務都會被取消。
例如：注冊一個叫USBD_TEST的client，再注銷。
注冊：usbdClientRegister("USBD_TEST'，&usbdClientHandle)；
注銷：usbdClientUnregister(usbdClientHandle)；
4.5 client回調(callback)任務
USB操作是嚴格遵守時序的。例如為使中斷傳輸和同步傳輸正確工作．需要依靠時鐘中斷。在一個有幾個不同client出現的主系統中．總是有可能出現一個client打斷其它client傳輸事件的發生。WindRiver USBD建議用client callback任務來解決這個問題。許多USB事件可以導致一個USB client的callback任務。例如， 每當USBD 完成USB IRP后，client的IRP callback函數被激活。同樣，當USBD識別出一個動態連接事件后，會激活一個或更多的動態attach callback操作。但不是馬上激活這些回調操作， 而是安排合適的相應的USBD client的回調任務來執行callback。
一般的情況下，每一個client的callback任務處于“休眠”態(阻塞態)。每一個client的callback，繼承了usbdClientRegister()產生的VxWorks任務優先級。這確保了每一個callback按其client的任務優先級來執行，而且可以利用優先級來寫client，保證對時間要求嚴格的USB傳輸。由于每一個client有它自己的callback任務，因此在callback期間，它們有很大的靈活性決定可以做什么。例如，允許在不破壞USBD或其它USBD client性能的條件下，使callback執行代碼運行至阻塞態。
Client callback task有VxWorks任務名：tUsbdCln。
4.6 USBD內部Client
當次初始化USBD時，由USBD產生并注冊一個內部client，以跟蹤USB請求。
USBD 可以產生什么類型的USB請求呢? 所有USBD與USB設備的傳輸，均利用調用USBD client的形式來完成。例如， 當一個設備次連接到系統時．USBD用一個控制管道(control pipe) 自動地創建設備需要的所有的control pipe，即USBD client要用usbdPipeCreate()來創建一個與USB endpoint0通話的通道，然后所有USBD 內部、外部client通過這個管道來發送諸如usbdDescriptorGet()或usbdFeatureGet()等的函數，進行操作。
所以，USBD 的一個機制就是USBD 循環利用它自己的entry point，而內部chent跟蹤這些請求。
4.7 動態連接的注冊
每當一個特定類型的設備插入或拔出時，USBD client都通知上一層。利用調用usbdDynamicAttachRegister()操作，client可以指定一個callback操作，以便可以獲取這樣的通知。
USB設備類型用class，subclass，protocol來區別。標準的USB 類在usb．h 中定義為USB_CLASS_XXXX。Subclass和protocol根據class來定義， 因此這些常數根據特定的class在頭文件中定義。
有時， 一個client當利用usbdDynamicAttachRegister()進行注冊時，只對特定的class，subclass，protocol感興趣。例如，USB鍵盤類驅動usbkeyboardLib， 注冊了Human Device Interface (HID) 類，subclass 是USB_SUBCLASS_HID_ BOOT，protocol是USB_PROTOCOL_HID_BOOT _KEYBOARD。通過callback機制的響應，每當一個設備完全符合這樣的標準， 從設備上插入或拔出時，SBD便通知給keyboard class driver。而在其它情況下，client關注的范圍更廣泛了。常量USBD_NOTIFY(定義在usbdLib.h)可以替代任意的class，subclass，protocol。例如，USB打印機USB驅動，usbPrinterLib， 其class等于USB_CLASS_PRINTER，subclass 等于USB_SUBCLASS_PRINTER (usbPrinter.h)，protocol等于USBD_ NOTIFY_ ALL。典型的，當一個client只調用一次usbdDynamicAttachRegister()時，對一個client能擁有的并發通知請求數目沒有限制。
4.8 Node ID
USB設備一般用USBD_NODE_ID來區別。從其作用來看，USBD_ NODE_ ID 是USBD 用來跟蹤一個設備的句柄。它與USB設備真正的USB地址無關。這表明client并不真正關心想要了解設備是物理上與哪一個USB主控制器相連。應用為每個設備抽象定義的Node ID， 使client可以不用考慮物理設備的連接細節以及USB地址分配， 并允許USBD 在其內部對這些進行詳細的管理。
當一個client通知有一個設備連接或斷開時，USBD經常通過USBD_NODE_ID來定位設備。同樣，當一個client想通過USBD與一個特定的設備通信時，它必須向USBD傳遞那個設備的USBD_NODE_ID。
4.9 總線編號(bus enumeration)操作
usbdLib模塊提供了usbdBusCountGet()，usbdRootNodeldGet()，usbdHubPortCountGet()，usbdNodldGet()操作。它們被一起稱作總線編號操作。它們使USBD Client對連接到每一個主控制器上的設備進行編號。
這些操作對于診斷程序和測試工具很有用，例如usbTool(WindRiver提供的一個測試工具)。但是，利用它們編號之后，調用者無法知道USB的拓撲結構是否變化。因此， 建議USB class driver的開發者不要用這些操作。
4.10 數據傳輸
一旦client配置完成一個設備，就開始利用USBD提供的管道和傳輸功能與設備進行數據交換。傳輸種類(分為控制、塊、中斷和同步傳輸)用一個USB_IRP數據結構來描述。 USB_IRP 的具體描述請參見HCD_FUNC_IRP_SUBM1T。USB數據傳輸被定位于每一個設備的特定endpoint。在USBD client和特定的設備endpoint之間的通道被稱作管道(pipe)。每一個管道有以下若干特性：
USBD_NODE_ID；
設備的endpoim 數目；
數據傳輸方向；
帶寬需求；
延時需求。
為了和設備交換數據，client必須先創建管道。作為結果，USBD得到了一個USBD_PIPE_HANDLE，它被用于隨后對這個管道的所有client操作。
當client企圖創建一個管道時，USBD會檢查是否有足夠的可用帶寬。對于中斷和同步傳輸，帶寬限制是必需的。USBD不允許把90％ 以上的可用帶寬分配給中斷和同步管道；而對于控制和塊傳輸，則沒有帶寬的限制。同時，保證至少10％ 的帶寬用于控制傳輸，對塊傳輸則不保證會提供任何可用帶寬。
數據傳輸的具體過程：
(1)創建pipe ：usbdPipeCreate(usbdClient Handle，nodeld，endpoint，configvalue，interface， USB_XFRTYPE_BULK，USB_ DIR_OUT，maxPacketSize，0，0，&outPipeHandle)；
(2)定義callback：ourlrpCallback(pvoid P)；
(3)初始化IRP的數據結構；
(4)發送IRP：usbdTransfer(usbdChentHandle，outPipeHandle，＆irp)。
5 、小結
USB在VxWroks下的從下至上驅動棧分為HC、UCD、USBD和Client Module四層，每一層都相對獨立，并為上一層提供了屏蔽該層次具體特征的接口。作者所說的USB驅動，實際上主要在USBD這一層次上完成。具體分為Chent注冊，注銷，創建pipe ，配置，數據發送，以及各回調函數。當正確地依次調用時， 會根據回調函數的狀態和返回值，按正確的時序進行完整的數據傳輸。
上述設計思想構成了VxWorks下USB設備應用的基礎。作者的研究詳細地分析了VxWorks的USB協議棧，證明了該方案的可行性，同時又給出了合理的實現方法。作為實踐成果，作者已在VPN網關證書讀取系統中，利用該思想編寫的驅動，順利讀出存儲在USB設備中的設備證書和管理員證書，且運行情況良好。作者認為，文中提到的模型完全可以勝任解決USB設備在VxWorks下的應用所面臨的技術難題。