USB 2.0規範中譯本 第五章 USB數據流模型（上）

第五章 USB數據流模型

本章介紹了數據是如何通過USB進行傳輸的。本章中的內容關係所有開發者。呈現的內容層級在系統的信令和協議定義之上。請參閱第7章和第8章，瞭解有關USB系統部分的更多詳細信息。本章提供的框架信息在第9章到第11章中有進一步的擴展。所有開發者都應該閱讀本章，這樣他們才能理解USB的關鍵概念。

5.1 開發者視角

USB提供主機和連接的USB設備之間的通信服務。然而，終端用戶（end user）看到的將一個或多個USB設備連接到主機的簡單視圖就如圖5-1所示，實際上的實現比圖中所示的要複雜一些。從不同開發者的角度來解釋特定的USB需求，需要不同的系統視圖。USB有幾個必須支持的重要的概念和功能，爲最終用戶提供目前PC所需的可靠操作。爲了便於解釋，將USB以分層的方式呈現，並允許特定USB產品的開發者專注於與其產品相關的特定細節。

 圖5-2顯示了一個更深層次的USB總線概述，確定了系統的不同層，這些層將在本規範的其餘部分中詳細描述。具體而言，有四個重點開發領域:

• USB物理設備:USB電纜末端的硬件，它執行一些有用的終端用戶功能。
• 客戶端軟件:在主機上執行的軟件，對應USB設備。該客戶端軟件通常與操作系統一起提供，或者與USB設備一起提供。
• USB系統軟件:在特定操作系統中支持USB的軟件。USB系統軟件通常與操作系統一起提供，獨立於特定的USB設備或客戶端軟件。
• USB主機控制器(主機端總線接口):允許USB設備連接到主機的硬件和軟件。

四個USB系統組件之間有共享的權利和責任。本規範的其餘部分描述了支持一個function和它的客戶端之間的健壯性、可靠的通信流所需的細節。

如圖5-2所示，主機到設備的簡單連接需要多個層和實體之間的連接交互。USB總線接口層(USB Bus Interface)提供主機和設備之間的物理/信令/數據包的連接。USB設備層(USB device layer)是USB系統軟件對設備執行USB操作的視圖層。function層通過適當匹配的客戶端軟件層爲主機提供附加功能。USB設備層和fucntion層都有各自層內的邏輯通信視圖，它們實際上使用USB接口層來完成數據傳輸。

第6、7和8章中描述的USB通信的物理視圖與第9和10章中介紹的邏輯通信視圖相關。本章描述了那些影響USB開發者的關鍵概念，在繼續閱讀本規範的其餘部分之前，所有人都應該閱讀這些概念，以找到與他們的產品最相關的細節。

爲了描述和管理USB通信，以下概念很重要:

• 總線拓撲:第5.2節介紹了USB的主要物理和邏輯組件以及它們之間的相互關係。
• 通信流模型:第5.3至5.8節描述了主機和設備之間如何通過USB通信，並定義了四種USB傳輸類型。
• 總線訪問管理:第5.11節描述了主機如何管理總線訪問，以支持USB設備的各種通信流。
• 同步傳輸的特殊考慮:第5.12節介紹了需要同步傳輸數據的設備所特有的USB總線特性。非同步設備的設備實現者不需要閱讀第5.12節。

 

5.2 總線拓撲

USB拓撲有四個主要部分:

• 主機和設備:USB系統的主要組件
• 物理拓撲:USB元件之間如何連接
• 邏輯拓撲:描述各種USB元素的角色和職責，以及從主機和設備的角度看USB是如何工作的
• 客戶端軟件到function的關係:客戶端軟件和它在一個USB設備上的相關function接口如何向對方通信

5.2.1 USB主機

主機的邏輯組成如圖5-3所示，包括以下內容:

• USB主機控制器
• USB系統軟件集合(包含USB驅動程序、主機控制器驅動程序和主機軟件)
• 客戶軟件

 USB主機作爲USB總線的協調實體佔據着獨特的地位。除了其特殊的物理位置之外，主機還對USB及其附屬設備負有特定的責任。主機控制對USB總線的所有訪問。只有被主機授予訪問權時一個USB設備才能訪問總線。主機還負責監控USB的拓撲結構。

關於host及其職責的完整討論，請參閱第10章。

5.2.2 USB設備

USB物理設備的邏輯組成如圖5-4所示，包括以下內容:

• USB總線接口
• USB邏輯設備
• Function

USB物理設備爲主機提供了額外的功能。USB設備提供的功能類型差異很大。然而，所有的USB邏輯設備向主機提供統一的基本接口。這允許主機以相同的方式管理不同USB設備(USB層面的控制，具體業務邏輯USB設備自己處理)。

爲了幫助主機識別和配置USB設備，每個設備都會攜帶並向主機報告其配置相關的信息。報告中的一些信息在所有邏輯設備中是統一的，其他信息特定於設備提供的功能。該信息的詳細格式因設備的設備類別而異。

關於USB設備的完整討論，請參考第9章。

5.2.3 物理總線拓撲

如圖5-5所示，USB上的設備通過分層星型拓撲結構物理連接到主機。UISB連接點由一種稱爲hb特殊的USB設備提供。hub提供的附加連接點稱爲端口。主機包括一個稱爲root hub的嵌入式集線器。主機通過根集線器提供一個或多個連接點。向主機提供附加功能的USB設備稱爲function。爲了防止循環連接，對USB的星型拓撲結構進行了分層排序。這導致瞭如圖5-5所示的樹狀結構。

多種功能可以封裝在一個看似單一的物理設備中。例如，一個鍵盤和一個軌跡球可以組合在一個單獨的包中。在包內，單個功能永久連接到一個集線器，而內部hub連接到USB總線。當多個function與一個hub組合在一個包中時，它們被稱爲複合設備。複合設備中的hub和連接到hub的每個function都分配有自己的設備地址。具有多個相互獨立控制的接口（interface,後面會提到該描述符，一種interface表示一種功能）的設備稱爲複合設備。複合設備整體在USB總線上只有一個設備地址。從主機的角度來看，複合設備就像一個獨立的hub，具有多種附加功能。圖5-5展示了一個複合設備。

hub在高速系統中起着特殊的作用。hub將全速/低速信號環境與高速信號環境隔離開來。圖5-6顯示了高速hub支持連接的高速設備。hub還允許USB1.1 hub以全速/低速與其他僅全速/低速設備連接並運行。主機控制器還支持直接連接全/低速設備。第11章詳細描述了hub如何實現兩個信令環境的隔離。

5.2.4 邏輯總線拓撲

當設備以分層星形拓撲物理連接到USB總線時，主機與每個邏輯設備通信，就好像它直接連接到根端口一樣。這創建了圖5-7所示的邏輯視圖，它對應於圖5-5所示的物理拓撲。hub也是邏輯設備，但爲了簡化起見，圖5-7中沒有顯示。儘管大多數主機/邏輯設備活動都使用這種邏輯視角，但主機會保持對物理拓撲的監視，以支持集線器的移除事件的處理。移除hub時，必須從主機的邏輯拓撲視圖中移除所有連接到hub的設備。關於hub的更完整的討論可以在第11章中找到。

 5.2.5 客戶端軟件與fucntion的關係

儘管USB的物理和邏輯拓撲反映了總線的共享特性，但客戶端軟件(CSw)僅操作其感興趣的USB function接口(interface)。用於USB function對應的客戶端軟件必須使用USB軟件編程接口來操作function，而不是與其他總線一樣(例如，PCI、EISA、PCMCIA等)通過內存或I/O訪問直接操縱其功能。在操作過程中，客戶端軟件設計應獨立於可能連接到USB的其他設備。這使得設備和客戶端軟件的設計者能夠專注於硬件/軟件交互設計細節。圖5-8從設備設計者的角度說明了客戶端軟件和USB fucntion相對於圖5-7的USB邏輯拓撲的關係。

 

 5.3 USB通信流

USB提供主機上的軟件與其USB function之間的通信服務。對於不同的客戶端到function的交互，function可以有不同的通信流需求。通過將不同的通信流分離爲不同的USB function，USB可以提供更好的整體總線利用率。每個通信流都利用一些總線訪問來完成客戶端和功能之間的通信。每個通信流都在設備的端點(endpoint)終止。設備端點將識別並接收每個通信流。

圖5-9顯示了比圖5-2的更詳細的視圖。圖5-2中真實通信流的完整定義支持邏輯設備和function層通信流。真實的通信流跨越了幾個接口邊界。第6章到第8章描述了USB“電線”的機械、電氣和協議接口定義，第9章描述了允許從主機端操縱USB設備的USB設備編程接口。第10章描述了兩個主機端軟件接口:

• 主機控制器驅動程序(HCD):USB主機控制器和USB系統軟件之間的軟件接口。該接口允許一系列主機控制器實現，而不要求所有主機軟件依賴於任何特定實現。一個USB驅動程序可以支持不同的主機控制器，而不需要特定的主機控制器實現知識。主機控制器實現者提供支持主機控制器的HCD實現。
• USB驅動程序(USBD):USB系統軟件和客戶端軟件之間的接口。該接口爲客戶端提供了操作USB設備的便利功能。

 在USB系統中，USB邏輯設備表現爲一組端點。端點被分組到不同接口(interface)的端點集。接口是function的視圖。USB系統軟件使用默認控制管道管理設備。客戶端軟件使用管道集(與端點集相關聯)管理接口。客戶端軟件請求在主機上的緩衝區和USB設備上的端點之間通過USB傳輸。主機控制器(或USB設備，取決於傳輸方向)將數據打包，通過USB傳輸。當使用總線訪問通過USB傳輸數據包時，主機控制器也會進行協調。

圖5-10說明了通信流是如何在端點和主機端內存緩衝區之間的管道上傳輸的。以下部分將更詳細地描述端點、管道和通信流。

主機上的軟件通過一組通信流與邏輯設備通信。通信流組由設備軟件/硬件設計者選擇，以有效地將設備的通信要求與USB提供的傳輸特性相匹配。

5.3.1 設備端點

端點是USB設備中唯一可識別的部分，是主機和設備之間通信流的終點。每個USB邏輯設備都由一組獨立的端點組成。每個邏輯設備在設備連接時都有一個由系統分配的唯一地址。設備上的每個端點在設計時都有一個唯一的設備確定標識符，稱爲端點號。每個端點都有一個由設備確定的數據流方向。設備地址、端點號和方向的組合可以確定唯一的端點。每個端點都是單工連接，支持單向數據流:輸入(從設備到主機)或輸出(從主機到設備)。

端點具有決定端點和客戶端軟件之間所需的傳輸服務類型的特徵。端點通過以下方式描述自己:

• 總線訪問頻率/延遲要求
• 帶寬要求
• 端點號
• 錯誤處理行爲要求
• 端點能夠發送或接收的最大數據包大小
• 端點的傳輸類型(詳情參見第5.4節)
• 端點和主機之間數據傳輸的方向

端點編號爲零的端點以外的端點在配置前處於未知狀態，在配置完成前主機可能無法訪問。

5.3.1.1 零號端點需求

所有的USB設備都需要實現一種默認的控制方法，該方法使用到端點號爲零的輸入和輸出端點。USB系統軟件使用這種默認控制方法來初始化和操作邏輯設備(例如，配置邏輯設備)，該方法的傳輸管道即爲默認控制管道(參見第5.3.2節)。默認控制管道提供對設備配置信息的訪問，並允許通用的USB狀態和控制訪問。默認控制管道支持第5.5節中定義的控制轉移。當設備連接、通電並接收到總線復位信號，端點編號爲零的端點總是可訪問的。

能夠高速運行的USB設備必須具備全速運行的最低支持級別。當設備連接到全速運行的hub時，設備必須:

• 能夠成功復位爲全速模式
• 正常併成功響應標準請求:設置地址、設置配置、獲取設備描述符和配置描述符，並返回適當的信息

全速模式運行時，高速設備可能支持也可能不支持其預期功能。

5.3.1.2 非零號端點需求

function可以根據實現需要擁有額外的端點。除了實現默認控制管道所需的兩個端點之外，低速function僅限兩個可選端點。全速設備可以具有僅受協議定義限制的額外端點(即，最多15個附加輸入端點和15個附加輸出端點)。

在設備配置完成之前，不能使用默認控制管道以外的端點(參見第9章)。

5.3.2 管道

USB管道是設備上的端點和主機上的軟件之間的關聯。管道表示通過內存緩衝區和設備上的端點在主機上的軟件之間傳輸數據的能力。有兩種互斥的管道通信模式:

• 流:通過管道傳輸的數據沒有USB定義的結構
• 消息:通過管道傳輸的數據有一些USB定義的結構

USB不解釋它通過管道傳輸的數據內容。即使消息管道要求數據根據USB定義來構造，數據的內容也不由USB來解釋。

此外，管道具有以下關聯:

• 關於USB總線訪問和帶寬使用的聲明。
• 傳輸類型
• 相關端點的特徵，如方向和最大數據負載大小。數據有效負載是總線事務中數據包的數據字段中攜帶的數據(如第8章所定義)。

由端點編號爲零的兩個端點組成的管道稱爲默認控制管道。一旦設備通電並收到總線復位信號，該管道始終可用。當配置了一個USB設備時，其他管道就出現了。USB系統軟件使用默認控制管道來確定設備標識和配置要求，以及配置設備。設備配置後，默認控制管道也可以由特定設備的軟件使用。USB系統軟件保留默認控制管道的“所有權”，並協調其他客戶端軟件對管道的使用。

軟件客戶端通常通過I/O請求包(IRPs)向管道請求數據傳輸，然後等待或在傳輸完成時收到通知。有關IRPs的詳細信息不同操作系統有不同的定義方式。該規範使用術語來簡單地指代軟件客戶端的可識別請求(request)，該request請求在它自己(在主機上)和設備的端點之間以適當的方向傳輸數據。如果需要，軟件客戶端可以讓管道返回所有未完成的IRPs。當與其相關聯的總線事務已經成功完成或者由於錯誤而完成時，軟件客戶端被通知IRP已經完成。

如果管道沒有等待處理或正在處理的IRPs，則管道處於空閒狀態，主機控制器不會對管道採取任何措施；即，這種管道的端點不會看到任何指向它的總線事務。總線活動出現在管道上的唯一時間是該管道的IRPs出現的時間。

如果非同步管道遇到 導致其向主機發送STALL的條件發生(參見第8章)，或者在IRP的任何數據包上遇到三個總線錯誤，則IRP被中止/退出，所有未完成的IRPs也被退出，並且在軟件客戶端從該狀態(以依賴於實現的方式)恢復並通過USBD調用來確認暫停或錯誤條件之前，不再接受任何其他IRPs。總線將會使用適合的狀態通知客戶端軟件導致IRP暫停和錯誤的原因。(參見第10章)。第5.6節描述了同步管道行爲。

IRP可能會需要多個數據有效負載來通過總線傳輸客戶端數據。這種需要多數據負載傳輸數據的情況下，總線期望單個數據負載大小爲配置最大包大小，直到最後一個數據負載包含整個IRP的剩餘部分。有關更多詳細信息，請參見每種傳輸類型的描述。對於這樣的IRP，輸入端的短分組(即，小於最大大小的數據有效載荷)如果沒有完全填滿IRP數據緩衝器，可能是兩種可能的含義之一，這取決於客戶的期望:

• 客戶端期望一個IRP數據大小可變的。在這種情況下，沒有填滿IRP buffer的短分組可以簡單地用作帶內定界符，以指示“數據單元的結束”。收到該段分組數據時，IRP應該毫無錯誤地結束，而主機控制器應該前進到下一個IRP。
• 客戶端期望一個IRP數據大小爲固定或特定大小的。在這種情況下，沒有填滿IRP buffer的短分組指示着錯誤存在。IRP應該結束，管道應該停止使用，任何管道內未處理的IRPs也應該結束。

因爲主機控制器在這兩種情況下必須有不同的行爲，並且它自己不知道對於給定的IRP應該採取哪種行爲方式；可以根據IRP指出客戶期望的主機控制器行爲。

端點可以通過迴應NAK來通知主機它正忙。NAKs不被用作將IRP返還給軟件客戶端的結束條件。在處理給定的IRP期間，可能會遇到任何數量的NAKs。對事務的NAK響應不構成錯誤，也不被視爲上述三個錯誤之一。

5.3.2.1 流管道

流管道在總線事務的數據包部分中傳輸數據，數據內容上不需要USB規定的結構或者格式。數據從流管的一端流入，從另一端以相同的順序流出。流管在它們的通信流中總是單向的。

通過流管道傳輸的數據被期望是僅和單個用戶(USB總線所認爲的)進行交互。不要求USB系統軟件在多個用戶使用同一個流管道的情況下提供同步機制。在流管道的數據將按順序傳輸:先進先出。

一個設備使用到流管道時，流管道將會被綁定到該設備的一個合適傳輸方向的端點號(即，對應於協議層定義的輸入或輸出令牌)。相反方向的設備端點號可用於設備的其他一些流管道。

流管道支持大容量、等時和中斷傳輸類型，這將在後面的章節中解釋。

5.3.2.2信息管道

消息管道與端點的交互方式不同於流管道。首先，主機向USB設備發送請求。該請求之後是適當方向的數據傳輸。最後，一個狀態階段會在稍後的某個時間出現。爲了協調請求/數據/狀態時序，消息管道在通信流上制定了一種結構，使得命令可以被可靠地識別和傳輸。消息管道允許雙向通信流，儘管通信流可能主要是單向的。默認控制管道始終是一個消息管道。

USB系統軟件確保多個請求不會同時發送到一個消息管道。設備應該一個時間內只處理每個消息管道內的一個消息請求。主機上的多個軟件客戶端可以通過默認控制管道發出請求，但它們會以先進先出的順序發送到設備。設備可以根據其對主機事務的響應能力來控制數據和狀態階段的信息流(有關更多詳細信息，請參考第8章)。

在當前消息在設備上的處理完成之前，消息管道通常不會從主機發送下一條消息。但是，當存在錯誤的條件下，主機可以終止該消息的傳輸，此時消息管道可以提前發送新的消息傳輸(從設備的角度來看是提前的)。從操作消息管道的軟件的角度來看，IRP的某個部分出錯會使當前的IRP和所有排隊的IRP失效，此時請求IRP的軟件客戶端會被通知IRP完成，並帶有適當的錯誤提示(錯誤碼之類)。

設備的兩個方向上的消息管道各自一個設備端點號(輸入和輸出令牌)。USB不允許消息管道與不同方向的不同端點號相關聯。

消息管道支持控制傳輸類型，這將在第5.5節中解釋。

5.3.3 幀和微幀

在全速/低速總線上，USB建立了一個1毫秒的時基，稱爲幀；在高速總線上，建立了一個125微秒的時基，稱爲微幀。一個(微型)幀可以包含多個事務。每種傳輸類型定義了端點在(微)幀內允許的事務。每隔N(微)幀總線會提供同步和中斷端點傳輸的機會。第5.6節和第5.7節描述了N的值和其他有關同步和中斷傳輸的細節。

5.4 傳輸類型

USB通過管道在客戶端軟件的內存緩衝區和USB的端點之間傳輸數據。通過消息管道傳輸的數據以USB定義的結構承載，但USB允許特定設備的結構化數據在USB定義的消息數據負載內傳輸(個人認爲這裏是指特定設備自己的消息可能也會自己的結構，但是在消息管道傳輸時，仍要在自定義結構之外遵循USB定義的消息結構)。USB還定義了通過總線傳輸的數據被打包用於任何管道(流或消息)，但最終在總線事務的數據負載中傳輸的數據的格式化和解釋是使用管道的客戶端軟件和function的責任。

然而，USB提供了不同的傳輸類型，這些傳輸類型經過優化，能夠更緊密地匹配使用管道的客戶端軟件和function的服務需求。IRP使用一個或多個總線事務在軟件客戶端及其function之間傳輸信息。

每種傳輸類型決定了通信流的各種特性，包括:

• 由USB定義的傳輸需要使用的數據格式
• 通信流的方向
• 數據包大小限制
• 延遲限制
• 所需的數據序列
• 錯誤處理

USB設備的設計者爲設備的端點選擇功能。當爲端點建立管道時，大多數管道的傳輸特性被確定，並在管道的使用壽命內保持固定。針對每種傳輸類型描述了可以修改的傳輸特性。

USB定義了四種傳輸類型:

• 控制傳輸:突發的、非週期性的、主機軟件發起的請求/響應通信，通常用於命令/狀態操作。
• 等時傳輸:主機和設備之間的週期性連續通信，通常用於與時間相關的信息。這種傳輸類型還保留了封裝在數據中的時間概念。然而，這並不意味着這些數據的交付需求總是時間緊迫的。
• 中斷傳輸:低頻、有限延遲的通信。
• 批量傳輸:非週期性的大數據包突發通信，通常用於可以使用任何可用帶寬的數據傳輸，也可以延遲到帶寬可用時再進行傳輸。

以下四個主要部分詳細描述了每種傳輸類型。如第8.3.4節所述，任何IRP的數據都由數據包的數據字段攜帶。第8章還描述了受每種特定傳輸類型影響的協議細節。

5.4.1 表格計算示例

以下各節描述了每種USB傳輸類型。在這些部分中，有一些表格說明了一個(微)幀中可以包含的最大事務數量。這些表可用於確定特定傳輸類型可能的最大傳輸性能。實際性能可能因具體的系統實現細節而異。

每個表格將會顯示:

• 特定傳輸類型(和速度)所需的協議開銷
• 對於某些樣本數據的有效負載大小:
• 1.這種情況下可能的最大持續帶寬
• 2.每個事務所需的(微)幀的百分比
• 3.特定情況下(微)幀中的最大事務數
• 4.特定情況下不需要的(微)幀中的剩餘字節
• 5.特定情況下在單個(微)幀中傳輸的數據字節總數

特定傳輸類型的事務通常需要多個數據包。每個事務的協議開銷包括:

• 每個數據包的同步字段:8位(全速/低速)或32位(高速)
• 每個數據包的一個PID字節:包括PID和PID反相(校驗)位
• 每個數據包的一個EOP:3位(全速/低速)或8位(高速)
• 在令牌包中，端點號、設備地址和CRC5字段(總共16位)
• 在數據包中，CRC16字段(總共16位)
• 數據包中的任何數據字段(每字節8位)
• 對於有多個包的事務，需要包間間隙或總線週轉時間。

對於這些計算，假設不需要位填充。

以低速中斷輸出爲例，事務中有5個數據包:

• 一個 PRE 特殊包
• 一個令牌包
• 一個 PRE 特殊包
• 一個數據包
• 一個握手包

數據和握手包之間有一個總線週轉。因此，協議開銷爲：

5個SYNC、5個PID、端點+ CRC5、CRC16、5個EOPs和分組間延遲(一個總線週轉、一個分組間延遲和兩個hub的建立時間)。

 

5.5 控制傳輸

控制傳輸允許訪問設備的不同部分。控制傳輸一般用來支持客戶端軟件和它對應的function之間的配置/命令/狀態類型的通信流傳輸。控制傳輸由從host到function傳輸request信息的總線建立(SETUP)事務、以SETUP事務指定的方向發送數據的0個或者多個數據事務以及從function返回給host的狀態事務組成。當端點成功完成請求的操作時，狀態事務返回“成功”。第8.5.3節描述了使用什麼包、總線事務和事務序列來完成控制傳輸的細節。第9章描述了定義的USB命令代碼的細節。

每個通USB設備都需要將默認控制管道實現爲消息管道，且該管道由USB系統軟件使用。默認控制管道提供對USB設備的配置、狀態和控制信息的訪問。一個function可以爲它自己的實現需求提供額外控制管道的端點，但不是必須。

USB設備框架(參見第9章)定義了可用於操縱設備狀態的標準、設備類別或供應商特定的請求。還定義了能包含設備上的不同信息的描述符。控制傳輸提供了訪問設備描述符和請求設備操縱其行爲的傳輸機制。

控制傳輸僅通過消息管道進行。因此，使用控制傳輸的數據流必須符合第5.5.1節所述的USB數據結構定義。

USB系統將盡最大努力支持主機和設備之間的控制傳輸。一個function及其客戶端軟件不能爲控制傳輸請求特定的總線訪問頻率或帶寬。USB系統軟件可能會限制設備控制傳輸所需的總線訪問和帶寬。這些限制在第5.5.3節和第5.5.4節中定義。

5.5.1 控制傳輸數據格式

建立（SETUP）包具有由USB定義的結構，該結構可容納主機和設備之間進行通信所需的最少命令集。結構定義允許廠家拓展用於特定設備的命令。SETUP事務之後的數據擁有USB定義的結構，除了攜帶供應商自定義的信息。狀態事務也有USB定義的結構。第8.5.3節和第9章描述了具體的控制傳輸設置/數據定義。

5.5.2 控制傳輸方向

USB通過信號管道上的雙向通信流來支持控制傳輸。因此，當配置控制管道時，它使用具有指定端點號的輸入和輸出端點。

5.5.3 控制傳輸包大小限制

用於控制傳輸的端點指定了端點能夠接收或者發送的最大數據負載大小。全速設備允許的最大控制傳輸負載大小爲8、16、32或者64字節；對於高速設備，它是64字節，對於低速設備，它是8字節。該最大值適用於SETUP後數據包的數據有效負載；即，指定的大小用於第8章中定義的數據包的數據字段，不包括協議要求的其他信息。SETUP數據包總是八個字節。控制管道(包括默認控制管道)總是將它的wMaxPacketSize值用於數據有效負載。

端點在其配置信息中報告其最大數據負載大小的值。USB不要求傳輸的數據有效負載正好是最大尺寸；即，如果數據負載小於最大值，則不需要填充到最大值。

要求所有主機控制器支持全速控制端點的8、16、32和64字節最大數據負載大小，低速控制端點的最大數據有效負載大小僅爲8字節，高速控制端點的最大數據有效負載大小僅爲64字節。不需要主機控制器來支持更大或更小的最大數據負載大小。

爲了確定默認控制管道的最大數據包大小，USB軟件讀取設備描述符。主機將讀取設備描述符的前八個字節。設備總是在單個數據包中至少用這些初始字節進行響應。在主機讀取設備描述符的初始部分之後，它保證已經讀取了這個默認管道的wMaxPacketSize字段(設備描述符的第7字節處)。然後，它將爲所有後續事務提供正確的大小。對於所有其他控制端點，最大數據有效負載大小在配置後是已知的，因此，USB系統軟件可以確保不會向大於支持大小的端點發送任何數據有效負載。

端點必須始終保證傳輸的包中數據字段長度小於或等於端點的wMaxPacketSize的最大數據有效負載(參見第9章)。當控制傳輸涉及的數據超過當前確定的最大大小的一個數據有效負載所能容納的數據時，除了最後一個數據有效負載之外，所有數據有效負載都需要達到最大大小，最後一個數據有效負載將包含剩餘數據。

當端點執行下列操作之一時，從端點到主機的控制傳輸的數據階段完成:

• 已經準確傳輸了SETUP階段指定的數據量
• 傳輸有效負載大小小於wMaxPacketSize的數據包或傳輸零長度數據包

當數據階段完成時，主機控制器進入狀態階段，而不是繼續另一個數據事務。當數據階段完成時，如果主機控制器沒有進入狀態階段，端點將按照第5.3.2節所述停止管道。如果從端點接收到大於預期的數據有效負載，控制傳輸的IRP將被中止/取消。

當所有數據都已傳輸完畢時，從主機到端點的控制傳輸的數據階段就完成了。如果端點從主機接收到大於預期的數據負載，它會停止管道。

5.5.4 控制傳輸總線訪問限制

高速、全速和低速的通用串行總線設備都可以使用控制傳輸。

端點無法指示控制管道所需的總線訪問頻率。USB平衡了所有控制管道的總線訪問要求和等待處理的特定IRP，以在客戶端軟件和功能之間提供“最大限度”的數據傳輸。

USB要求保留每個(微)幀的一部分，以供控制傳輸使用，如下所示:

• 如果一次控制傳輸(以依賴於實現的方式)對於全速/低速端點消耗少於10%的幀時間，或者對於高速端點消耗少於20%的微幀時間，剩餘時間可用於支持批量傳輸(參見第5.8節)。
• 需要重試的控制傳輸可以在當前或未來(微)幀中重試；即不需要在同一(微)幀中重試。
• 如果控制傳輸多於保留時間，但有沒有用於同步或中斷傳輸的額外(微)幀時間，主機控制器可以在有額外控制傳輸可用時傳輸它們。
• 如果在可用的(微)幀時間內有太多等待處理的控制傳輸，控制傳輸將被選擇爲在總線上適當地傳輸。
• 如果有多個端點的控制傳輸等待處理，則根據主機控制器的的公平訪問策略來選擇不同端點的控制傳輸，這取決於主機控制器實現。
• 經常重試的控制傳輸事務不應消耗過多的總線時間份額。

高速控制端點必須爲輸出事務支持PING流控制協議。第8.5.1節描述了該協議的細節。

這些要求允許主機和設備之間的控制傳輸通過總線“盡最大努力”規律地進行。

USB系統軟件可以自行決定改變特定端點的控制傳輸速率。端點及其客戶端軟件不能爲控制傳輸假定特定的服務速率。一個控制端點可能在單個(微)幀中看到零個或多個傳輸。當其他設備插入系統或從系統中移除時，或者當其他設備端點請求控制傳輸時，可以改變軟件客戶端及其端點可用的總線時間。

總線頻率和(微)幀時序限制了任何USB系統在(微)幀內成功控制傳輸的最大數量。對於全速/低速總線，每幀成功控制傳輸的數量被限制爲少於29個全速八字節數據有效負載或少於四個低速八字節數據有效負載。對於高速總線，控制傳輸的數量限制爲每微幀少於32個高速64字節數據有效載荷。

表5-1列出了不同大小的低速數據包以及一幀中可能的最大數據包數量。該表不包括與位填充相關的開銷。

 對於所有速度(低速、全速、高速)，因爲控制傳輸由多個包組成，所以包可以分佈在幾個(微)幀上，以將所需的總線時間分佈在幾個(微)幀上。

全/低速非週期傳輸的10%幀預留意味着，在總線時間完全分配的系統中，系統中的所有全速控制傳輸搶佔式使用每幀三次的控制傳輸。因爲除了其他客戶端軟件可能請求的任何其他控制傳輸之外，USB系統還將控制傳輸用於配置目的，所以給定的軟件客戶端及其功能不應該期望能夠將該全部帶寬用於其自己的控制目的。主機控制器還可以自由決定特定控制傳輸的單個總線事務如何在幀內和幀間通過總線傳輸。一個端點可以看到同一幀內或跨幾個不連續幀的控制轉移的所有總線事務。出於各種實施原因，主機控制器可能無法提供每幀控制傳輸的理論最大數量。

對於高速端點，非週期性傳輸的20%微幀預留意味着，所有高速控制傳輸搶佔式使用每個微幀6次的控制傳輸。對於全速和低速控制傳輸，高速控制傳輸與分割事務一起爭奪微幀時間(有關分割事務的更多信息，請參見第11.15-11.21節)。全速和低速控制傳輸爭用相同的可用幀時間。但是，某些端點的高速控制傳輸可以與其他端點的全速和低速控制傳輸同時發生。低速控制傳輸需要更長的傳輸時間。

表5-2列出了不同大小的全速控制傳輸信息以及一幀中可能的最大傳輸次數。此表是在假設有一個數據階段事務並且數據階段具有零長度狀態階段的情況下生成的。該表說明了小於或等於允許的最大數據有效負載大小的兩個數據有效負載的可能功率。該表不包括與位填充相關的開銷。

 表5-3列出了不同大小的高速控制傳輸以及微幀中可能的最大傳輸次數。此表是在假設有一個數據階段事務並且數據階段具有零長度狀態階段的情況下生成的。該表說明了小於或等於允許的最大數據有效負載大小的兩個數據有效負載的可能功率。該表不包括與位填充相關的開銷。

5.5.5 控制傳輸數據序列

控制傳輸要求從主機向設備發送SETUP總線事務，以描述設備應該執行的控制訪問類型。設置事務之後是零個或多個控制數據事務，這些事務攜帶請求訪問的特定信息。最後，狀態事務完成控制轉移，並允許端點將控制轉移的狀態返回給客戶端軟件。控制轉移的狀態事務完成後，主機可以前進到該端點的下一個控制轉移。如第5.5.4節所述，每個控制事務和下一個控制傳輸將會通過總線以一定的時間進行傳輸，這個時間根據主機控制器的實現定義。

在控制傳輸的數據和狀態事務期間，端點可能會在設備特定的時間內繁忙。在這些時間內，當端點指示它正忙時(有關詳細信息，請參考第8章和第9章)，主機將在稍後重試該事務。

如果在先前發起的控制傳輸完成之前，端點接收到SETUP事務，則設備必須中止當前傳輸/操作，並處理新的控制SETUP事務。在完成前一次控制傳輸之前，通常不應發送SETUP事務。但是，如果傳輸因總線錯誤而中止，主機可以提前(從端點的角度)發送下一個SETUP事務。

在遇到暫停條件或主機檢測到錯誤後，允許控制端點通過接受下一個設置PID來恢復；即，控制端點不需要通過一些其他管道的恢復動作。對於默認控制管道，如果不接受下一個SETUP PID，最終將需要設備復位來清除暫停或錯誤情況。

USB爲控制傳輸過程中出現的錯誤提供強大的錯誤檢測和恢復/重傳功能。發射機和接收機可以在控制傳輸中保持同步，並且可以很容易地恢復同步。數據和狀態包的重傳可以由接收器通過包中的數據重試指示符來檢測。發射機可以通過握手中返回的信息來可靠地確定其對應的接收機已經成功地接受了發送的包。該協議允許將重傳的包與其原始包區別開來，除了控制SETUP包。由於傳輸錯誤，SETUP數據包可能會被重新傳輸；但是，SETUP數據包不能指示數據包是原始傳輸還是重試傳輸。