首先，要明白兩個觀點。第一，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這些步驟，其他的差不多都由硬件自動完成了。