USB協(xié)通訊議--深入理解

0. 基本概念

一個【傳輸】(控制、批量、中斷、等時)：由多個【事務】組成；

一個【事務】(IN、OUT、SETUP)：由一多個【Packet】組成。

USB數(shù)據(jù)在【主機軟件】與【USB設備特定的端點】間被傳輸?！局鳈C軟件】與【USB設備特定的端點】間的關聯(lián)叫做【pipes】。一個USB設備可以有多個管道(pipes)。

1. 包(Packet)

包（Packet）是USB系統(tǒng)中信息傳輸?shù)幕締卧?，所有?shù)據(jù)都是經(jīng)過打包后在總線上傳輸?shù)?。?shù)據(jù)在 USB總線上的傳輸以包為單位，包只能在幀內傳輸。高速USB 總線的幀周期為125us，全速以及低速 USB 總線的幀周期為 1ms。幀的起始由一個特定的包（SOF 包）表示，幀尾為 EOF。EOF不是一個包，而是一種電平狀態(tài)，EOF期間不允許有數(shù)據(jù)傳輸。
注意：雖然高速USB總線和全速/低速USB總線的幀周期不一樣，但是SOF包中幀編號的增加速度是一樣的，因為在高速USB系統(tǒng)中，SOF包中幀編號實際上取得是計數(shù)器的高11位，最低三位作為微幀編號沒有使用，因此其幀編號的增加周期也為 1mS。

•USB總線上的情形是怎樣的？

•包是USB總線上數(shù)據(jù)傳輸?shù)淖钚挝唬荒鼙淮驍嗷蚋蓴_，否則會引發(fā)錯誤。若干個數(shù)據(jù)包組成一次事務傳輸，一次事務傳輸也不能打斷，屬于一次事務傳輸?shù)膸讉€包必須連續(xù)，不能跨幀完成。一次傳輸由一次到多次事務傳輸構成，可以跨幀完成。

USB包由五部分組成，即同步字段（SYNC）、包標識符字段（PID）、數(shù)據(jù)字段、循環(huán)冗余校驗字段（CRC）和包結尾字段（EOP），包的基本格式如下圖：

1.1 PID類型(即包類型)

1.2 Token Packets

此格式適用于IN、OUT、SETUP、PING。

PID 數(shù)據(jù)傳輸方向

IN Device->Host

OUT Host->Device

SETUP Host->Device

PING Device->Host

1.3 Start-of-Frame(SOF) Packets

SOF包由Host發(fā)送給Device。
1) 對于full-speed總線，每隔1.00 ms ±0.0005 ms發(fā)送一次；
2) 對于high-speed總線，每隔125 μs ±0.0625 μs發(fā)送一次；
SOF包構成如下圖所示：

1.4 Data Packets

有四種類類型的數(shù)據(jù)包：DATA0, DATA1, DATA2,and MDATA，且由PID來區(qū)分。DATA0和DATA1被定義為支持數(shù)據(jù)切換同步(data toggle synchronization)。

1.5 Handshake Packets

• ACK:對于IN事務，它將由host發(fā)出；對于OUT、SETUP和PING事務，它將由device發(fā)出。

• NAK:在數(shù)據(jù)階段，對于IN事務，它將由device發(fā)出；在握手階段，對于OUT和PING事務，它也將由device發(fā)出；host從不發(fā)送NAK包。

2. 事務(Transaction)

在USB上數(shù)據(jù)信息的一次接收或發(fā)送的處理過程稱為事務處理（Transaction）即：The delivery of service to an endpoint。一個事務由一系統(tǒng)packet組成，具體由哪些packet組成，它取決于具體的事務?？赡苡扇缦掳M成：

• 一個token packet

• 可選的data pcket

•可選的handshake packet

•可選的special packet

2.1 輸入（IN）事務處理

輸入事務處理：表示USB主機從總線上的某個USB設備接收一個數(shù)據(jù)包的過程。

•【正常】的輸入事務處理

•【設備忙】時的輸入事務處理

•【設備出錯】時的輸入事務處理

2.2. 輸出（OUT）事務處理

輸出事務處理：表示USB主機把一個數(shù)據(jù)包輸出到總線上的某個USB設備接收的過程。

•【正?！康妮敵鍪聞仗幚?br />

•【設備忙時】的輸出事務處理

•【設備出錯】的輸出事務處理

2.3 設置（SETUP）事務處理

•【正?！康脑O置事務處理

•【設備忙時】的設置事務處理

•【設備出錯】的設置事務處理

3.USB傳輸類型

在USB的傳輸中，定義了4種傳輸類型：

•控制傳輸 (Control Transfer)

•中斷傳輸 (Interrupt Transfer)

•批量傳輸 (Bulk Transfer)

•同步傳輸 (Isochronous)

3.1 控制傳輸 (Control Transfer)

控制傳輸由2～3個階段組成：

1) 建立階段(Setup)

2) 數(shù)據(jù)階段（無數(shù)據(jù)控制沒有此階段）(DATA)

3) 狀態(tài)階段(Status)

控制數(shù)據(jù)由USB系統(tǒng)軟件用于配置設備(在枚舉時)，其它的驅動軟件可以選擇使用control transfer實現(xiàn)具體的功能，數(shù)據(jù)傳輸是不可丟失的。

3.1.1 建立階段

主機從USB設備獲取配置信息，并設置設備的配置值。建立階段的數(shù)據(jù)交換包含了SETUP令牌封包、緊隨其后的DATA0數(shù)據(jù)封包以及ACK握手封包。它的作用是執(zhí)行一個設置（概念含糊）的數(shù)據(jù)交換，并定義此控制傳輸?shù)膬热?即：在Data Stage中IN或OUT的data包個數(shù)，及發(fā)送方向，在Setup Stage已經(jīng)被設定)。

3.1.2 數(shù)據(jù)階段

根據(jù)數(shù)據(jù)階段的數(shù)據(jù)傳輸?shù)姆较?，控制傳輸又可分?種類型：

1) 控制讀?。ㄗx取USB描述符）

2) 控制寫入（配置USB設備）

3) 無數(shù)據(jù)控制

數(shù)據(jù)傳輸階段：用來傳輸主機與設備之間的數(shù)據(jù)。

•控制讀取

是將數(shù)據(jù)從設備讀到主機上，讀取的數(shù)據(jù)USB設備描述符。該過程如下圖的【Control Read】所示。對每一個數(shù)據(jù)信息包而言，首先，主機會發(fā)送一個IN令牌信息包，表示要讀數(shù)據(jù)進來。然后，設備將數(shù)據(jù)通過DATA1/DATA0數(shù)據(jù)信息包回傳給主機。最后，主機將以下列的方式加以響應：當數(shù)據(jù)已經(jīng)正確接收時，主機送出ACK令牌信息包；當主機正在忙碌時，發(fā)出NAK握手信息包；當發(fā)生了錯誤時，主機發(fā)出STALL握手信息包。

•控制寫入

是將數(shù)據(jù)從主機傳到設備上，所傳的數(shù)據(jù)即為對USB設備的配置信息，該過程如下的圖【Control Wirte】所示。對每一個數(shù)據(jù)信息包而言，主機將會送出一個OUT令牌信息包，表示數(shù)據(jù)要送出去。緊接著，主機將數(shù)據(jù)通過DATA1/DATA0數(shù)據(jù)信息包傳遞至設備。最后，設備將以下列方式加以響應：當數(shù)據(jù)已經(jīng)正確接收時，設備送出ACK令牌信息包；當設備正在忙碌時，設備發(fā)出NAK握手信息包；當發(fā)生了錯誤時，設備發(fā)出STALL握手信息包。

3.1.3 狀態(tài)階段

狀態(tài)階段：用來表示整個傳輸?shù)倪^程已完全結束。
狀態(tài)階段傳輸?shù)姆较虮仨毰c數(shù)據(jù)階段的方向相反，即原來是IN令牌封包，這個階段應為OUT令牌封包；反之，原來是OUT令牌封包，這個階段應為IN令牌封包。

對于【控制讀取】而言，主機會送出OUT令牌封包，其后再跟著0長度的DATA1封包。而此時，設備也會做出相對應的動作，送ACK握手封包、NAK握手封包或STALL握手封包。

相對地對于【控制寫入】傳輸，主機會送出IN令牌封包，然后設備送出表示完成狀態(tài)階段的0長度的DATA1封包，主機再做出相對應的動作：送ACK握手封包、NAK握手封包或STALL握手封包。

3.2 批量傳輸 (Bulk Transfer)

•用于傳輸大量數(shù)據(jù)，要求傳輸不能出錯，但對時間沒有要求，適用于打印機、存儲設備等。

•批量傳輸是可靠的傳輸，需要握手包來表明傳輸?shù)慕Y果。若數(shù)據(jù)量比較大，將采用多次批量事務傳輸來完成全部數(shù)據(jù)的傳輸，傳輸過程中數(shù)據(jù)包的PID 按照 DATA0-DATA1-DATA0-…的方式翻轉，以保證發(fā)送端和接收端的同步。
•USB 允許連續(xù) 3次以下的傳輸錯誤，會重試該傳輸，若成功則將錯誤次數(shù)計數(shù)器清零，否則累加該計數(shù)器。超過三次后，HOST 認為該端點功能錯誤（STALL），放棄該端點的傳輸任務。
•一次批量傳輸（Transfer）由 1 次到多次批量事務傳輸（Transaction）組成。
•翻轉同步：發(fā)送端按照 DATA0-DATA1-DATA0-…的順序發(fā)送數(shù)據(jù)包，只有成功的事務傳輸才會導致 PID 翻轉，也就是說發(fā)送端只有在接收到 ACK 后才會翻轉 PID，發(fā)送下一個數(shù)據(jù)包，否則會重試本次事務傳輸。同樣，若在接收端發(fā)現(xiàn)接收到到的數(shù)據(jù)包不是按照此順序翻轉的，比如連續(xù)收到兩個 DATA0，那么接收端認為第二個 DATA0 是前一個 DATA0 的重傳。

它通過在硬件級執(zhí)行“錯誤檢測”和“重傳”來確保host與device之間“準確無誤”地傳輸數(shù)據(jù)，即可靠傳輸。它由三種包組成(即IN事務或OUT事務)：

1) token

2) data

3) handshake

1) For IN Token (即：IN Transaction)

•ACK: 表示host正確無誤地接收到數(shù)據(jù)

•NAK: 指示設備暫時不能返回或接收數(shù)據(jù) (如：設備忙)

•STALL:指示設備永遠停止，需要host軟件的干預 (如：設備出錯)

2) For OUT Token(即：OUT Transaction)

如果接收到的數(shù)據(jù)包有誤，如：CRC錯誤，Device不發(fā)送任何handshake包

•ACK: Device已經(jīng)正確無誤地接收到數(shù)據(jù)包，且通知Host可以按順序發(fā)送下一個數(shù)據(jù)包

• NAK: Device已經(jīng)正確無誤地接收到數(shù)據(jù)包，且通知Host重傳數(shù)據(jù)，由于Device臨時狀況(如buffer滿)

•STALL: 指示Deviceendpoint已經(jīng)停止，且通知Host不再重傳

3) Bulk讀寫序列

即由一系統(tǒng)IN事務或OUT事務組成。

3.3 中斷傳輸(Interrupt Transfer)

中斷傳輸由IN或OUT事務組成。

中斷傳輸在流程上除不支持PING 之外，其他的跟批量傳輸是一樣的。他們之間的區(qū)別也僅在于事務傳輸發(fā)生的端點不一樣、支持的最大包長度不一樣、優(yōu)先級不一樣等這樣一些對用戶來說透明的東西。
主機在排定中斷傳輸任務時，會根據(jù)對應中斷端點描述符中指定的查詢間隔發(fā)起中斷傳輸。中斷傳輸有較高的優(yōu)先級，僅次于同步傳輸。
同樣中斷傳輸也采用PID翻轉的機制來保證收發(fā)端數(shù)據(jù)同步。下圖為中斷傳輸?shù)牧鞒虉D。

中斷傳輸方式總是用于對設備的查詢，以確定是否有數(shù)據(jù)需要傳輸。因此中斷傳輸?shù)姆较蚩偸菑腢SB設備到主機。

DATA0或DATA1中的包含的是中斷信息，而不是中斷數(shù)據(jù)。

3.4同步傳輸(Isochronous Transfer)

1) 它由兩種包組成：

1) token

2) data

同步傳輸不支持“handshake”和“重傳能力”，所以它是不可靠傳輸。

同步傳輸是不可靠的傳輸，所以它沒有握手包，也不支持PID翻轉。主機在排定事務傳輸時，同步傳輸有最高的優(yōu)先級。

同步傳輸適用于必須以固定速率抵達或在指定時刻抵達，可以容忍偶爾錯誤的數(shù)據(jù)上。實時傳輸一般用于麥
克風、喇叭、UVC Camera等設備。實時傳輸只需令牌與數(shù)據(jù)兩個信息包階段，沒有握手包，故數(shù)據(jù)傳錯時不會重傳。

Isochronous data is continuous and real-time in creation, delivery, and consumption. Timing-relatedinformation is implied by the steady rate at which isochronous data is received and transferred. Isochronousdata must be delivered at the rate received to maintain its timing. In addition to delivery rate, isochronousdata may also be sensitive to delivery delays. For isochronous pipes, the bandwidth required is typicallybased upon the sampling characteristics of the associated function. The latency required is related to thebuffering available at each endpoint.

A typical example of isochronous data is voice. If the delivery rate of these data streams is not maintained,drop-outs in the data stream will occur due to buffer or frame underruns or overruns. Even if data isdelivered at the appropriate rate by USB hardware, delivery delays introduced by software may degrade applications requiring real-time turn-around, such as telephony-based audio conferencing.

The timely delivery of isochronous data is ensured at the expense of potential transient losses in the data stream. In other words, any error in electrical transmission is not corrected by hardware mechanisms such as retries. In practice, the core bit error rate of the USB is expected to be small enough not to be an issue. USB isochronous data streams are allocated a dedicated portion of USB bandwidth to ensure that data can be delivered at the desired rate. The USB is also designed for minimal delay of isochronous data transfers.