USB協議簡介

USB協議簡介
    USB是一種協議總線，即主機與設備之間的通信需要遵循一系列約定。協議內容較多，這裏僅作一些簡單介紹，深入學習，可參看USB規範(WWW．usb．org)。
    爲了理解協議中的名稱，先看圖10．32。該圖突出了主機上的客戶軟件和USB邏輯設備(編程涉及的設備)之間的通信流(Communication Flow)，該通信流跨越了USB驅動程序USBD、主控制器驅動程序UHCD、主控制器等硬件接口及其連接。端點(Endpoints)是USB設備的惟一可識別的部分，是主機和設備之間通信流的終點。每一個邏輯設備有若干個獨立端點，每一個端點在設計時被分配一個惟一的由設備確定的標識符，稱之爲端點號。
    如圖10．32所示，將用於通信流流動的通道稱爲管道(Pipe)，這是忽略了許多中間環節的很形象的稱呼，對於理解USB系統中的信息傳輸很有幫助。圖中把3個端點看成了一個接口，關於接口的說明安排在後面。

1．包格式
包的概念在前面已經介紹了，包是幀的基本成分。常用的包有令牌包、數據包和握手包。對於高速傳輸，還定義了事務分割專用令牌包(事務分割開始令牌包和事務分割完成令牌包)。
  1)令牌包格式
  在USB系統中，所有的通信都是由主機發出相應的令牌所引起的。令牌包格式圖
10．33所示。
    其中PID爲包標識，ADDR爲設備地址，ENDP爲端點號，CRC5是對ADDR和ENDP域進行校驗的5位CRC校驗碼，校驗多項式爲：G(X)=X⁵+X²+1。
  2)數據包格式
  數據包用於主機與設備之間的數據傳輸。數據包格式如圖10．34所示。
  其中PID爲包標識，DATA爲數據位，最多爲8 192個位，DATA應是字節的整數倍。CRCl6是對DATA域進行校驗的16位CRC校驗碼，校驗多項式爲：G(X)=X¹⁶+X¹⁵+X²+1.



3)握手包格式
    握手包用來指示數據被成功接收、命令被接收或被拒絕等事務狀態。握手包格式如圖10．35所示。
    握手包僅由PII)組成。有四種常用握手包(ACK、NAK、STALL和NYET)和一個專用握手包，握手包的類型是通過PID的編碼來體現的。
·ACK包表示接收器已成功接收數據。
·NAK包表示接收設備不能接收數據或發送設備不能發送數據。
·STALL包表示端點已終止或不支持控制管道請求。 
·NYET包表示接收器還沒有任何響應。
    4)幀開始包SOF(Start Of Frame)

 

在全速或低速時，主機每隔1 ms±0．0005 ms發出一個幀開始包SOF，在高速時，每隔125 μs±0．0625μs發出一個SOF，以表示開始一個新幀。SOF包的格式如圖10．36所示。
   

    
    其中FmmeNumber爲幀編號，每發一幀後FrameNumber加l，當11位都爲1(即3FFH)時再加1又回到0。在SOF包中對FrameNumber域進行CRC校驗。
    2．PID域格式
    上面的幾種包的開始都是PID域。PID域的格式如圖10．37所示。

    低4位用來標識不同的包，高4位分別爲低4位的非。這樣安排是爲了保證對PID可靠的譯碼，從而也使得包的其他部分能得到正確解釋。表lO．20表示了PID編碼和對應的PID類型。其中第3列是PID的低4位，即PID編碼。
    表中有兩種數據包PID，都用於數據的傳輸，以它們開頭的兩種數據包除了包PID部分有一位(及與它對應的反向位)不同外，其他部分都相同。設置這兩種數據包是爲了使發送方和接收方保持同步，這涉及到一些細節，將在10．3．6小節中介紹。在圖10．38～10．40中不妨將它們看成一種數據包。



    3．USB傳輸的處理過程
    前面已經提到USB系統中有四種傳輸：一個傳輸通常要分解成若干個事務；而一個事務的處理一般要經歷令牌包、數據包和握手包三個階段，但也有一些事務的處理沒有數據包階段或沒有握手包階段，還有一些事務只有令牌包階段。下面對這四種傳輸的處理過程分別作一些介紹。
    1)塊傳輸
    用於主機與USB設備之間的批量數據傳輸，通常一次塊傳輸需要分解成若干個塊傳輸事務。顯然，一次塊傳輸的方向是單一的，對主機而言，要麼是輸入，要麼是輸出。因此，一次塊傳輸是由若干個IN事務或由若干個OUT事務組成的。圖10．38所示是塊傳輸事務處理過程示意圖。圖中的PING包和NYET包僅用於高速傳輸設備，初學者暫時可以不考慮。

    對於要進行輸入的塊傳輸，一般要執行若干個IN事務。每執行一個IN事務時，主機都首先發出IN令牌包。設備端點收到後做出響應，一般是回送一個數據包。如果不能回送數據，則回送NAK包或STALL包。NAK表示設備暫時不能回送數據；STALL表示端點一直停着或需要IJSB系統軟件進行干預；如果主機收到合法數據包，則回以ACK握手包；如果主機在接收數據時發現有錯，則不給設備任何迴音。
    對於要進行輸出的塊傳輸，一般要執行若干個OUT事務。每執行一個OUT事務時，主機都首先發出OUT令牌包，接着發出數據包。設備在收到數據包後，根據情況回以握手包；回以ACK表示數據已接收無誤，並通知主機可開始下一個0UT事務，以便傳送下一個數據包；回以NAK表示數據已接收無誤，但是主機不要再送數據，因爲設備暫時不能接收(如緩衝區滿)；如果端點已終止，則回以STALL，通知主機不要再重發數據，因爲設備出現了故障；如果接收時出現CRC校驗錯，則不發任何握手包。
    需要指出，IN事務和OUT事務不僅在塊傳輸事務中用到，在其他幾種傳輸事務中也要用到，當然，處理的過程可能有所不同。
    2)中斷傳輸
    用於數據傳輸量小，無週期性，但對響應時間敏感，要求馬上響應的數據傳輸。中斷傳輸的名字暗示一個設備可以引起一個硬件中斷，這個硬件中斷將使主機進行快速響應。但真實情況是中斷傳輸和所有其他USB傳輸一樣，只在主機訪問設備時出現。之所以將其稱爲中斷傳輸，是因爲它可保證主機將在最短的延遲裏響應或發送數據。中斷傳輸的特別之處在於主機將按照特定的週期訪問可引起中斷的端點(稱爲中斷端點)，看是否有中斷情況發生。圖10．39所示爲中斷傳輸事務的處理過程。

對於要進行輸入的中斷傳輸，主機按照特定的週期執行IN事務，如果沒有中斷髮生，中斷端點回以NAK包；如果有中斷情況發生，則回送中斷數據。主機收到數據後，發一個ACK包。
    對於要進行輸出的中斷傳輸，主機按照特定的週期執行OUT事務，在發送OUT令牌後，接着發送數據包。如果沒有中斷髮生，中斷端點回以NAK包或STALL包；如果有中斷情況發生且接收數據無誤，則回送ACK包。需要指出，在設備沒有中斷髮生的情況下，主機一直會按照特定的週期執行OUT事務，並且所發送的數據保持不變。當有中斷髮生時，才修改數據指針，指向下一個數據區。
    一箇中斷傳輸由一個或多個IN事務或者一個或多個OUT事務組成。一箇中斷傳輸用以下兩種情況之一結束：當請求的數據量被傳送完時，或者當數據包的長度小於規定的最大值(包括0長度包)時。中斷傳輸的結束表示要傳送的數據已經到齊，接收方可以加以利用；而主機對中斷端點週期性的查詢還將繼續進行下去，以便在下一個中斷情況發生時，開始下一個中斷傳輸。
    3)等時傳輸
    用於有週期性、傳輸速率不變的數據傳輸。等時傳輸在每幀中傳送的字節數是一定的。一個等時傳輸由一個或多個連續幀裏每幀一個IN或一個OUT事務所組成。圖10．40表示了等時傳輸事務的處理過程。可以看出，等時傳輸的IN事務和OUT事務只包括令牌包和數據包兩個階段，沒有握手包階段，也不支持重試。
    4)控制傳輸
    控制傳輸提供了一種方法來配置USB設備，並對它的操作的某些方面進行控制。每個設備必須設置一個缺省的控制端點(通常是O號端點)。控制端點用來配置設備、控制設備狀態以及設備操作的某些方面。控制端點響應一些通過控制傳輸發送過來的USB特殊請求。例如，當系統檢測到設備時，系統軟件必須讀取該設備的描述符，以確定其類型和操作特性。
    控制傳輸至少由兩個階段組成，也可以是三個階段：
    ①SETUP階段：控制傳輸總是從SETUP階段開始，這個階段把信息發送給目標設備，定義對設備的請求類型(例如，讀設備描述符)。
    ②數據階段：這個階段僅僅是爲需要數據傳輸的請求定義的。例如，在數據階段，讀描述符請求把描述符的內容發送給主機。一些請求在SETUP階段之外不需要數據傳輸。
    ③狀態階段：這個階段總是用來報告被請求的操作的結果。
    在SETUP階段，一個SETUP事務被用來向控制端點傳輸信息。SETUP事務類似於
一個OUT事務，只是包標識PID是SETUP，而不是OUT。圖10．41所示爲SETUP事務的執行過程。SETUP事務的數據階段總是利用DATA0 PID。如果接收正確，控制端點則回以ACK包；如果接收不正確或數據丟失，則不回送任何握手包。
    控制傳輸的數據階段不是必需的。如果需要有這個階段，則它由一個或多個IN事務或者一個或多個OUT事務組成。數據階段的所有事務的方向必須是一致的，即都是IN事務或都是OUT事務。數據階段傳送的數據量及方向是在SETUP階段規定的。如果數據量超過了預先確定的數據包規模，則數據的發送需要多個能攜帶最大包的事務(IN或OUT)，剩下的部分(不足最大包規模)再安排一個事務。
    控制傳輸的狀態階段是該傳輸的最後一個階段，它只需要一個事務。狀態階段的數據流方向應該與前面的階段不同，並且總是利用DATAl PID.例如，如果數據階段執行的是OUT事務，則狀態階段就是一個IN事務。如果一個控制傳輸沒有數據階段，則狀態階段由一個IN事務組成。圖10．42所示爲控制讀傳輸、控制寫傳輸以及沒有數據階段的控制傳輸的事務排列順序、觸發位的值(在括號內)及數據PID的類型。


    上面介紹的傳輸及傳輸事務的處理過程反映了USB系統中數據傳輸的過程。注意到一幀(或微幀)中包括了四種傳輸事務，所以實際的傳輸過程要比這裏所講的複雜。
4．數據觸發技術
    在USB系統中採用了數據觸發技術。數據觸發是一種機制，用來確保數據傳輸的發送方和接收方之間保持同步，對於需要大量事務的一次長傳輸過程尤爲重要。數據觸發機制可以使握手包出錯情況下發送方和接收方之間能重新同步。
    數據觸發僅僅支持中斷傳輸、塊傳輸和控制傳輸。支持數據觸發機制的發送方和接收方在每一次數據傳輸時都必須具有觸發位。當雙方都認爲數據傳輸已經正確完成以後，都會把自己的觸發位轉換爲和原來相反的狀態。兩種類型的數據包(DATAO和DATAl)被交替傳送，並且包的接收方將會把它和觸發位作比較，以確定接收的包是否正確。發送方使用的數據包類型和它的觸發位當前狀態保持一致(例如，如果觸發位爲0，則數據包用DATA0)。下面僅以OUT事務爲例來理解數據觸發機制。
    例10．1  圖10．43所示爲無錯誤的OUT事務的處理過程和觸發位的變化情況。假定發送方和接收方的觸發位開始都是0。傳輸的過程

 

如下：
    事務處理l：



①主機向目標設備發送一個OUT令牌。
②目標設備無錯誤地收到該令牌包。
③主機向目標設備發送一個DATA0數據包(和它的觸發位保持一致)。
④目標設備收到數據包DATA0，它和觸發位一致。
⑤目標設備成功收到數據包DATA0，觸發位轉變爲1。
⑥目標設備向主機發送一個ACK握手包，通知主機數據已經被無錯誤接收。
⑦主機無錯誤地收到ACK包。
⑧成功地收到ACK包，主機把觸發位轉變爲l。
事務處理2：
①主機向目標設備發送一個新的OUT令牌，開始下一個事務處理過程。
②目標設備無錯誤地收到該令牌包。
③主機向目標設備發送一個DAl、A1數據包(和它的觸發位保持一致)。
④目標設備收到數據包DATAl，它和觸發位一致。
⑤目標設備成功收到數據包DATAl，觸發位轉變爲0。
⑥目標設備向主機發送一個ACK握手包，通知主機數據已經被無錯誤接收。
    ⑦主機無錯誤地收到ACK包。
    ⑧成功地收到ACK包，主機把觸發位轉變爲0。
    這個處理過程對每一個事務都是如此，直到整個傳輸完成。只要收到的數據包和觸發位相一致，並且發送方無錯誤地收到ACK握手包，那麼發送方和接收方就保持同步。
    上面是數據包和握手包都被正確傳輸的情況。下面分別看一下數據包傳輸出錯和握手包傳輸出錯時的情況。
    例l0.2  圖10．44所示爲一個傳輸的第m個OUT。事務的處理過程，期間數據包傳輸出現了錯誤。主機和目標設備所採取的行動如下：
    事務處理m：
    ①主機向目標設備發送一個OUT令牌。
    ②目標設備無錯誤地收到該令牌包。    ，
    ③主機向目標設備發送一個DATA0數據包(和它的觸發位保持一致)。
    ④當目標設備收到數據包DATAO時，發現有錯。
    ⑤因爲檢測到數據包的錯誤，目標設備將會忽略這個包。數據被丟棄，不向主機發握手包。因爲數據包沒有正確接收，觸發位保持不變。
    ⑥主機等待握手包的返回，但是沒有響應。在總線超時週期(16個位時間)到達後，主機檢測到沒有響應，於是它認爲數據包的傳輸不成功，主機的觸發位保持不變。主機必須在以後重新進行該事務處理。
  事務m重新進行：
  ①主機再向目標設備發送OUT令牌。
  ②目標設備無錯誤地收到該令牌包。
  ③主機向目標設備發送一個DATAO數據包(和它的觸發位保持一致)，這個數據包在上一次傳送時沒有成功。
    ④目標設備成功地收到數據包DATA0，它和觸發位保持一致。
    ⑤因爲正確收到數據包DATA0，所以目標設備將觸發位轉變爲1。
    ⑥目標設備向主機發送一個ACK握手包，通知主機數據已經被無錯誤接收。
    ⑦主機無錯誤地收到ACK包。
    ⑧成功地收到了ACK包，主機把觸發位轉變爲l。
    由上面的處理過程可以看出，儘管傳輸發生了錯誤，但是主機和目標設備還是能夠保持同步。
    例10．3  圖10．45所示爲一個傳輸的第n個OUT事務的處理過程，期間由於ACK包錯誤而失敗。對錯誤檢測和恢復的每一步列舉如下：
    事務處理n：
    ①主機向目標設備發送一個OUT令牌。
    ②目標設備無錯誤地收到該令牌包。
    ③然後主機向目標設備發送一個DATA0數據包(和它的觸發位保持一致)。
    ④目標設備收到數據包DATA0，它和觸發位一致。
    ⑤目標設備成功收到數據包DATA0，觸發位轉變爲1。
    ⑥目標設備向主機發送一個ACK握手包，通知主機數據已經被無錯誤接收。
    ⑦主機收到的ACK包出現了錯誤。
    ⑧由於主機檢測到了錯誤，所以它不能確定目標設備是否已經成功地接收到數據。因此，主機的觸發位沒有改變(還是0)。主機假定目標設備沒有收到數據，因而會重新進行該事務處理。
    事務n重新進行：
    ①主機再向目標設備發送OUT令牌。
    ②目標設備無錯誤地收到該令牌包。
    ③主機重新向目標設備發送DATA0數據包(和它的觸發位保持一致)，這個數據包在上一次傳

<script language=javascript src="/AD/200611/10.js"></script>

<script language=javascript src="/AD/200611/11.js"></script>

送時不知道目標設備是否已正確接收。
    ④目標設備無錯誤地收到數據包DATA0，但是它和觸發位不一致。
    ⑤目標設備認爲其本身和主機不同步，因而丟棄數據，並且觸發位保持不變(1)。
    ⑥目標設備向主機發送一個ACK握手包，通知主機數據已經被無錯誤接收，這是因爲
主機明顯沒有收到上一次的ACK握手包。
    ⑦主機無錯誤地收到ACK握手包。
    ⑧成功地收到了ACK包，主機把觸發位轉變爲1。現在主機和目標設備就爲下一次的事務處理做好了準備。
    通過該例可以看出，主機和目標設備暫時在數據傳輸是否完成的問題上沒有達成一致。然而，數據觸發機制保證了不同步的狀態能夠被檢測到，並且能夠重新實現同步。