上一篇：https://blog.csdn.net/qq_40088639/article/details/109741653

總述

1. 設備枚舉的整個過程

USB設備枚舉過程，可大致分為下面的幾個階段：

一、獲取設備描述符???? 二、復位總線 三、設置地址階段 四、再次獲取設備描述符 五、獲取配置描述符集合請求（第一次） 六、語言ID描述符和字符串描述符的請求 七、又獲取了一次設備描述符 八、又再一次獲取配置描述符 九、設置配置請求 十、設置接口請求 十一、重復兩次請求產品字符串描述符 十二、Set_Idle請求 十三、獲取報告描述符 十四、又一次獲取產品描述符 十五、又一次設置接口 十六、一個未知的HID中斷輸出請求 十七、最后再獲取一次配置描述符

2. 說明

（1）根據實例，分析枚舉過程，使用的是實時操作系統Zephyr的設備協議棧架構，并且該實例是一個組合設備[ HID + UAC ]。

（2）USB設備枚舉過程并不是固定的，比如，有多種因素會導致Host重復請求獲取某個描述符，并且每次獲取的長度是不一樣的；不同的PC可能枚舉過程也有差異；不同操作系統枚舉過程也有差異(這是開發USB面臨的最大問題之一，兼容性問題)。但是，過程大致是一樣的，指令也是一樣的，都遵循同一套USB協議。

（3）關于Zephyr操作系統的USB協議棧，后續有介紹。

（4）USB設備枚舉過程比較復雜，因此篇幅比較長，這里差分為連續的幾篇博文進行記錄。

（5）分析枚舉過程，又把前面四篇的內容給串起來了[對協議有粗略的解析]。

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 設備枚舉過程分析

USB檢測到USB設備插入，會先對其進行復位。USB設備在總線復位后，地址為0。接下來，主機就使用地址0和設備進行通信。

一、Host獲取設備描述符

主機向 地址為0的設備 的端點0發送獲取設備描述符的標準請求。

1. USB的標準請求

USB協議定義了一個8字節的標準設備請求，標準請求發生在設備的枚舉過程中。

(1) 標準請求的結構

偏移量/字節	域	大小/字節	取值	描述
0	bmRequestType	1	位圖	見下表
1	bRequest	1	數值	見下表
2	wValue	2	數值	見下表
4	wIndex	2	索引或偏移量	見下表
6	wLength	2	字節數	見下表

對各個字段的描述：

請求的特性[bmRequestType]： 1）該字節數據的第七位D7：請求的數據傳輸方向 0：表示主機到設備?? 1：表示設備到主機 2）該字節數據的第五和第六位D6~D5：表示請求的類型 0：表示這是一個標準請求 1：表示這是一個類請求 2：表示這是一個廠商請求 3：保留 3）第0到第4位D4~D0：表示該請求的接收者。 0：表示該請求的接收者是設備 1：表示該請求的接收者是接口 2：表示該請求的接收者是端點 3：表示該請求的接收者是其他 實例：如果是一個獲取設備描述符的標準請求，那么這個字節數據就是0x80 = 1000 0000 B

[bRequest]: 請求代碼

[wValue]: 意義由具體的請求來決定

[wIndex]: 意義由具體的請求來決定

[wLength]: 數據過程需要傳輸的字節數（可能為0，沒有數據過程，那就是0）

?

2. USB獲取設備描述符的標準請求

USB協議定義了11個標準請求（bRequest）。這11個標準請求的名字和對應的編號如下表。

bRequest	Value	bRequest	Value
GET_STATUS	0 (0x00)	GET_CONFIGURATIOIN	8 (0x08)
CLEAR_FEATURE	1 (0x01)	SET_CONFIGURATIOIN	9 (0x09)
SET_FEATURE	2 (0x02)	GET_INTERFACE	10 (0x0a)
SET_ADDRESS	5 (0x05)	SET_INTERFACE	11 (0x0b)
GET_DESCRIPTOR	6 (0x06)	SYNCH_FRAME	12 (0x0c)
SET_DESCRIPTOR	7 (0x07)	?

常用的幾個標準請求為GET_DESCRIPTOR、SET_ADDRESS、GET_CONFIGURATIOIN、SET_CONFIGURATIOIN。

(1) GET_DESCRIPTOR

（獲取描述符）請求是枚舉過程中，用得最多的一個請求。主機通過發送獲取描述符請求，設備返回相應的數據，主機解析設備的各種描述符數據。也就是說，設備描述符還有分類，

USB協議規定，USB設備具有5種標準的描述符類型，如下表：

5種標準描述符類型	編號
設備描述符	1(0x01)
配置描述符	2(0x02)
字符串描述符	3(0x03)
接口描述符	4(0x04)
端點描述符	5(0x05)

GET_DESCRIPTOR的請求結構

bmRequestType	bRequest	wValue（2 Byte）	wIndex(2 Byte)	wIndex (2 Byte)
1000 0000 （0x80）	GET_DESCRIPTOR （0x06）	描述符的類型和索引值	0或者語言ID	描述符的長度

說明：

A．對于wValue這個域，第一字節（低字節）表示索引號，從0開始。第二字節（高字節）表示描述符的類型編號。

B．除了獲取字符串描述符之外，獲取其他類型的描述符時，該域的值都為0。當獲取的是字符串描述符中的語言ID字符串時（字符串描述符也有分類，下文會解析到），該域值就表示語言ID號。

C. wLength域是主機期望設備能返回的總數據字節數，那么，設備實際返回的字節數可以比該域指定的字節數少。比如：Host請求設備描述符的時候，只能返回18字節的數據（因為設備描述符只有18個字節）。

D. wValue、wIndex、wIndex的長度都是2字節，USB協議規定，使用小端模式進行數據傳輸，也就是低字節在前，高字節在后。

(2) 實例

Host請求設備描述符，則請求結構中各個域的為：

bmRequestType	bRequest	wValue	wIndex	wLength
1000 0000 （0x80）	GET_DESCRIPTOR （0x06）	描述符的類型和索引值 0x01 00	0或者語言ID 0x00 00	長度 0x0040

那么Host下發的DATA0數據包的數據為[總線上的數據]：80 06 ?00 01 ?00 00 ?40 00

(3) 主機請求設備描述符的流程

在枚舉階段，USB使用的是控制傳輸。一次數據傳輸可認為是一個事務，事務一般由兩三個包組成。事務=令牌包+數據包+握手包。

控制傳輸分為三個過程：

第一過程：建立過程 第二過程：可選的數據過程 第三過程：狀態過程

對于建立過程，使用一個建立事務（一次數據傳輸過程[有發送方 和 接收方]）。建立事務是一個數據輸出的過程，也就是數據從主機到設備。

令牌包只能使用SETUP令牌包；數據包只能使用DATA0數據包；最后是握手包，設備只能用ACK來應該（如果出錯，則不應答）。使用USB協議分析儀分析建立事務，如下圖：

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數據包的處理 ? ? 在枚舉階段，有很多的數據包以及復雜的傳輸過程，作為開發者，要怎么去處理呢？其實很多地方，USB接口芯片已經處理好了。我們只需要弄清楚過程就可以，區分哪部分是芯片完成的，哪部分是代碼中需要處理的。 ? ? 芯片自動完成的（可認為是芯片內部的硬件自動處理的）：CRC校驗、數據包切換等。 ? ? 需要關注的：SETUP令牌包的中斷、IN令牌包的中斷、ACK握手包的回復等，對于程序來說，就是處理一系列的中斷事件。Host下發的數據指令，比如上面這個例子中的DATA0數據包（80 06 00 01 00 00 40 00）。在程序中會收到這些數據，并且做邏輯上的處理(比如接下來就要把設備描述符的數據返回給主機，回應它的請求)。 ? ? 芯片自動完成的那些事情，數據是沒法捕獲到的，比如，使用Bus Hound這個上位機軟件，只能捕獲到DATA0數據包的數據，在Bus Hound中只能看到成功傳輸的數據，也就是只有ACK確認過的數據包。而使用比較高級的協議分析設備，比如專業的USB協議分析儀，就可以將整個過程都可視化。

數據過程是可選的，也就是一個控制傳輸，可以沒有數據過程。一旦數據傳輸方向發生了改變，就會進行入狀態過程。狀態過程數據傳輸方向和前面的數據階段相反，狀態過程使用的是DATA1數據包。

繼續接著分析下一個事務，也就是下一個數據傳輸。主機接著下發IN令牌包。設備切換到DATA1數據包，將設備描述符(18 Byte)發送給主機。主機收到數據，進行ACK回應。

設備返回描述符數據的過程如下圖：

因為主機請求的是設備描述符，所以，這里返回的是USB設備的設備描述符數據。

?

3. 設備描述符

每個USB設備都必須并且只有一個設備描述符(在程序中有定義)。USB協議對設備描述符的定義如下：

(1) 設備描述符的結構

偏移量/字節	域	大小/字節	說明
0	bLength	1	描述符的長度 (18Byte=0x12)
1	bDescriptorType	1	描述符類型(設備描述符=0x01)
2	bcdUSB	2	本設備使用的USB協議版本
4	bDeviceClass	1	類代碼
5	bDeviceSubClass	1	子類代碼
6	bDeviceProtocol	1	設備所使用的協議
7	bMaxPacketSize0	1	端點0的最大包長(64 bytes)
8	idVendor	2	廠商ID
10	idProduct	2	產品ID
12	bcdDevice	2	設備版本號
14	iManufacturer	1	描述廠商字符串的索引
15	iProduct	1	描述產品字符串的索引
16	iSerialNumber	1	產品序列號字符串的索引
17	bNumConfigurations	1	可能的配置數

說明：

1）bcdUSB是該設備所使用的USB協議版本號，長度2字節。比如可以取2.0或者1.1等版本號。需要特別注意的是，協議規定使用BCD碼來表示版本號，比如：USB2.0協議就是0x0200，USB1.1協議就是0x0110。對照USB協議分析儀來看的時候，要注意，USB協議中使用的是小端結構，也就是低字節在前。比如說，USB2.0協議拆分成兩個字節就是0x00 0x02，那么對照協議分析儀里面的數據就是：00 02? ；USB1.1在協議分析儀里面的數據就是：10 01。

2）bDeviceClass是設備所使用的類代碼（XX類接口描述符碼）。常用的類如下(根據協議，進行C宏定義)：

//HID設備類接口描述符碼 #define HID_CLASS??????????????????? 0x03 //音頻類接口描述符碼 #define Audio_CLASS???????????????? 0x01 //視頻類接口描述符碼 #define Vedio_CLASS???????????????? 0x0E //大容量設備類接口描述符碼 MASS_STORAGE_CLASS?????????? 0x08 //雜項類或者混合類接口描述符碼 #define MISC_CLASS?????????????????????????? 0xEF //廠商自定義的設備類接口描述符碼 #define CUSTOM_CLASS??????????????????? 0xFF //特定應用類接口描述符碼 #define DFU_DEVICE_CLASS??????????? 0xFE

3）bDeviceSubClass設備所使用的子類代碼。當類代碼不為0也不是0xFF時，子類代碼就得根據協議來進行賦值。當類代碼為0的時候，子類代碼也必須為0。

4）bDeviceProtocol是設備使用的協議。協議代碼由USB協議規定。當該字段為0的時候，表示設備不使用類所定義的協議。該字段為0xFF的時候，表示使用的是廠商自定義的協議。也就是說，bDeviceProtocol要結合設備類和設備子類來進行賦值，如果設備類代碼不為0，則子類代碼肯定也不為0，進而bDeviceProtocol也就不為0（具體的取值，得深入研究USB協議）。如果類代碼為0，則子類代碼也就為0，進而bDeviceProtocol的值也就為0。綜上所述，bDeviceClass、bDeviceSubClass、bDeviceProtocol這三者，要么都同時為0，要么都不為0。一般來說，設備類的定義放到接口里面，所以這三個字段一般都設置為0。

5）端點0的最大包長，取值可以是:8、16、32、64字節。注意，對應的十六進制數分別就是：0x08、0x10、0x20、0x40(分析源碼和協議分析儀里面的數據，注意進行轉換)。

6）關于廠商ID (2Byte)，在開發中，可以隨意設定一個值。真正做產品，要使用公司的ID(向USB協會申請)，避免侵權。對于插入的設備，主機是依靠廠商ID號、產品ID號、產品序列號來安裝驅動的。

7）產品ID是生產廠商自己定義的，比較自由。

8）bcdDevice設備版本號。同一個產品，升級之后(比如固件修改，新增功能)，可以通過修改設備版本號來進行區別。

9）iManufacturer是描述廠商字符串的索引值。如果設為0，則表示該USB設備沒有廠商字符串。主機單獨獲取廠商字符串的時候，下發的標準請求數據包中，wValue域的第一個字節【低字節】就是廠商字符串的索引值，而高字節就是描述符的類型(字符串描述符0x03)。

廠商字符串就是一串普通的字符串，在設備描述符中，有三個非0的索引值：廠商字符串的索引值為1；產品字符串的索引值為2；產品序列號字符串的索引為3。設備在收到主機的字符串描述符請求之后，根據索引值，將對應的字符串數據返回給主機。所以，如果解析到主機字符串描述符請求的數據包，如果wValue=0x0301，則表示主機請求獲得廠商字符串。

10）iProduct是描述產品的字符串的索引值。同樣的，如果設置為0，則表示該USB設備沒有產品字符串。第一次插上設備時，提示發現新硬件，并顯示設備的名稱，其實這里顯示的信息就是從產品字符串中獲取的。實驗:可通過修改產品字符串，再編譯固件燒錄，插入設備，就可以看到提示信息了。

同理，當主機請求產品字符串的時候，wValue這個域的值應該是：0x0302

11）iSerialNumber是設備的序列號字符串的索引值。同樣的，如果設置為0，則表示該USB設備沒有設備序列號。最好一個產品指定一個唯一的序列號，因為有可能主機會結合產品序列號和VID、PID來進行設備的區分和加載對應的驅動。

同理，當主機請求序列號字符串的時候，wValue這個域的值應該是：0x0303

注：

?? 廠商ID 、產品ID和序列號字符串是不一樣的。

---

下文對源碼的分析，僅供參考。

(2) 設備描述符在源碼中的定義

對于設備描述符這個數據結構，可以抽象定義成一個結構體。在zephyr的原生代碼中，設備描述符的定義處如下：

?

4. 代碼流程分析

(1) usb_handle_control_transfer()函數

這是設備核心層中的API，端點0有數據（數據輸入/輸出事務）的時候，usb_handle_control_transfer()會被回調。假如是一個標準請求，那么可以根據bmRequest域的值來進行判斷，接下來數據的傳輸方向，只有兩種情況:

A. 設備---->主機[bmRequest=0x80]，也就是設備收到了一個請求，主機要求它接下來要把特定的請求的數據發給主機。 B. 主機---->設備[bmRequest=0x00]，也就是設備收到了一個請求，通過解析請求，它知道接下來主機要下發數據。

在USB通信中，數據的收發是通過端點來進行的。各種描述符之間的關系，大概如下：

設備描述符(一個設備有且只有一個設備描述符)【up】

--------------------------------------------------------------------------------------

配置描述符

接口描述符

---------------------------------------------------------------------------------------

端點描述符 【bottom】

?

端點存在這幾種狀態，在源碼中，定義如下：

文件：usb_dc.h

/** ?* USB Endpoint Callback Status Codes ?* 端點回調狀態碼定義 ?*/ enum usb_dc_ep_cb_status_code { ?? /*已經收到SETUP數據包 */ ? ?/*如果是標準請求，那么SETUP數據包就是完整的8字節標準請求數據包 */ USB_DC_EP_SETUP,??? /* SETUP received =0*/ ???????? ???????? /* Out transaction on this EP, data is available for read =1*/ /* Host通知設備，在該端點上進行的是:數據輸出事務 */??? /* 并且，數據已經可以進行讀取 */ ???????? USB_DC_EP_DATA_OUT, ? ?? //在該端點上，一個數據輸入事務已經完成。 ?? //一個事務，就是一次數據傳輸， ? ?USB_DC_EP_DATA_IN,? /* In transaction done on this EP =2*/ };

回到usb_handle_control_transfer()的分析，該函數主要是進行數據傳輸方向的判斷和端點狀態的檢測，對于枚舉過程，首先從這個函數入手進行分析（整個API是處理控制傳輸的），原型定義如下：

(2) 一個標準請求處理的流程

首先一個標準請求會使得usb_handle_standard_request()被回調[暫時不分析底層控制器]。然后在函數體內，usb_handle_std_device_req()會被調用，真正地去處理標準請求指令是在usb_handle_std_device_req()里面。也就是前者是被觸發，進行回調，后者是被調用。這兩個函數定義的地方分別如下：

請求獲得設備描述符、請求設置地址、請求獲得配置描述符等標準請求，都要從下面這個函數開始進行分析。

在這個階段，以Host請求獲得設備描述符為例，接著進行分析。

分析usb_get_descriptor()這個函數，可以大概知道：先提取描述符的類型，判斷是屬于哪一種描述符，比如是設備描述符，然后，到描述符空間[一個地址，里面存放的是描述符的數據，設備描述符定義好之后，會進行注冊]進行遍歷，根據偏移量進行遍歷進行尋找，該函數的定義處:

看函數體里面的注釋，結合USB協議，可以知道:對于全速模式和低速模式的設備，獲取描述符的標準請求只有三種。單獨請求獲取設備描述符、單獨請求獲取配置描述符、單獨請求獲取字符串描述符。接口描述符和端點描述符是跟著配置描述符一起返回的，不可單獨返回，根據他們之間的包含關系（一個配置描述符可以有很多個接口，一個接口可以有很多個端點……），如果單獨返回，主機沒法解析（不符合協議）。實際上，主機也不會單獨請求獲取。

找到設備描述符之后，通過usb_data_to_host()將數據發送到主機。一層層剖析，可以發現，數據的發送是通過端點0進行發送的(符合協議)。usb_data_to_host()里面調用的是usb_dc_ep_write()，進入usb_dc_ep_write()可以發現，該函數完成數據的發送，還可以獲取到發送成功的數據字節數。

發送的大概過程(結合代碼和協議): 將設備描述符數據寫入到端點0的輸入緩沖區中，并使能端點發送。主機下發IN令牌包之后，設備的USB控制器就將緩沖區中的數據返回給主機，主機收到數據，則下發ACK握手包到設備，設備收到握手包就可以確認數據已經成功傳輸到主機了(這部分也是硬件自動完成的，對用戶不可見)。

兩個函數的定義處，分別如下:

主機在成功獲取第一個數據包的設備描述符并確認無誤之后，就會返回一個0長度的確認數據包(狀態過程，使用的是DATA1數據包)，設備收到確認數據包，就知道發送的數據是無誤的，接下來設備發送握手包給主機，結束一個控制傳輸過程?？刂苽鬏斶^程比較復雜，幾次交互，有可見的數據交互，也有不可見的數據交互，雖然復雜，但是能保證數據的可靠性。

到此，一個控制傳輸過程結束【建立過程(主機下發請求)、狀態過程(設備返回數據) 狀態過程(主機返回0長度的數據包)】。設備描述符總共有18個字節。

串口跟蹤打印如下：

總結大概的流程: 有請求----->解析請求----->返回數據

需要注意的是，端點狀態的回調(能反映數據的通信過程是否完整，開始或者結束)。

USB協議分析儀上捕獲到的完整的總線數據：

Packet: 包 ? ? ? ? Transation: 事務 ? ? ?? Transfer: 傳輸

?

5. 總結

(1) Host請求返回64個字節(0x40)的數據，但是實際上，設備描述符只有18字節。即返回的字節數可以小于或者等于wLength（協議規定）。

(2) 芯片自動處理的令牌包: ACK握手包（對用戶不可見，一般的USB上位機捕獲軟件也沒能捕獲到，只有USB協議分析儀可以）。

(3) 這個過程總共有三個事務，每個事務的構成 = 令牌包 + 數據包 + 回應包，這三個事務又構成一次傳輸。

(4) 主機請求設備描述符這個階段，使用的是控制傳輸類型，數據包在DATA0和DATA1之間進行切換。

(5) USB協議分析儀能夠圖形化分析每個流程。注意結合: USB協議分析儀 + 協議文檔 + 源碼。

(6)?主機在這個階段【還沒有復位總線】是和地址為0的USB設備的端點0進行數據通信。

(7) 都是Host在主動

Host檢測到DP/DM電平有變化，說明有device接入; 緊接著就獲取設備描述符(發出SETUP 和 IN_TOKEN包)； ...........................................................................................

以上是Host檢測到Device插入，第一次請求設備描述符的過程。

?

下一篇：https://blog.csdn.net/qq_40088639/article/details/109752441

總結

以上是生活随笔為你收集整理的第五篇 USB设备枚举过程(1)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。