USB控制傳輸過程 詳細解析

首先，要明白兩個觀點。第一，USB總線上所有的事務（數據流傳輸）都是由USB Host主動發起，而USB設備永遠永遠都是隻是被動地接收然後處理USB Host發來的各種各樣的命令（要求）。第二，中斷是USB Host和USB設備之間的信令員，USB Host所有的要求都是通過這個信令員即中斷來通知USB設備。
. 我們可以將整個USB數據通信過程看成是由一個一個的數據包構成，而這些數據包又分很多類，比如：令牌包，數據包，握手包，幀起始包。令牌包又分In包，Out包，Setup包。有一點我覺得對於剛開始接觸USB的人來說，一定要弄清楚這麼多包，哪些是由硬件自動來處理，哪些是要由驅動程序去處理的，如果這點沒有弄清楚，寫或者看驅動代碼時往往會摸不着頭腦.
下面通過分析USB Host讀取USB設備描述符整個過程來說明這個問題：



1．上圖中粉紅色的Packet#表示是主機發出，設備接收包；淡青色的Packet#表示是設備發出，主機接收包。如果區分不了這兩種顏色，可以根據箭頭的方向來區分，“－>”這個表示是主機發出，設備接收的包；”<－” 表示是設備發出，主機接收的包。
2．圖中灰色的部分表示，這些包在寫驅動的時候是不太需要關心的地方，但是要了解有這麼一個過程，這些灰色的部分都是由硬件自動處理.
3．那設備驅動要做的是什麼呢？就是根據設備產生的中斷來讀取、解析、迴應相應的數據包，注意上圖中土黃色和淡藍色兩個數據包。
4. 下面詳細分析整個過程，以及設備驅動該幹些什麼？
1) 在控制傳輸階段，任何一個傳輸都是由Setup包發起(Packet#96)
2) 當USB設備接收到這個包，並識別出這是一個Setup包時，USB設備會產生一個Setup中斷，有的稱之爲控制端點/端點0中斷，以便通知MCU主機有任務下來啦，準備開始做事啦，這個動作都是由硬件自動完成
3) 緊接着Setup包的是，USB主機下達給USB設備具體是什麼任務了，我們可以認爲這個過程幾乎是和Setup中斷同時完成. (Packet#97)
4) 既然發生了Setup中斷，USB設備驅動就可以認爲主機有命令下達，USB設備收到主機下達命令後，由USB設備驅動發送一個Setup應答包，表示說“長官，命令已經收到” (Packet#98)
5) 設備已經接收到了主機的命令，那麼USB設備驅動現在就要解析這個命令，來得知USB主機到底下達的是什麼命令，在這裏通過解析黃色數據 ” 80 06 00 01 00 00 40 00”可以得知該命令的意思是主機要求設備發送設備描述符，具體解析過程就是協議規範的內容了…
6) 既然USB設備已經成功得知了USB主機的命令是要發送設備描述符，那USB設備就趕緊去查找這些設備描述符在哪裏？
7) 那驅動已經找到了設備描述符了，驅動是不是該把這個設備描述符發給USB主機呢？答案是No，No，No，原因就是開篇就提到的，所有的傳輸都是有主機主動發起，設備被動響應。現在雖然USB主機通知設備主機要設備描述符信息，但是主機目前並沒有要求主機將這些信息發回去，所以，設備就算已經找到了描述符，也不能主動給主機發這些信息。打一個不太恰當的比喻，就好比一場足球比賽，教練讓你”活動活動,準備上場”,現在你準備活動已經做完了，那你可不能立馬就衝到場上去踢球，即使你活動完了，你還得等待教練的下一步指示，因爲教練還得安排決定讓誰下場，什麼時候下場比較合適…. 等到教練說”上場吧”，那你就可以上場了… 好像比較扯了….哈哈
8) USB主機下一個IN包通知USB設備迴應剛纔的命令，相當於教練喊”上場”，當USB設備收到這個IN包時，產生一個IN中斷來通知MCU，那這時表示設備收到了”上場”的命令了。(Packet#103)
9) 這時，USB設備驅動把找到的設備描述符發送給USB主機。(Packet#104)
10) 主機收到設備迴應的設備描述符後，給設備發一個握手包，表示已經收到設備的迴應包了。(Packet#105) 11) 接下來，USB主機會發送一個0字節的數據包來作爲狀態響應，並且設備發一個握手包來結束整個過程，這是由硬件自動完成. (Packet#108/109/110)
由此可見，在控制傳輸過程中，USB設備驅動比較關心的應該是4，5，6，8，9這些步驟，其他的差不多都由硬件自動完成了。
今天就寫了這麼多，有時間再寫.. ：）