本篇筆記將詳述 CDC設備枚舉過程，讓大家對整體的枚舉過程有個概念。

為了更好到理解并分析接下來的通信流程，魚鷹首先介紹標準請求和描述符。

上篇筆記了解了標準請求和描述符是怎么回事，但還不夠，還需要更細節的東西。

首先從標準請求的8字說起：

第一字節：位圖請求信息。 D7 代表了接下來傳輸的數據是從主機到從機，還是從機到主機的。我們知道枚舉過程使用控制傳輸，有三個階段，如果有數據階段，那么這個階段的DATA數據是由主機發出還是由從機發出，就看這個位的值了。 當然了，因為每一次事務都有令牌包存在，所以IN令牌后的數據一定是由從機發出的，但是標準請求的這個位可以讓從機做好發送數據或者接收數據的準備。

D6~D5：代表了請求類型。 請求類型代表本次請求屬于什么類型的請求。目前有三類，標準、類、廠商。標準請求主要有：

除了標準請求，還有類請求，比如 CDC 類，用到了三種類請求： SET_LINE_CODING（0x20） 設置串口波特率、起始位、停止位、流控等信息 GET_LINE_CODING（0x21） 獲取串口波特率、起始位、停止位、流控等信息 SET_CONTROL_LINE_STATE（0x22）用于設置串口的狀態 廠商請求一般不會用于標準設備，CDC 類就沒有用到（如果需要的話，應該也是能發出的）。 D4~D0：代表了請求類型。 因為請求的內容可能是面向設備，也可能面向接口、端點，所以這個域確定了本次請求面向的對象，這樣設備可以根據請求的對象作相應的措施。 第二字節：bRequest：請求代碼，即上面的幾種請求代碼，每個請求都會有請求代碼，代表了具體請求。 第三四字節：wValue：這個雙字節主要根據bReuest來確定含義，比如如果是獲取描述符（GET_DESCRIPTOR），而描述符有很多種，比如設備描述符、字符串描述符、配置描述符，那么到底主機要獲取什么描述符？就看這個雙字的高字節了。如果高字節為 1，代表獲取設備描述符，高字節為 2，代表獲取配置描述符。 總之這個值的具體含義需要根據請求代碼來確定，而每一種請求代碼都會明確規定wValue具體含義。 第五六字節：wIndex：這個值和上面一樣，也是需要請求代碼來確定含義的。比如在獲取產品序列號字符串時，這個值代表了語言 ID，告訴從機需要返回什么哪種字符串，當值為0x0409時代表英語。 第七八字節：wLenth：這個值代表接下來主機會發送或者需要接收字節長度。 一般來說，主機會根據需要在接下來的數據階段獲取或發送指定長度數據，主機發送的數據因為是由主機控制的，所以可以很容易確定這個值，但是因為主機并不清楚從機到底有多少數據會返回，所以這個值可能會比實際的更大。 比如第一次獲取設備描述符時，因為主機不清楚這個描述符多長，一般會比實際的描述符長度更大，所以如果從機沒有足夠的數據返回，那么只要返回從機能返回的最大數據即可； 但是如果主機請求返回的數據比從機實際的數據短，那么從機就按照主機的要求來就行，不必把自己所有的數據返回。 以上就是標準請求的內容。設備返回的描述符通用格式比較簡單： 第一字節：描述符總長度（包括本字節） 第二字節：描述符類型（對應標準請求wValue的高字節） 其余字節就代表了這個描述符的具體內容了，每種描述的具體內格式都不相同，需要根據實際的描述符確定，比如：

bcdUSB 代表 USB 版本號，比如 0x0110，代表 USB 1.1 版本（bcd編碼，即寫成十六進制時的版本號），這樣主機就知道這個設備只支持全速 12 Mbit/s 那么關于關于高速的請求qualifier（wValue 高字節為6）就不用發送到該設備了，因為發送給設備也肯定會被回復 STALL，那么主機就沒必要浪費這個帶寬了。 但是如果你這里寫成 0x0200，那么這個設備可能是全速的，也可能是高速的，那么主機就會發送請求來詢問是否支持高速，如果設備不支持，回復的描述符設置為0即可。 接下來的三個字節根據設備屬于什么類別來確定，比如 CDC 類，這三個值分別為 0x02 ，0x00，0x00。 bMaxPacketSize0 確定了端點0的數據包大小，主機可以據此知道設備的傳輸能力，進而控制傳輸數據包的大小，不然主機一次發送的數據包太大，那么從機可能無法正確接收。 idVendor 由 USB-IF 分配，這個值確定了這個設備屬于哪個廠家的產品。比如 0xC251，代表了KEIL，只要主機看到了這個代號，就知道這個設備由哪個廠家生產的了，因為這個在USB-IF中掛了號，大家都可以從網上查到。 和必須購買的 idVendor 不同卻類似的是，iProduct 是由廠家自己定義的，可以根據這個來確定這個設備屬于哪個產品。 這個USB設備更新到哪一個版本了？通過bcdDevice 即可確定，也是bcd 編碼。 iManufacture 代表廠商的字符串序號，一般都是 1，這樣當主機需要獲取廠商的字符串，只要在wValue 的低字節為設置為 1，那么從機就知道該發送什么字符串給主機了。 iProject 代表產品字符串序號，一般為2。 iSerialNumber 代表產品序列字符串序號，一般為3。 為什么從 1 開始編號，而不是從 0 開始呢，這是因為如果設備沒有這個字符串的話，可以設置該值為 0，這樣主機就知道沒有這個字符串，也就不會主動獲取這個字符串。 當然了，即使你告訴了主機有這個字符串存在，主機也是按照需求來獲取的，不一定會把所有的字符串描述符都獲取回來。 iNumConfigurations 代表了設備有多少種配置，前面說過，設備可能會在不同時刻的功能表現不一樣，那么可以通過該值確定這個設備有多少種配置，一般而言這個值是1，即只有一種配置。畢竟復合設備可以同時滿足多功能的要求，沒必要使用多種配置來達到多種功能的要求。 以上就是設備描述符的具體含義，其他描述符比如配置描述符、接口描述符、端點描述符等就自行看魚鷹給的資料理解即可，只要找到對應描述符的格式說明，分析代碼中的描述符數據也不是那么難的事情。 接下來魚鷹介紹枚舉總體流程。 主機在對設備復位后，首先會請求獲取設備描述符。這個描述符一般為18個字節，但是主機一開始并不知道這個描述符多大（雖然一般是18，但萬一不是呢），所以一般主機會以更大的請求長度來獲取，而從機根據實際長度18字節返回即可。 現在我們從多個維度看看這次交互的數據情況： 從傳輸事務的角度看：

從包的角度看：

從DATA內容看： 主機發送數據：80 06 00 01 00 00 40 00

從機回復數據：

從D+、D-數據線電平變化的角度： 主機發送（建立階段）：

從機回復（數據階段）：

狀態階段：

現在把整個枚舉過程大概圖解一遍（其他請求交互的具體情況請看魚鷹提供的資料）：

數據流截取（魚鷹提供的《CDC設備完整數據通信.txt》）：