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

總述

1. 設備枚舉的整個過程

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

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

2. 說明

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

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

（3）關于Zephyr操作系統(tǒng)的USB協(xié)議棧，后續(xù)有介紹。

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

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

?

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

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

一、Host獲取設備描述符

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

1. USB的標準請求

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

(1) 標準請求的結構

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

對各個字段的描述：

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

[bRequest]: 請求代碼

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

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

[wLength]: 數(shù)據(jù)過程需要傳輸?shù)淖止?jié)數(shù)（可能為0，沒有數(shù)據(jù)過程，那就是0）

?

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

USB協(xié)議定義了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

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

USB協(xié)議規(guī)定，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這個域，第一字節(jié)（低字節(jié)）表示索引號，從0開始。第二字節(jié)（高字節(jié)）表示描述符的類型編號。

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

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

D. wValue、wIndex、wIndex的長度都是2字節(jié)，USB協(xié)議規(guī)定，使用小端模式進行數(shù)據(jù)傳輸，也就是低字節(jié)在前，高字節(jié)在后。

(2) 實例

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

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

那么Host下發(fā)的DATA0數(shù)據(jù)包的數(shù)據(jù)為[總線上的數(shù)據(jù)]：80 06 ?00 01 ?00 00 ?40 00

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

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

控制傳輸分為三個過程：

第一過程：建立過程 第二過程：可選的數(shù)據(jù)過程 第三過程：狀態(tài)過程

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

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

?

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

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

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

設備返回描述符數(shù)據(jù)的過程如下圖：

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

?

3. 設備描述符

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

(1) 設備描述符的結構

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

說明：

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

2）bDeviceClass是設備所使用的類代碼（XX類接口描述符碼）。常用的類如下(根據(jù)協(xié)議，進行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時，子類代碼就得根據(jù)協(xié)議來進行賦值。當類代碼為0的時候，子類代碼也必須為0。

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

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

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

7）產(chǎn)品ID是生產(chǎn)廠商自己定義的，比較自由。

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

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

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

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

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

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

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

注：

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

---

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

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

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

?

4. 代碼流程分析

(1) usb_handle_control_transfer()函數(shù)

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

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

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

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

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

配置描述符

接口描述符

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

端點描述符 【bottom】

?

端點存在這幾種狀態(tài)，在源碼中，定義如下：

文件：usb_dc.h

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

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

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

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

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

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

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

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

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

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

兩個函數(shù)的定義處，分別如下:

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

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

串口跟蹤打印如下：

總結大概的流程: 有請求----->解析請求----->返回數(shù)據(jù)

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

USB協(xié)議分析儀上捕獲到的完整的總線數(shù)據(jù)：

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

?

5. 總結

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

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

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

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

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

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

(7) 都是Host在主動

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

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

?

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。