USB協議：控制傳輸（二）

本篇筆記寫的很糙，在這里你會看到很多專業名詞，可能會一臉懵逼，但還是先發出來給大家看看，沒有基礎的不用細看，大概了解即可，后面的筆記將把這些內容揉碎了再呈現給大家。而且當時看的例程是 HID 鼠標的，比較復雜，內核代碼也沒有使用狀態機，比較難以理解，但是魚鷹接下來的例程用了狀態機，并且魚鷹畫了整個狀態機的運行流程圖，將更加清晰易懂，所以 HID 的例程暫時就不再提供給大家。

現在和電腦通信基本上是采用 USB 進行通信，所以我們有必要學習 USB 協議。而 USB 協議中最重要的一種傳輸就是控制傳輸。

串口通信在設置串口波特率、連上線后是沒有數據傳輸的，只有在電腦或設備發送數據時，線上才會有數據傳輸，而 USB 設備不同，在設備插入電腦時，電腦就開始和設備進行交流了，就像人們剛見面就打招呼似的。但是 USB 主機可不是僅僅問你（USB 設備）有沒有吃飯什么的，而是全面的了解你的信息（必要信息）。

為了獲得你的信息，就必須有一個通道，還有一個雙方支持的通信格式才行。所以就有了控制端點?？刂贫它c是一個具有雙向通信能力的默認端點（也叫缺省端點），是一個 USB 設備必須支持的端點。初期的枚舉過程都在該端點上完成。枚舉過程是一個 USB 設備必須經歷的一個過程。通過枚舉，讓主機了解設備的一些基本信息。而枚舉過程的實現就是通過控制傳輸實現的。我們通過枚舉過程來了解控制傳輸。

首先確定控制傳輸是四大傳輸之一，也是最基本的傳輸，所有的 USB 設備都必須支持。它是可靠的傳輸，具有最少兩個個階段，建立階段（Setup Stage）、狀態階段（Data Stage），還有一個數據階段（Status Stage）是可能會有的。建立階段是由建立傳輸事務（Setup Transaction）實現的，狀態階段和數據階段是由數據輸出（Data Out Transaction）或輸入事務（Data IN Transaction）實現的（如果數據太多，將會采用多次數據輸入或輸出事務）。如下圖，本文將主要講這圖中的內容，一定要明白它們之間的關系。

各種可能的控制傳輸過程：

（SETUP（0）由三個包組成：SETUP Packet 、DATA0 Packet、ACK Packet；

OUT（1）由三個包組成：OUT Packet 、DATA1 Packet、ACK Packet；

IN（1）由三個包組成：IN Packet 、DATA0 Packet、ACK Packet 。這里的 SETUP 、DATA0 、ACK 、OUT 、IN 是 PID）

一個事務又是由各種包組成的。包又分為四大類包：Token（令牌）Packet、Data（數據） Packet、 Handshake（握手）Packet、特殊 Packet。每類包中又分為各種具體的包（由 PID（Packet ID）確定該包屬于哪一種包）。需要注意的是包是 USB 傳輸最小的傳輸單位、所有數據都必須進行打包才可以進行傳輸，包格式如下。

（灰色區域表示每個包都有，彩色表示可能有）

因為有各種不同的包，各種包的具體格式也不盡相同。所以我們只分析我們需要的包。為了簡化內容，讓我們能夠將注意力集中在我們需要的東西上，我們都以包來進行說明，包里面具體的其他內容，將選擇性的了解，對于包，我們也只對需要的包進行說明。

令牌包：SETUP 包、OUT 包、IN 包。（主機發送）

主機最開始會發出的包，標志一次傳輸事務的開始，里面有 PID（標志這個是什么包，SETUP 包中的 PID 就是 SETUP）、地址（包括設備地址，端點地址）、CRC（對地址信息進行校驗）。在程序中我們可以知道是什么類型的包。

數據包：DATA0 包、DATA1 包。（主機設備都可以發送）

里面有 PID、數據、CRC（對數據信息進行校驗）。這是用戶真正要關心的數據。里面的數據我們是可以進行查看的。我們枚舉過程處理的就是這些數據。

握手包：STALL 包、NAK 包、ACK 包（主機只能發送 ACK 包）

里面只有 PID。

ACK 包：表示正確接收數據，并且有足夠的空間來容納數據，主機和設備都可以用 ACK 確認，而 NAK，STALL，NYET 只有設備能夠返回，主機不能使用（因為請求都是主機發送，當主機發送請求了，就說明已經準備好了，自然不應該有這些回答）。

NAK 包：表示沒有數據需要返回，或者數據接收正確但是沒有足夠的空間來容納數據，當主機收到 NAK 是，知道設備沒有準備好，主機會在合適的時機進行重新傳輸。

STALL 包：表示設備無法執行這個請求，或者端點已經被掛起，它表示一種錯誤的狀態。設備返回 STALL

后需要主機進行干預才能解除這種 STALL 狀態。

注意:返回 NAK 并不代表數據出錯,只是說明設備暫時沒有數據傳輸或暫時沒有能力接收數據 . 當主機或設備檢測到數據出錯時(如 CRC 校驗出錯，PID 校驗出錯，位填充出錯等 )將什么也不返回。這時等待握手包的一方就會因為收不到握手包而等待超時。

現在有了這些基礎知識，我們為了更清楚認識控制傳輸，就通過講解 usb_core.h、 usb_core.c 文件（本文必須結合這兩個文件）來了解枚舉過程，進而認識控制傳輸。

之前也說過，枚舉過程是通過控制傳輸實現的，那么現在就來看看當你把一個 USB 設備插入主機時，它的枚舉過程是怎樣的。

首先，弄清楚一點，這兩個文件處理的就是枚舉過程，也是整個 USB 程序中最最核心的部分，所有的 USB 相關的文件都是以它為基礎。它定義了各種結構體，各種聯合體。而其他文件就是根據這個結構體、聯合體進行具體的定義，并且寫出具體的實現的方法。弄明白這兩個文件是重中之重。

因為控制傳輸比較復雜，和上一個狀態有很大關系。所以定義了一個枚舉類型 CONTROL_STATE 確定程序當前的各種狀態。還有結構體 ENDPOINT_INFO、DEVICE_INFO、DEVICE_PROP，還有一個特殊的結構體 USER_STANDARD_REQUESTS 等各種類型。

CONTROL_STATE：確定當前的端點的傳輸狀態

ENDPOINT_INFO：端點傳輸數據的信息，包括要發送或接收的剩余數據長度，已經發送或接收的數據偏移，該端點的最大包長（決定了該端點一次處理的數據的能力），要發送或接收數據的地址。（數據長度和地址由具體的函數提供，這個結構體有一個函數指針指向具體實現函數。也就是說要接收或發送數據的大小和地址是由具體的函數實現的）。

DEVICE_INFO：包含了設備的狀態信息，控制端點的傳輸狀態（CONTROL_STATE 控制傳輸狀態），控制端點的信息（ENDPOINT_INFO 的具體實現），還有標準請求的數據信息。

DEVICE_PROP：這里面包含了具體的實現函數。如具體設備的硬件相關的函數實現

void (*Init)(void);，復位信號發過來時的處理函數void (*Reset)(void);，控制傳輸中的狀態階段的處理函數void (*Process_Status_IN)(void);void (*Process_Status_OUT)(void);，發送接收函數的具體實現函數，就是之前的 ENDPOINT_INFO 中需要的具體實現函數。等等。

USER_STANDARD_REQUESTS：這個結構體就比較特殊了，因為這個結構體的函數是用來給用戶使用的。比如主機發送了什么信息過來，我們把數據發出去了，那么我們還要告知用戶（我們的程序），我們做了這些操作才行，但是這些操作函數有的可以省去的，而不會影響正常通信，雖然不會影響正常通信，但是對設備本身還是有可能有影響的。

現在我們來具體看看主機與設備是怎么通信的，所以看它的使用函數 void CTR_LP(void)（usb_int.c 文件），USB 通信是在中斷函數中的。

在我們插上 USB 設備時，枚舉過程數據(串口接收到的數據)：

1.SETUP：80 6 1 0 40 發送數據：112 200 0 4000 483 5710 200 201 103 IN：OUT：

2.SETUP：0 5 100 0 0 IN：

3.SETUP：80 6 1 0 12 發送數據：112 200 0 4000 483 5710 200 201 103 IN：OUT：

4.SETUP：80 6 2 0 ff 發送數據：209 22 101 e000 932 4 100 103 2 2109 100 100 4a22 700 8105 403 2000 IN：OUT：

5.SETUP：80 6 303 904 ff 發送數據：31a 38 ff ff ff 33 41 37 31 21 63 15 57 IN：OUT：

6.SETUP：80 6 3 0 ff 發送數據：304 409 IN：OUT：

7.SETUP：80 6 203 904 ff 發送數據：322 41 4c 49 45 4e 54 45 4b 20 89e6 63a7 55 53 42 9f20 6807 IN：OUT：

8.SETUP：80 6 6 0 a

9.SETUP：80 6 1 0 12 發送數據：112 200 0 4000 483 5710 200 201 103 IN：OUT：

10.SETUP：80 6 2 0 9 發送數據：209 22 101 e000 932 IN：OUT：

11.SETUP：80 6 2 0 22 發送數據：209 22 101 e000 932 4 100 103 2 2109 100 100 4a22 700 8105 403 2000 IN：OUT：

12.SETUP：0 9 100 0 0 IN：

13.SETUP：21 a 0 0 0

注意：因為用的是 printf 函數發送的，所以有些是省去了，有些高字節和低字節可能換了，所以分析時要注意。

我們現在主要分析傳輸過程，而不是具體數據的處理，所以不要太關心具體數據。

我們假設前期工作都做好了，USB 能通信了，既然如此，程序必定會進入 usb_int.c 文件中的 void CTR_LP(void)函數。當第一次進入此函數時，就說明一次傳輸事務成功完成。從包的角度來看就是主機發送一個 SETUP 包，再發一個 DATA 包，設備確認數據的正確性（從 PID 和 CRC 確定）然后發送 ACK 包。設備硬件將該端點自動設置為 NAK（此時如果主機發送包過來，一律以 NAK 回應，表示忙著呢，還沒有準備好），使設備有足夠的時間處理 DATA 包中的數據。在這之后程序才運行到了 CTR_LP（）函數里。

程序每運行到這里一次，意味著主機發送的設備地址和端點號正確，也意味著一次傳輸事務的結束。這一點要牢記。

現在我們看著設備接收到的數據再理一理過程。（以下內容必須結合附帶工程進行驗證）

SETUP：80 6 1 0 40 發送數據：112 200 0 4000 483 5710 200 201 103 IN：OUT：

設備的一次傳輸事務結束了（從 SETUP：看出）（第一次進入 CTR_LP（）），先判斷這次傳輸事務是什么類型傳輸事務（STM32 中有一個標志位可以進行判斷），然后發現是建立令牌包，那么就是建立傳輸事務，現在就轉到建立傳輸事務程序中。

在該程序中，先把數據包中的數據拷貝出來再說。

拷完了，同時設置當前的設備狀態為 SETTING_UP，表示開始處理一次建立事務，然后發現這是一個有數據階段的建立傳輸事務而且是設備發送數據給主機（怎么發現的就看具體的標準請求格式吧，現在只說結果）。

好吧，看看要什么數據，發現要設備描述符，長度是 64 字節。那行，只是我的設備描述符只有 18 字節，怎么辦，不管，就發 18 字節過去。

發送完這 18 字節后程序第二次進入了 CTR_LP（）函數（從 IN：看出），剛剛設備把數據發送出去了，這次進入相關處理函數也就沒什么事干了，就等著主機發送狀態數據過來呢，所以設置設備狀態為 WAIT_STATUS_OUT，表示正在等待主機發送狀態數據（之后發送端點狀態設為 STALL，表示如果主機發送 IN 令牌包將以 STALL 握手包進行回應）。

然后第三次進入 CTR_LP（）函數（從 OUT：看出），因為是 OUT 包，所以是一次數據輸出事務的完成（沒有寫錯，就是輸出，這是對于主機來說），這時設備就知道這應該是狀態階段的數據了，經過一系列的判斷，發現確實是（之后發送接收端點都設置為 STALL）。

到這里一個完整的控制傳輸過程算是完成了。但是一個枚舉過程是由很多這樣的控制傳輸過程構成的。

SETUP：0 5 100 0 0 IN：

第二次建立傳輸事務又來了（從 SETUP：看出），也標志著一次控制傳輸的開始（建立階段）?？纯从袥]有數據要發送或輸入，嗯，好像沒有，而且是設置地址的（這里有地址信息，就是 1），那行，開始設置地址吧？

那可不不行，USB 協議規定，設置地址的工作必須在設備發送狀態數據（狀態階段沒有具體的數據，也就是說數據區為 0 字節）到主機，主機接收到后發送 ACK 握手包后被設備接收到才能進行設置設備的地址（為什么這么規定，可能是防止中間出現問題吧）。

所以在程序中還真沒進行設置地址的工作，而是只是設置設備當前的狀態為 WAIT_STATUS_IN，什么意思，就是表示設備正在等待發送狀態數據呢（為什么要等，而不是直接發送，這是因為 USB 是有主從關系的，主機沒叫你發送數據，你是不能發送數據的，你只能把數據放在緩存區中，并且設置發送端點有效。當設備收到 IN 令牌包時，它就自動由硬件發送出去了）。

當主機成功收到狀態階段的數據時就會發送 ACK 握手包。然后設備接收到了握手包，這時也就意味著一次數據輸入事務（狀態階段）的結束，此時，程序再次運行到 CTR_LP（）這里（從 IN：看出），并進入到相關處理函數，這時相關處理函數就會設置地址了，此后發送和接收的端點再次變為 STALL。

上面這些都是正常的控制傳輸，如果不正常（不正常不代表數據出錯，而是請求不合理）的呢？我們跳過正常的，直接看下面這一次控制傳輸。

SETUP：80 6 6 0 a

看這條請求代碼是 6（后面那個），要求發送 10 個字節數據給主機，但是我的設備沒有這種代碼為 6 的描述符，怎么辦。USB 協議規定有些請求是必須支持的，但是有些請求卻不一定要支持。這個描述符沒有應該怎么處理呢。

分析程序，最終你會發現控制狀態設置為 STALLED，也就是說在主機下一個 IN 令牌包（在此之前主機可能已經發送了多次 IN 令牌包過來，只是設備都以 NAK 包進行回應）來的時候，設備會返回一個 STALL 包，當主機收到這個握手包之后，就知道設備不支持該請求，它就會放棄繼續發送 IN 令牌包，而是發送 SETUP 包，因為設備控制端點處于 STALL 狀態時，必須主機進行干預才能幫助設備解除這種狀態。

由于此次控制傳輸是設備不支持的請求，所以就沒有數據階段，同時也沒有狀態階段，既然不需要發送或接收數據，也就不會在建立傳輸事務來之前再次進入程序了。但是如果發送的請求為輸出數據，那么程序就會直接接收數據了。

說了這么多，下面進行一些總結：

1. 程序運行到 CTR_LP（）里面，就說明一次事務傳輸的完成，不管是建立事務還是數據輸入輸出事務。注意是已經完成，而不是將要完成。

2. 數據如果出錯了，只會有錯誤中斷產生，而不會產生傳輸完成中斷，也就不會進入 CTR_LP()服務程序中。

3. 注意分析每一次事務傳輸的完成將使當前端點的發送接收狀態產生何種影響，又會對之后的事務傳輸產生何種影響。

4. 每一次控制傳輸的結束，都會使端點發送和接收狀態都設為 STALL。

5. 控制傳輸在請求不支持情況下沒有狀態階段的數據。

6. 建立階段也由三個包組成，SETUP 令牌包 、DATA0 數據包（只能是 DATA0）、ACK 握手包。也是一次建立事務。

7. 數據階段也由三個包組成，OUT/IN 令牌包 、DATA0/1 數據包、ACK 握手包。也是一次數據輸出或輸入事務。在建立傳輸中有可能有多次該傳輸事務。

8. 狀態階段也由三個包組成，OUT/IN 令牌包 、DATA1 數據包、ACK 握手包。也是一次數據輸出或輸入事務。但是它沒有用戶所使用的數據。

9.OUT、IN 是對于主機來說的。OUT 就是主機向設備發送數據。

10. 注意根據實際數據進行分析。

注意：如果使用 USB 協議分析軟件，你會發現軟件的捕獲數據不全，所以要根據設備串口發送的數據進行分析

審核編輯 黃宇