本文轉自公眾號系列文章,歡迎關注
基于DWC2的USB驅動開發-USB包詳解 (qq.com)

前言

http://www.qd573.com/outside?redirect=https://mp.weixin.qq.com/s/gm5OAutfnYv6H_5Ce8GEqA一文中我們介紹了控制傳輸，中斷相關寄存器,尤其是DOEPINTn.XferCompl，DOEPINTn.SetUp，DOEPINTn.StsPhseRcvd幾個狀態的組合非常重要，因為由他們可以確定當前控制傳輸處于什么階段。前文我們對此進行了介紹，但是個人覺得講的還不夠透徹，原理還沒有講清楚，知其然知其所以然是我們一開始就強調的，所以針對這個幾個標志位我們再次更詳細的介紹，先來介紹最關鍵的DOEPINTn.SetUp。

DOEPINTn.SetUp

Setup是DOEPINTn寄存器中的一個標志，用于表示Setup階段是否完成。

我們這里可能要問DIEPINTn為什么沒有SetUp標志，因為Setup總是HOST->DEV的，所以總是OUT傳輸，所以總是對應OUT端點的，IN端點的寄存器不可能有。這里強調一下我們一定要多問為什么，先思考猜測，然后再從手冊規格書中查找答案，只有這樣才能加深理解，USB開發中這是很重要的，當然任何技術性的工作這一點都重要。

我們從寄存器的描述中也可以看到，該位表示SetUP階段完成，并且只有控制OUT端點有。

還有個信息是本次控制傳輸沒有連續的SETUP，意味著軟件可以開始解析SETUP的8字節的內容以決定下一步要干嘛了。如果有連續的SETUP則是最后一個SETUP完成才能進行。

那么究竟SETUP完成對應的一個什么狀態呢? 硬件是怎么知道SETUP階段完成的呢？ 主機和設備判斷SETUP完成有什么區別嗎? 我們會拋出一連串問題，如果能拋出這些問題說明你很適合做底層和驅動開發!

后面我們會抽絲剝繭，從原理到實踐，從猜測到手冊中求證，一層層剖析。

這里我們要回顧下控制傳輸，

我們從規格書中的拓撲圖可以看到，控制傳輸的SETUP階段過程如下

或者換個表達方式如下

或者從USB分析儀抓包數據來看，更形象。

SETUP階段對應3個包:SETUP令牌包；DATA0的數據包，始終是HOST->DEV；設備的響應ACK。

這里順便提一下，SETUP的數據始終使用DATA0;而設備要么正常接收并接受ACK，要么接收錯誤或者沒接收到不響應，只有這兩種情況，不能接收了不接受而NAK或者STALL等。

這里還順便提一下接收和接受的概念區別。接收通常指的物理層數據正確接收到了，而接受則指的軟件能夠處理，或者說愿意處理。 接收了也可能不接受。

這里協議層面我們可以看到SETUP階段完成的標志是，設備ACK響應了。

如下所示

仔細思考下，這里只是協議上的定義，也就是對應的總線上的數據，至于SETUP完不完成是要由參與者HOST和DEV去確定的，換句話說總線上的狀態并不意味參與者就是這個狀態了，因為參與者還要正確接收到總線上的數據才算。

對于主機接收到了設備發送的ACK那么主機認為SETUP階段完成，如果設備發了ACK但是主機沒收到呢？那么主機認為SETUP沒完成，會認為本次失敗，從頭發SETUP包重來。

同樣的對于設備來說將ACK發送到總線上去后，設備并不知道HOST接收沒接收到，設備并不知道主機的狀態。所以主機和設備對SETUP完成的狀態確認存在不同步。

那怎么辦呢? 設備并不知道主機認為SETUP完成了沒有，因為設備并不知道主機收沒收到ACK。就好比子非魚安知魚之樂，有點繞了。

其實也沒什么辦法，設備確實現在不知道主機是不是認為SETUP完成了，但是設備可以根據主機下一步的行動來確定。因為主機如果接收到了ACK，認為SETUP完成了那么主機下一步就會發IN或者OUT令牌進入數據階段(或者狀態階段)，否則則會重發SETUP重新進入SETUP階段。

設備可以據此來進行判斷，如果收到了主機的IN或者OUT令牌，則確認主機認為SETUP已經完成了，于是設備也知道SETUP完成了，這里設備和主機判斷SETUP完成的時間點是不一樣的，這就是協議定義和實際判定存在的區別。所以對于協議設計一定要考慮這種區別，協議設計了要考慮如何實現，也就一直強調的理論要結合實踐，對于驅動編寫更需要考慮從這些細節。

以上恭喜你從頭開始推導出了設備判斷SETUP完成的原理，那么回到上面的標志位DOEPINTn.SetUp即表示SETUP階段完成，DWC2控制也是這么判斷的嗎？所謂英雄所見略同，DWC2控制器還真是這么判斷的。

上面寄存器的描述中只提了該標志的含義，并沒提其具體置位的原理和時機，實際編程指導手冊中是有說明的。

如下位置，手冊就進行了說明當，SETUP令牌之后，接收到了IN或OUT令牌則置位DOEPINTn.SetU，和我們推導的完全一致。

為什么是IN或OUT呢，因為控制傳輸可能是控制寫，控制讀，還可能無數據階段的控制傳輸，所以后面要不就是IN數據或者OUT數據或者IN狀態，如下所示

控制寫

控制讀

無數據階段的控制傳輸

驅動編寫注意事項

從上面可以看到設備是延遲才能確認SETUP完成的，也就是在SETUP后設備收到了主機發的IN和OUT之后才確認，中斷也是在此時產生。

對于控制寫，上面設備確認SETUP完成產生中斷，中斷服務函數開始去解析8字節的SETUP內容，來確定數據階段要干嘛，后面數據階段是IN還是OUT或者還是沒有數據階段直接狀態階段，其實是數據階段(狀態階段)已經啟動，設備延遲了。

此時中斷服務函數還未執行，軟件還沒根據解析準備IN或者OUT描述符，所以此時對于這個IN或者OUT，硬件只能自動NAK，如下所描述:

所以這種情況下，中斷服務函數中進行了解析，并知道要準備OUT描述進行接收時，設置EPEna=1時還要同時設置CNAK=1，清除硬件的自動NAK狀態，讓硬件根據OUT描述符去接收數據。

對于控制讀后面是IN數據階段，或者無數據階段的控制傳輸后面是IN狀態，也是類似的。

總結

以上對DOEPINTn.SetUp進行了詳細的解析，因為它太重要了，SETUP階段是控制傳輸的核心，因為只有SETUP完成才能去解析8字節的內容，才能決定后續干嘛，對于驅動編寫接收到8字節的SETUP數據是第一個關鍵步。以上也可以看出一定要從原理上去理解，這也是驅動編寫的重要原則，必須知其然知其所以然，精確的知道各個時間點的各個時間，以及其條件等，注意精確兩個字。

審核編輯：湯梓紅