我們可以將整個USB資料通訊過程看成是由一個一個的資料包構成，而這些資料包又分很多類，比如：令牌包，資料包，握手包，幀起始包。令牌包又分In包，Out包，Setup包。有一點我覺得對於剛開始接觸USB的人來說，一定要弄清楚這麼多包，哪些是由硬體自動來處理，哪些是要由驅動程式去處理的，如果這點沒有弄清楚，寫或者看驅動程式碼時往往會摸不著頭腦.下面通過分析USB Host讀取USB裝置描述符整個過程來說明這個問題：

題：

<!--[if !vml]--><!--[endif]-->

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這些步驟，其他的差不多都由硬體自動完成了。