Linux-USB學習 -- USB枚舉過程

USB架構中, hub負責檢測設備的連接和斷開,利用其中斷IN端點(Interrupt IN Endpoint)來向主機(Host)報告。在系統啓動時,主機輪詢它的根hub(Root Hub)的狀態看是否有設備(包括子hub和子hub上的設備)連接。USB總線拓撲結構見下圖(最頂端爲主機的Root Hub):

 

USB總線拓撲結構

(USB BusTopology)

開始ColinkEx的固件編寫,現在

1.在做使用colinkex_usb的lib在windows上編寫USB收發程序(用以測試)。

2.看芯唐例程看USB枚舉過程。

一旦獲悉有新設備連接上來,主機就會發送一系列的請求(Resqusts)給設備所掛載到的hub,再由hub建立起一條連接主機(Host)和設備(Device)之間的通信通道。然後主機以控制傳輸(ControlTransfer)的方式,通過端點0(Endpoint 0)對設備發送各種請求,設備收到主機發來的請求後回覆相應的信息,進行枚舉(Enumerate)操作。所有的USB設備必須支持標準請求(StandardRequests),控制傳輸方式(ControlTransfer)和端點0(Endpoint 0)。

 

從用戶角度來看,枚舉過程是自動完成並不可見的。但很多初次使用的設備連接時,系統會彈出說新硬件檢測到,設備安裝成功,可以使用之類的消息提示框,而且有時還需要用戶配合選擇安裝相關的驅動。

 

當枚舉完成後,這個新添加的設備可在Windows的設備管理器裏面看到,當用戶刪除這個設備/硬件時,系統把這個設備從設備管理器裏刪除。

對於一般的設備,固件(Firmware)內包含主機所要請求的信息,而有些設備則是完全由硬件來負責響應主機的請求。在主機方面則是由操作系統而非應用程序負責處理相關枚舉操作。

 

枚舉步驟

USB協議定義了設備的6種狀態,僅在枚舉過程種,設備就經歷了4個狀態的遷移:上電狀態(Powered),默認狀態(Default),地址狀態(Address)和配置狀態(Configured)(其他兩種是連接狀態和掛起狀態(Suspend))。

 

下面步驟是Windows系統下典型的枚舉過程,但是固件不能依此就認爲所有的枚舉操作都是按照這樣一個流程行進。設備必須在任何時候都能正確處理所有的主機請求。

 

1.用戶把USB設備插入USB端口或給系統啓動時設備上電

    這裏指的USB端口指的是主機下的根hub或主機下行端口上的hub端口。Hub給端口供電,連接着的設備處於上電狀態。

 

 

2.Hub監測它各個端口數據線上(D+/D-)的電壓

    在hub端,數據線D+和D-都有一個阻值在14.25k到24.8k的下拉電阻Rpd,而在設備端,D+(全速,高速)和D-(低速)上有一個1.5k的上拉電阻Rpu。當設備插入到hub端口時,有上拉電阻的一根數據線被拉高到幅值的90%的電壓(大致是3V)。hub檢測到它的一根數據線是高電平,就認爲是有設備插入,並能根據是D+還是D-被拉高來判斷到底是什麼設備(全速/低速)插入端口(全速、高速設備的區分在我將來的文章中描述)。如下圖。

USB全速/高速設備上電連接

(Full-speedDevice Cable and Resistor Connections)

 

    檢測到設備後,hub繼續給設備供電,但並不急於與設備進行USB傳輸。

 

 

3. Host瞭解連接的設備

 

   每個hub利用它自己的中斷端點向主機報告它的各個端口的狀態(對於這個過程,設備是看不到的,也不必關心),報告的內容只是hub端口的設備連接/斷開的事件。如果有連接/斷開事件發生,那麼host會發送一個 Get_Port_Status請求(request)以瞭解更多hub上的信息。Get_Port_Status等請求屬於所有hub都要求支持的hub類標準請求(standard hub-classrequests)。

 

 

4.Hub檢測所插入的設備是高速還是低速設備

    hub通過檢測USB總線空閒(Idle)時差分線的高低電壓來判斷所連接設備的速度類型,當host發來Get_Port_Status請求時,hub就可以將此設備的速度類型信息回覆給host。(USB 2.0規範要求速度檢測要先於復位(Reset)操作)。

 

 

5.hub復位設備

    當主機獲悉一個新的設備後,主機控制器就向hub發出一個 Set_Port_Feature請求讓hub復位其管理的端口。hub通過驅動數據線到復位狀態(D+和D-全爲低電平 ),並持續至少10ms。當然,hub不會把這樣的復位信號發送給其他已有設備連接的端口,所以其他連在該hub上的設備自然看不到復位信號,不受影響。

 

6.Host檢測所連接的全速設備是否是支持高速模式

 

 

    因爲根據USB 2.0協議,高速(High Speed)設備在初始時是默認全速(Full Speed )狀態運行,所以對於一個支持USB 2.0的高速hub,當它發現它的端口連接的是一個全速設備時,會進行高速檢測,看看目前這個設備是否還支持高速傳輸,如果是,那就切到高速信號模式,否則就一直在全速狀態下工作。

    同樣的,從設備的角度來看,如果是一個高速設備,在剛連接bub或上電時只能用全速信號模式運行(根據USB 2.0協議,高速設備必須向下兼容USB 1.1的全速模式)。隨後hub會進行高速檢測,之後這個設備纔會切換到告訴模式下工作。假如所連接的hub不支持USB 2.0,即不是高速hub,不能進行高速檢測,設備將一直以全速工作。

    高速設備檢測的過程在我另外一篇文章(USB2.0速度識別)中有詳細描述,這裏不具體深入。

 

 

7. Hub建立設備和主機之間的信息通道

    主機不停得向hub發送 Get_Port_Status請求,以查詢設備是否復位成功。Hub返回的報告信息中有專門的一位用來標誌設備的復位狀態。

    當hub撤銷了復位信號,設備就處於默認/空閒狀態(Default state),準備着主機發來的請求。設備和主機之間的通信通過控制傳輸,默認地址0,端點號0進行。在此時,設備能從總線上得到的最大電流是100mA。

 

 

8.主機發送Get_Descriptor請求獲取默認管道的最大包長度

    默認管道(Default Pipe)在設備一端來看就是端點0。主機此時發送的請求是默認地址0,端點0,雖然所有位分配地址的設備都是通過地址0來獲取主機發來的信息,但由於枚舉過程不是多個設備並行處理,而是一次枚舉一個設備的方式進行,所以不會發生多個設備同時響應主機發來的請求。

    設備描述符的第8字節代表設備端點0的最大包大小。對於Windows系統來說,Get_Descriptor請求中的wLength一項都會設爲64,雖然說設備所返回的設備描述符(DeviceDescriptor)長度只有18字節,但系統也不在乎,此時,描述符的長度信息對它來說是最重要的,其他的瞄一眼就過了。Windows系統還有個怪癖,當完成第一次的控制傳輸後,也就是完成控制傳輸的狀態階段,系統會要求hub對設備進行再一次的復位操作(USB規範裏面可沒這要求)。再次復位的目的是使設備進入一個確定的狀態。

 

 

9.主機給設備分配一個地址

    主機控制器通過Set_Address請求向設備分配一個唯一的地址。在完成這次傳輸之後,設備進入地址狀態(Address state),之後就啓用新地址繼續與主機通信。這個地址對於設備來說是終生制的,設備在,地址在;設備消失(被拔出,復位,系統重啓),地址被收回。同一個設備當再次被枚舉後得到的地址不一定是上次那個了。

 

 

10.主機獲取設備的信息

    主機發送 Get_Descriptor請求到新地址讀取設備描述符,這次主機發送Get_Descriptor請求可算是誠心,它會認真解析設備描述符的內容。設備描述符內信息包括端點0的最大包長度,設備所支持的配置(Configuration)個數,設備類型,VID(Vendor ID,由USB-IF分配), PID(Product ID,由廠商自己定製)等信息。Get_Descriptor請求(Device type)和設備描述符(已抹去VID,PID等信息)見下圖:

 

標準Get_Descriptor請求

(Get_DescriptorRequest)

 

 

 

設備描述符(DeviceDescriptor)

    之後主機發送Get_Descriptor請求,讀取配置描述符(ConfigurationDescriptor),字符串等,逐一瞭解設備更詳細的信息。事實上,對於配置描述符的標準請求中,有時wLength一項會大於實際配置描述符的長度(9字節),比如255。這樣的效果便是:主機發送了一個Get_Descriptor_Configuration的請求,設備會把接口描述符,端點描述符等後續描述符一併回給主機,主機則根據描述符頭部的標誌判斷送上來的具體是何種描述符。

11.主機給設備掛載驅動(複合設備除外)

主機通過解析描述符後對設備有了足夠的瞭解,會選擇一個最合適的驅動給設備。在驅動的選擇過程中,Windows系統會和系統inf文件裏的廠商ID,產品ID,有時甚至用到設備返回來的產品版本號進行匹配。如果沒有匹配的選項,Windows會根據設備返回來的類,子類,協議值信息選擇。如果該設備以前在系統上成功枚舉過,操作系統會根據以前記錄的登記信息而非inf文件掛載驅動。當操作系統給設備指定了驅動之後,就由驅動來負責對設備的訪問。

    對於複合設備,通常應該是不同的接口(Interface)配置給不同的驅動,因此,需要等到當設備被配置並把接口使能後纔可以把驅動掛載上去。

    設備-配置-接口-端點關係見下圖:

 

USB 設備-配置-接口-端點關係

(DeviceConfiguration)

  

    實際情況沒有上述關係複雜。一般來說,一個設備就一個配置,一個接口,如果設備是多功能符合設備,則有多個接口。端點一般都有好幾個,比如Mass Storage設備一般就有兩個端點(控制端點0除外)。

 

12. 設備驅動選擇一個配置

    驅動(注意,這裏是驅動,之後的事情都是有驅動來接管負責與設備的通信)根據前面設備回覆的信息,發送Set_Configuration請求來正式確定選擇設備的哪個配置(Configuration)作爲工作配置(對於大多數設備來說,一般只有一個配置被定義)。至此,設備處於配置狀態,當然,設備也應該使能它的各個接口(Interface)。

   對於複合設備,主機會在這個時候根據設備接口信息,給它們掛載驅動。

 

 

13. 設備可使用

 

********************

寫在最後:

    寫此文是爲了自己對最近一段時間學習USB有個總結,也希望能讓其他USB初學者有點小小的收穫。本文主要參考來源是Jan Axelson的Enumeration: How the HostLearns about Devices(http://www.lvr.com/usbcenum.htm)和Danny Simpson的An Overview of theUniversal Serial Bus (USB) (http://www.sss-mag.com/usb.html),並結合些自己的一些體會和理解,輔以圖片。由於我自己也是剛接觸USB不久,文中必有一些瑕疵,還請各位高手多多指教了:)

本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/aaa6695798/archive/2009/11/12/4801368.aspx

發佈了12 篇原創文章 · 獲贊 11 · 訪問量 28萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章