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

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

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

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

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

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

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

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

從包的角度看：

從DATA內容看： 主機發(fā)送數(shù)據(jù)：80 06 00 01 00 00 40 00

從機回復數(shù)據(jù)：

從D+、D-數(shù)據(jù)線電平變化的角度： 主機發(fā)送（建立階段）：

從機回復（數(shù)據(jù)階段）：

狀態(tài)階段：

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

數(shù)據(jù)流截?。~鷹提供的《CDC設備完整數(shù)據(jù)通信.txt》）：