Zynq7000 USB2.0协议解析及USB控制器详解
USB 2.0規范及控制器
文章目錄
- USB 2.0規范及控制器
- USB2.0
- Univerasl Serial Bus
- USB
- Host
- USB總線
- 接口標準
- 總線信號
- USB拓撲結構
- 數據流模型
- 數據編解碼和位填充
- USB邏輯部件
- USB時間基準
- USB 描述符
- USB設備
- USB設備供電方式
- USB設備分層
- USB設備插入檢測機制
- USB設備狀態
- USB總線枚舉
- USB傳輸
- 傳輸類型
- 包(Packet)
- 事務(transaction)
- 傳輸(transfer)
- 傳輸種類
- 傳輸機制
- Zynq USB Device
- Hardware System
- 系統接口
- 控制器結構
- Configuration, Control, Status
- Data Structures
- Functional Description
- DMA引擎
- 協議引擎
- 通用定時器
- Programming And Reference
- 操作模式控制
- Device Mode Control
- 控制器狀態
- USB總線復位響應
- Device Endpoint Data Structures
- Link-List Endpoint Descriptors
- Manage Endpoints
- Endpoint初始化
- Device Endpoint Packet Operational Model
- Prime Transmit Endpoints
- Prime Receive Endpoints
- 中斷及批量端點操作模型
- 中斷及批量端點總線響應
- Device Endpoint Packet Descriptor Reference
- Endpoint Queue Head Descriptos (dQH)
- Endpoint Transfer Descriptor(dTD)
- Endpoint Transfer Overlay Area(參考figure15-14)
- Device Controller 編程模型
- 設備控制器初始化
- 管理傳輸描述符
- 利用傳輸描述符管理傳輸
- 建立一個傳輸描述符(dTD)
- DCD執行一個dTD
- 傳輸完成
- 傳輸完成
本文為ug585及usb2.0的個人學習及理解過程,后續將給出USB Device 源碼分析;
文章一部分圖片因github圖床加載的原因未展示感興趣可直接通過github查看;
? OTG及Host模式在裸機模式下不支持,結論來自Xilinx官網USB開源工程;
USB2.0
Univerasl Serial Bus
USB
USB1.0-> 1.5Mb/s Low-Speed 12Mb/s Full-Speed
USB2.0-> 480Mb/s High-Speed
特點 : 輪詢總線,由Host發起所有的數據傳輸
魯棒性 :
- 差分驅動,接收器保證信號完成
- 控制和數據傳輸過程中CRC校驗
- 設備插拔檢測
- 超時機制檢測丟失或損壞的包,傳輸失敗最多進行3次重傳
- 流式數據的流量控制,保證同步和硬件緩沖管理
Host
USB系統只有一個主機,Host 通過Host controller與Device交互; 檢測USB設備插拔;
管理Host和Device之間的控制流,數據流; 收集USB總線狀態和活動數據信息; 為連接USB總線的設備供電;
USB總線
接口標準
A型 B型 Mini型
總線信號
-
差分傳輸模式
? 兩根數據線D+ D- : 差分信號1 : D+ > 2.8V,D- < 0.3V ; 差分信號0 : D- > 2.8V,D+ < 0.3V;
-
J狀態 K狀態
低速 D+為’0’ D-為’1’ 為J狀態, K狀態相反
全速 同高速
高速 D+為’1’ D-為’0’ 為J狀態, K狀態相反 -
SE0狀態
D+為’0’ D-為’0’ -
IDEL狀態
低速 空閑狀態為’K’狀態
全速 空閑狀態為’J’狀態
高速 空閑狀態為SE0狀態 -
針對全速模式
-
reset信號
? 主機和設備通信前會發送reset信號來把設備配置到默認的未配置狀態.
? SE0狀態保持10ms
-
resume信號
? 20ms的K狀態 + 低速EOP
? suspend信號
? 3ms以上的J狀態 -
SOP信號
從IDLE狀態切換到K狀態 -
EOP信號
持續2位時間的SE0信號,后跟隨1位時間的J狀態 -
SYNC信號
3個重復的K ,J狀態切換, 后跟隨2位時間的K狀態
-
USB拓撲結構
-
主從結構
主機 : Host
? 從機 : Device 分為USB Function和USB HUB -
星型拓撲結構
以HOST為頂層,以HUB為中心,HUB串聯級數最多5層
數據流模型
-
數據節點
- USB Physical Device: 具有一定功能的USB設備硬件
- Client Software : 在Host上運行與USB Device通訊的軟件,一般與具體的USB設備配套
- USB System Software : USB系統軟件,一般與操作系統配套 與具體的USB設備和Client Software無關
- USB Host Controller：包括軟硬件,允許USB設備連接到Host
-
層級
- USB bus Interface提供物理,信號,包的連接
- USB Device層負責USB系統軟件與設備交互
- 功能層為USB設備與Host交互匹配合適的Client Software
數據編解碼和位填充
- NRZI(非歸零編碼) : 輸入數據0編碼成"電平翻轉"; 輸入數據1,編碼成"電平不變"
- 位填充
- 目的是為保證發送的數據序列有足夠的電平變化
- 填充的對象為輸入數據 即先填充后編碼
- 填充方式為數據流中每6個連續的’1’插入一個’0’
USB邏輯部件
特征
- USB設備是端點的集合, 分組端點構成一個接口
- USB系統通過默認控制管道來管理設備
- Client Software使用管道來管理接口
- 通過Host的buffer和USB設備的端點來請求數據
- Host Controller 打包數據并將數據發送出去
端點
- Endpoint是USB設備上可被獨立識別的端口,Host與Device通訊流的邏輯終點
- USB設備的最小收發單元,一系列相互獨立的端點構成USB邏輯設備
- 設備上的每個端點會在接入總線時被分配唯一端點號,并決定其傳輸方向
- Host 通過"設備地址 + 端點號 + 數據傳輸方向"對其進行唯一尋址
- 分類
- 0端點 : 控制端點,一個設備只有一個,對設備進行枚舉和基本控制功能, 數據雙向傳輸
- 非0端點 : LS最多支持2個, HS/FS最多支持15組, 單向通訊,且在設備被成功配置之后, 只有向主機報告端點特性之后才能被成功激活
管道
-
Host Softwarw的buffer與設備 Endpoint之間的數據搬運模型;
-
同端點配套,意味著其存在一個Host對Device的默認控制管道, 在上電和總線復位時有效, 用于Device鑒別和配置;
-
分類
-
流管道
數據傳輸無USB定義結構, first in first out, 通信流總是單向的;
-
信息管道
主機向USB設備發送請求,隨后進行數據傳輸,最后進行傳輸狀態確認, 數據中加入USB定義格式以用來區別請求/數據/狀態,允許雙向數據流;
-
同一管道支持一種類型的數據傳輸,所以需要多個管道完成數據交換,根據傳輸類型定義可包含的事務類型;
USB時間基準
- 幀 LS\FS上建立的1ms時間基準 微幀 HS模式下建立的125us時間基準; 這個時間由控制器內部定時器產生;
- 一個時間基準可包含多組事務
根據傳輸類型定義可包含的事務類型
每N個時基為總線提供同步和中斷端點的窗口(針對中斷傳輸和同步傳輸)
N值取值參考具體傳輸方式
USB 描述符
Device(具體參見USB2.0 Table 9-8)
- 描述有關USB設備的常規信息(一個USB設備具有唯一此描述符)
- 包含全局適用于設備和所有設備配置的信息
- 具有全速和高速不同設備信息的高速設備也必須具有 設備限定 描述符
- 所有USB設備具有一個默認控制管道, 設備描述符描述設備默認控制管道的最大數據包大小
Device_Qualifier
- 描述有關高速設備的信息
- 此描述符會返回與當前運行速率相反狀態的信息,eg:以全速運行會返回如何以高速運行的信息
Configuration
- 描述關于特定設備配置的信息
- 描述符包含一個bConfiguration Value字段,此字段的值用于做SetConfiguration請求的參數時會使設備采用所描述的配置
Other_Speed_Configuration
描述高速設備的配置
如果以其他速率運行,其結構與配置描述符相同
Interface
- 描述配置中的特定接口 ,接口描述符總是作為配置描述符的一部分返回
- 一個配置提供一個或多個接口,每個接口具有零或多個端點描述符,用于描述配置中的一組唯一端點
- 當配置支持多個接口特定接口的端點將遵循GetConfig( )請求返回的數據中的接口描述符
- 接口描述符不能通過GetDescriptor( ) \ SetDescriptor( )直接返回
Endpoint
- 描述端點 接口的每個端點都有各自的描述符
- 包含主機為確認每個端點的帶寬需求所需要的信息
- 一個端點描述符總是作為配置描述符的一部分返回
- 端點描述符不能通過GetDescriptor() 或 SetDescriptor( )請求直接訪問
- 端點0 不存在端點描述符
String
- 描述字符串 可選
- 如設備不支持字符串描述符, 則必須將設備,配置,接口描述符中對字符串描述符的所有引用重置為0,否則會導致host枚舉失敗
USB設備
USB設備供電方式
- 自供電設備 設備從外部電源獲取電壓
- 總線供電 設備從VBUS(5V)取電
- 低功耗設備
最大功耗不超過100mA - 高功耗設備
枚舉時最大功耗不超過100mA
枚舉配置結束后功耗不超過500mA
- 低功耗設備
USB設備分層
- 底層
傳輸和接收數據包的總線接口 - 中間層
處理總線接口和設備上各個端點之間的路由數據
端點是數據的最終消費者和提供者 - 頂層
串行總線設備提供的功能,eg 鼠標等
USB設備插入檢測機制
沒有設備連接主機時主機的D+ D-為’0’總線處于SE0狀態,此狀態持續一段時間,主機認為斷開;
設備連接主機時,主機檢測到相應數據線拉高,認為設備連接,此時主機必須在復位設備前采樣數據線判斷設備速度;
-
全速/高速 D+上拉
-
低速 D-上拉
USB設備狀態
-
連接狀態
設備接入總線系統中狀態依據規范 -
上電狀態
設備通過配置描述符報告其電源功能
根據設備供電選項上游端口進行對應供電策略 -
默認狀態
上電后不進行任何響應,直至復位信號到來
接到復位信號后,使用默認地址對設備進行尋址
此狀態完成后設備在正確的速度下進行操作 -
地址狀態
所有USB設備在加電復位后都使用缺省地址
每一個設備在連接或復位后由主機分配一個唯一的地址
USB設備處于掛起后保持此地址不變
USB設備支隊默認通道(pipe)請求發生響應,而不管設備是否已經分配地址或者使用默認地址 -
配置狀態
USB設備正常使用前,必須正常配置 -
設備角度
使用一個非零配置值正確處理SetConfiguration()請求
配置一個器件或者改變一個可變的設備設置會使與這個相關接口的端點的所有狀態與配置值被設為缺省值;包括正在使用的data toggle的end point data taggle被設置為DATA0
-
掛起狀態
USB設備在探測不到總線傳輸時自動進入掛起狀態,
USB保持本身的內部狀態,包括地址及配置
USB總線枚舉
USB設備連接到主機或拔出時,主機通過枚舉過程來管理與識別,總線枚舉過程經歷如下幾個步驟
供電 -> 復位 -> 獲取DeviceDescriptor前8個字節 -> 復位 -> 分配地址 -> 獲取Device Descriptor -> 獲取String Descriptor -> 配置
檢測電壓變化,報告給主機
HUB檢測到有電壓變化,利用自己的中斷將信息反饋給主機
主機探尋設備詳細信息
主機通過查詢HUB確認此次變化的詳細種類
發送Get_Port_Status()請求給hub
Hub檢測所插入的設備是高速還是低速
hub通過檢測USB總線空閑(IDLE)時的差分線電平來判斷所連接設備的速度類型
接收Get_Port_Status()請求后回復速度類型
此操作必須先于復位操作
hub復位設備
主機得知新設備連接,至少等待100ms以等待插入操作及設備電源穩定
之后向hub發送Set_Port_Feature()請求 讓hub復位其管理的端口
hub驅動 D+D-為0以復位設備
Host檢測所連接的全速設備是否支持高速模式
高速設備在初始時默認全速狀態
是否支持取決于設備的上拉電阻切換及總線電流(參考中文網)
HUb建立設備與主機之間的信息通道
主機不斷發送Get_Port_Status請求來查詢是否復位成功
主機發送Get_Descriptor請求,獲取設備描述符
默認管道(Default Pipe)在設備一端視為端點0,此時發送的請求是默認地址0,端點0
設備描述符的第8字節代表設備端點0 的最大包大小
當完成第一次控制傳輸后,系統會要求hub對設備及性能再次復位,以使設備進入一個確認狀態
主機給設備分配地址
主機控制器通過Set_Address請求向設備分配一個為唯一地址, 設備進入地址狀態,之后啟動新地址
主機獲取設備的信息
主機再次發送Get_Descriptor請求到新地址讀取設備描述度
主機給設備掛載驅動
主機通過解析描述符獲取信息,之后選擇一個合適的驅動給設備
之后調用設備模型提供的device_add將設備添加到USB總線的設備列表
設備驅動選擇一個配置
驅動根據前面設備回復的信息,發送Set_configuration()請求來正式確定設備的工作配置
設備處理處于配置狀態(Configured),設備使能其各個接口
供電;
USB傳輸
總線傳輸數據以包(Packet)為基本單位, 上層稱為事務(transaction) 由不同的包組成, 之后組成一次transfer
傳輸類型
域組包->包組事務->事務組傳輸
- 批量傳輸 同步傳輸 中斷傳輸 控制傳輸 一次transfer為一次transation
- 控制傳輸分為如下過程 :
- 建立過程 一個transation
- 狀態過程 一個transation
- 數據過程 一個或多個transation
包(Packet)
一個包分為不同的域,不同類型的包含義不同;
但都以同步域SYNC開始,緊跟標識符PID,并以EOP結束符結束
SOP包起始位同步域的一部分
EOP界定符和SYNC等都是通過電氣特性描述,扎包工具并能抓到
-
PID域(8bit)
- 標識一個包的類型 8bit
前四位為PID0~3
后四位為前四位取反用于校驗PID - 種類
令牌包
分為: OUT->0001; IN->1001;SOF(start_of_frame)-> 0101; SETUP->1101
數據包
分為: data0->0011; data1->1011;data2->0111;mdata->1111
握手包
分為: ACK->0010; NAK->1010; STALL->1110; NYET->0110
特殊包
分為: PRE->1100; ERR->1100(復用PRE); SPLIT->1000; PING->0100; 保留->0000
具體參考table8-1 - 僅在幀首傳輸一次SOF包
- 標識一個包的類型 8bit
-
地址域(11bit)
- 設備地址域(低7位)
默認為0,必須在設備枚舉階段被定義 - 端點地址域(高4位)
LS設備最多3個端點
FS / HS最多16個端點
- 設備地址域(低7位)
-
端點域(4bit)
- 定義在IN SETUP OUT令牌包及PING包中
- 指示由Device端點
低速最大支持3個端點 一個控制端點兩個默認
FS/LS 支持16個種類同上
-
幀號域(11bit)
- 主機每發出一個幀,幀號自動加1,直至0x7FF歸零
-
數據域(n bytes)
控制傳輸
HS:64 FS:64 LS:8
批量傳輸
HS:512 FS:64 LS:N/A
中斷傳輸
HS:1024 FS:64 LS:8
同步傳輸
HS:1024 FS:1023 LS:N/A -
CRC域
token CRC
G(X) = X^5+ X^2 + 1
data CRC
G(X) = X^16+ X^15+ X^2 + 1 -
包類型
-
令牌包
OUT
通知設備將要輸出一個數據包
IN
通知設備返回一個數據包
SETUP
只用在控制傳輸中,通知設備將要輸出一個數據包
與OUT區別在于只是用DATA0數據包,
且只能發送Device的控制端點 -
SOF
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-B6mM3gV3-1649168263498)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/5_sof.png)]
在每幀開始時以廣播的形式發送,USB主機會對當前幀號進行統計,每次幀開始前通過SOF包發送幀號;
主機以全速總線每 1.00ms±0.0005ms 和高速總線 125us±0.0625us 的標稱速率發出
-
數據包
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-kst98ezy-1649168263499)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/6_data.png)]
-
握手包
handshakedescribe NAK 設備暫時沒有好接受數據或發送數據 STALL 設備不能用于傳輸 YET/ERR 僅用于高速傳輸,設備沒有準備好或出錯 CK 傳輸正確完成
-
-
事務(transaction)
- 組成
Token packet +data packet + 可選的(handshake packet) - 分類
| setup事務 | 主機用來設備發送控制命 |
| 數據輸入事務(IN) | 主機用來從設備讀取數據 |
| 數據輸出事務(OUT) | 主機用來向設備發送數據 |
傳輸(transfer)
傳輸種類
-
控制傳輸
特點:
突發, 非周期性; 主機軟件發起的"請求/響應"通信, 通常用于"命令/狀態"操作 -
同步傳輸
特點:
主機與設備之間的定期, 連續通信, 通常用于對時間敏感的數據; 此傳輸類型保留了封裝在數據中的時間概念 -
中斷傳輸
特點:
低頻,有限延遲通信 數據量小不連續,但實時性要求很高的傳輸
約束:-
中斷管道
? 流式管道->單向數據傳輸, 端點描述符給定中斷管道的通信流的方向
-
傳輸包約束
中斷管道端點,指定它將發送或接收的最大數據有效載荷 LS: 8bytes FS:64bytes HS:1024Bytes? USB系統軟件確定配置期間用于中斷管道的最大數據有效負載大小 此大小在設備配置的整個生命周期保持不變
? USB系統軟件確認最大負載數據后確認總線時間,在保證總線時間能夠容納最大數據負載后建立管道
? 端點傳輸數據時必須始終保持數據量不超過wMaxPacketSize 值,Device可以通過大于wMaxPacketSize的中斷管道傳輸數據
? Client SW可以通過IRP(See I/O Requset Packet)來接收數據,當數據拆包為多個事務時,Client SW設置緩沖實現
傳輸數據包完成標志
已準確傳輸預期的數據量
數據有效負載大小小于最大負載,或數據包長度為0中斷傳輸完成后主機控制器退出當前IRP,進入下一IRP
如實際傳輸負載大于預期,此中斷IRP將"aborted/retired",并且管道將停止接收IRP高速默認接口傳輸最大負載不能超過64Bytes
總線接口約束
- 高速 傳輸不能超過80%微幀時間 最大帶寬53.248MB/s->對應512Byte最大裝載值;
- 全速/低速 傳輸不能超過90%微幀時間 最大帶寬1.216MB/s ,48KB/s->對應64Byte/8Byte最大裝載值;
- 總線訪問訪問周期 高速 -> 2^(1~16)*125us ;全速 -> 1ms~255ms; 低速 -> 10ms~255ms;
- 總線錯誤會阻斷傳輸;
- Client SW由一個IRP用于掛起的中斷傳輸時才會輪詢端點;
- 如執行中斷傳輸的總線時間到IRP沒有掛起,那么端點將不能傳輸, 等待IRP可用;
- client 和Device依賴于host確保與端點兩次事務嘗試之間的持續時間不長于事實時間;
-
-
批量傳輸
特點
非周期性,大數據包突發通信 ; 通常用于可以使用任何可用帶寬的數據
數據量大但對時間要求不高的傳輸
傳輸機制
? 采用 "令牌包 + 數據包 + 握手包"的傳輸形式 令牌包指定數據去向或者來源的設備地址和端點 握手包表示數據傳輸結果
-
中斷傳輸
IN事務(Host->Device) -> Data(Device->Host) -> ACK(Host->Device)
OUT事務(Host->Device) -> Data(Host->Device) -> ACK(Device->Host) -
同步傳輸
IN事務(Host->Device) -> Data(Device->Host)
OUT事務(Host->Device) -> Data(Host->Device)
Zynq USB Device
Hardware System
兩路控制器信號獨立;
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Yi61nbUJ-1649168263503)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/9_block.png)]
系統接口
每個控制控制器DMA傳輸通過AHB總線連接到PS片內互聯;
控制及狀態寄存器由APB映射到系統內存空間進行系統編址;
兩個USB控制器有獨立的復位信號及輸出到GIC的中斷信號;
控制器結構
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-u3U2oB9S-1649168263504)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/10_contr.png)]
DMA, Protocol Engines, Context and FIFOs
DMA引擎與協議引擎一起處理endpoints,periodic elements,queue heads,等其他傳輸描述符;
軟件將數據結構寫入系統內存,DMA引擎獲取這些數據結構并將其復制到控制器的本地雙端口RAM;
控制器在處理數據結構時讀取和寫入DPRAM中的數據結構;
當傳輸完成時,描述符通過DMA引擎返回內存;
除數據結構的上下文信息,控制器同時使同DPRAM來實現TX RX 的FIFO;
這些FIFO為系統內存和USB實時傳輸提供緩沖;
FIFO的使用方式跟隨模式變動, 主機模式下通過DPRAM在每個方向上保持單個數據信道;
設備模式下,針對每個活動設備端點維護RX和TX數據FIFO通道,并且FIFO通道可以異步和實時操作;
Port Transceiver Controller
端口收發器提供 暫停/恢復,并且用于設備模式,chirp 控制功能(兩次上電reset后的chrip K信號);
端口控制器控制8位的數據總線傳遞到8位的ULPI;
USB控制器的整個后端與PHY的60 MHz USB時鐘同步工作;
ULPI(USB Low Pin Interface) Link Wrapper
協議引擎包括一個類似與UTMI+的內部總線;
ULPI wrapper 在此總線和ULPI接口之間提供一座橋梁,對用戶透明;
ULPI Wrapper傳遞數據包并解釋RX命令以及發送 TX命令;
ULPI Rx/Tx Commands
Rx命令由PHY啟動以設置狀態位,從而時軟件能夠查看PHY事件,這些指令設置控制器狀態位;
Tx命令由軟件通過寄存器寫入來啟動,以控制PHY功能,這些指令由ULPI規范定義;
Programmable Timers
兩個控制器有獨立的通用定時器用于生成超時或測量時間活動;
控制器用定時器生成幀(微幀)間隔并為Host控制器調度程序生成選通信號;
Software Programming Interface
除系統內存中維護數據和緩沖區結構,軟件還讀取和寫入控制和狀態寄存器;
控制器可以生成由DMA和協議引擎活動,PHY和其他控制器功能引起的中斷;
Control and Status Registers
控制和狀態寄存器包括常量,配置和 操作/狀態(ECHI Host模式)兼容性以及非ECHI功能(Device,OTG);
Clock and reset
ULPI接口和協議引擎工作在通過ULPI接口輸入的60MHz下;
AHB總線工作在CPU_1x;
CPU_1x和60MHz的跨時鐘域通過DPRAM實現;
控制器復位: PS 復位系統(全控制器復位), usb.USBCMD[RST] bit位(部分控制器復位用于OTG);
ULRL PHY 復位: GPIO輸出控制信號;
USB Bus 復位:OTG模式下的自動復位 , USB復位控制傳輸;
Configuration, Control, Status
軟件管理控制器自身的配置和控制 以及 用于USB事務的一組一致的數據結構和內存緩沖區;
兩種數據結構模型: data 和 host;
三種控制模式: Host, Device, OTG, OTG使用主機或器件模式;
Data Structures
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-etXoee8R-1649168263505)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/11_endpoint.png)]
響應Host請求,DCD(Device Controller Driver)設置一個端點描述符并管理端點的實時需求;
內存和ULPI之間的高速數據傳輸由控制器使用Queue Head和傳輸描述符進行管理;
每次傳輸的結果都由DCD進行確認并執行相應的操作;
Host Mode
Device Controller包括一個簡單描述符模型用來快速響應主機請求;
12個端點每一個都有2個 device Queue Heads(dQH),一個用于IN事務,一個用于OUT事務,共有24個設備dQH;
使用一個dQH和≥1個的設備傳輸描述符(dTD)來定義一次數據傳輸;
Link-List Concept
Host和 Device控制器使用鏈表描述符來管理內存buf的雙向傳輸流;
首TD(Transfer Descriptors)指向Queue Head,具體結構如下:
Functional Description
DMA引擎
數據傳輸
主機模式下,數據結構由EHCI規范定義, 表示由主機控制器執行的而周期行異步傳輸隊列,包括允許控制器將數據包發送到FS/LS設備,該設備位于外部的Hs Hub或根Hub的下游;
主機模式使用隊列頭 (QH), 隊列元素傳輸描述符 (QTD), 等時傳輸描述符(ITD), 分割事務等時傳輸描述符 (SITD)和周期幀跨越橫向節點(FSTN)數據結構;
器件模式,數據結構較為簡單,由鏈表形式的設備隊列頭(dQH)和設備傳輸描述符(dTD)組成;
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-XDrYUHYN-1649168263509)(14_dma.png)]
協議引擎
協議引擎解析令牌包,生成相應包響應,以及執行錯誤檢測功能;
引擎執行所有的錯誤檢查, 檢查字段生成,格式化總線上的所有的握手,ping,數據響應包,并根據基于USB規范的時間范圍生成所需的信號;
協議引擎功能
-
令牌狀態機跟蹤總線上的所有令牌并根據令牌上的地址和端點信息進行過濾;
-
CRC5/CRC16 生成器/校驗器電路檢查并生成令牌和數據包的CRC域;
-
數據和握手狀態機生成USB所需的任何響應,并將數據包數據通過DPRAM傳送到DMA控制器;
-
間隔定時器提供識別重要總線定時事件的定時選通: 總線超時間隔,微幀間隔,幀開始間隔,總線復位,恢復和暫停間隔;
-
向DMA引擎報告所有傳輸狀態;
通用定時器
此定時器要與控制器間隔定時器區分,此定時器為兩個可編程的獨立定時器,用于生成超時或測量與時間相關的活動;
該定時器受控于其自身的控制及裝載寄存器: usb.GPTIMERxCTRL and usb.GPTIMERxLD ;
控制寄存器包含定時器配置及一個數據字段,可以查詢運行計數值,粒度1us;
Programming And Reference
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-G0LmDjLm-1649168263511)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/14_stack.png)]
操作模式控制
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-JLQwDDvW-1649168263513)(15_mode.png)]
Device Mode Control
控制器處于控制模式時, 軟件啟動其控制端點, 根據設備的功能準備描述符并準備必要的端點;
控制器狀態
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-q6JLoJJe-1649168263514)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/16_state.png)]
軟件負責維護狀態變量以區分默認 FS/HS狀態和地址/配置狀態;
根據USB2.0協議,根據設備枚舉過程中的配置更改相應地址及配置狀態;
進入地址狀態后,設備地址寄存器由DCD(Device Controller Dirver)操作;
進入配置狀態后操作端點控制寄存器并初始化關聯的隊列達到配置所有需使用的端點的目的;
USB總線復位響應
Host下發初始化指令復位總線;
當檢測到總線復位時,設備控制器硬件重新協商連接速度(LS\FS\HS)并將設備地址復位,并通過中斷通知DCD,接收到復位后,除控制端點(0端點)外禁用所有端點,并任何已啟動的事務都被設備控制器取消;
DCD接收到復位時必須執行如下任務:
Device Controller Reset
Port Change Detect(端口探測)
檢測到端口變化后,器件達到默認狀態,同時DCD讀 PORTSC1寄存器確認器件的速率模式; 此時設備控制器已經就已經進入正常工作模式,根據USB2.0協議進行事務響應;
Device Endpoint Data Structures
端點鏈表描述符組成器件端點的數據結構,軟件為其提供初始化并控制;
Link-List Endpoint Descriptors
device 控制器存在兩種類型描述符: device Queue Head(dQH) ,device Transfer Descriptor(dTD);
DMA引擎使用Link-List描述符來響應來自host的端點包請求;
DCD維護每個隊列頭的dTD鏈表的頭尾指針;因為dQH只維護當前工作dTD和下一個執行的dTD;
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VdVUSXSm-1649168263516)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/17_device_link_list.png)]
Descriptor and Data Flow
每個端點一個Queue Head;
根據上述章節所描述的內容,驅動層在初始化時初始端點并設置dQH,dQH維護當前執行dTD及下一次dTD,這個結構加上Tx_Buf組成發送數據結構,同時驅動層為達到保護內存的目的去維護dTD的頭尾;
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9Sq78SXf-1649168263517)(18_data_flow.png)]
Manage Endpoints
端點為USB設備唯一可尋址的部分,其作用在于Host和Device的信道中獲取或接受數據;
端點地址由端點編號和端點方向共同確定;
Host和Device端點之間為數據管道,Device 的端點0始終適用于設備發現和枚舉的控制端點; 端點類型與傳輸類型一一對應;端點數量最大12個(針對Zynq);
DCD可以啟動, 禁用, 配置端點類型, 每個端點方向獨立存在,即可以在每個方向上配置不同的行為; eg: endpoint1 的IN和OUT可以為不同的端點類型;
每一個端點方向在內存中需要一個dQH, 這意味著最高需要24個dQH來描述
Endpoint初始化
硬件復位后所有非0端點都是禁用且未初始化的;
DCD通過寫入配置寄存器 usb.ENDPTCTRLx 使能和配置每一個端點;
每個32位 usb.ENDPTCTRLx 分為上半部分和下半部分, 下半部分用于接收或OUT端點,上半部分用于配置相應的發送或IN端點; 控制端點必須在usb.ENDPTCTRLx寄存器的上半部分和下半部分配置相同否則為未定義定位;
Stall 參考USB2.0 chapter 8.4
如下兩種情況下Device需要向Host返回STALL:
- Functions Stall: 軟件啟動(僅限非控制端點);
- Protocol Stall : 硬件啟動(控制端點)
Function Stall(功能停頓),由DCD基于USB2.0實現停頓, 功能停頓僅限于非控制端點, 可以通過設置與給定端點和給定方向關聯的usb.ENDPTCTRLx[TXS]停頓位在Device Controller中啟動. 在啟動條件下, 控制器將繼續向發生在相應端點和方向上的所有事物返回STALL響應,直到端點停止位被DCD清除;
Protocol Stall(協議停頓),用于控制端點, 并在新的控制事務(設置階段)開始時由設備控制符自動清除. 啟動協議停頓時,DCD應成對啟動停頓位(IN and OUT),對usb.ENDPTCTRLx 寄存器一次寫入保證兩個停止位同時設置;
注: 任何寫入usb.ENDPTCTRLx 寄存器的操作必須保留端點模式字段;
Data Toggle 參考USB2.0 chapter 8.6
數據切換對應到USB2.0 即為包域的Data 0/1 切換及一系列的機制跳轉;
DCD可以復位數據翻轉狀態位, 并通過usb.ENDPTCTRLx [TXR]寄存器中的數據翻轉位寫入1來使設備控制器中的數據翻轉序列復位,這個操作只有在 配置/初始化/從STALL條件返回 時需要執行;
Device Endpoint Packet Operational Model
所有傳輸由USB Host發起,Device在一定時間范圍內進行響應;
主機無法精確預測每個單個管道的順序去向設備控制器發送請求, 因此無法為設備控制器準備單個數據包來執行,但是 當考慮端點編號和方向時,數據包請求的順序是可預測的, eg:端點3(傳輸方向)配置為bulk pipe,那么可預期主機向該端點發送IN請求;
所有傳輸由USB Host發起,Device在一定時間范圍內進行響應;
主機無法精確預測每個單個管道的順序去向設備控制器發送請求, 因此無法為設備控制器準備單個數據包來執行,但是 當考慮端點編號和方向時,數據包請求的順序是可預測的,
eg:端點3(傳輸方向)配置為bulk pipe,那么可預期主機向該端點發送IN請求;
Prime and Flush Endpoints
器件控制器的實現方式為預測主機對每個端點或方向所發出的請求.;
準備響應總線上的主機發起的事務發送或接受數據的設備控制器的過程稱為"prime"端點;
"flush"用于清除排隊執行的數據包的操作;
flushing一個控制器端點會導致此端點 de-primed(意味著端點必須完成重新初始化才能繼續使用);
Prime Transmit Endpoints
啟動發送端點會觸發控制器獲取dQH指向的事務的dTD;取到dTD后其會被復制到dQH中,直到Device Controller完成dTD描述的傳輸;從dQH覆蓋區域中復制dTD允許Device Controller獲取處理來自主機的請求所需的操作而不需要遵循dTD鏈表,從接受主機請求的dQH開始;
設備加載dTD后,數據包中的前導數據存儲在設備控制器的FIFO中; 此FIFO被拆分為虛擬通道,已達到存儲多
端點前導數據的摸底,拆分量取決于初始化時配置的端點量;
啟動請求完成后, 端點狀態在ENDPTSTATUS寄存器中報告. 對于已啟動的發送端點,device controller就可以進行IN事務的響應且嚴格滿足USB總線周轉時間;
由于控制器FIFO中只進行前導數據的存儲,因此設備控制器需要在事務開始后填充前導數據,同時考慮系統內存總線對FIFO大小的影響;
Prime Receive Endpoints
DCD層面接收端點和發送端點一致;
設備控制器層面,其與發送端點區別在于前導數據包數據沒有數據移動, 因為數據是從主機接收;
接收FIFO不分通道且大小固定;
中斷及批量端點操作模型
中斷端點和批量端點操作一致;
所有有效的傳輸事務通過BULK管道, 端點準備好進行數據傳輸, 未準備全部返回NAK;
Device Controller會收回dTD當傳輸描述符中描述的包完成時, 每個dTD描述了根據USB協議的變長協議計算的需傳輸的N個報文,設備控制器根據最大裝載和需傳輸總字節數計算USB發送和接收數據包的數量和長度,計算公式如下:
N = INT(Number of Bytes/Max. Packet Length) + 1; (With Zero Length Termination dTD.ZLT == 0)
N = MAXINT(Number of Bytes/Max. Packet Length); (With Zero Length Termination dTD.ZLT == 1)
注: dQH.Mult 域在中斷 , 批量, 控制傳輸中必須設置為 “00”
關于dTD.ZLT 在批量及控制傳輸中的操作:
默認值 = 0;意味著Zero Length Termination開啟;
滿足下列條件時,硬件會自動附加一個零長度數據包:
-
傳輸的數據包等于最大數據包長度
-
dTD已發出所有字段
在此之后,dTD被銷毀. 設備在接收時,如果接受到的最后一個包長度等于最大包長度且總字節數為0 ,它將等待來自主機的一個零長度包退出當前的dTD;
dQH.ZLT = 1,意味著Zero Length Termination關閉;
硬件不在自動添加零長度數據包;
在接收時,其不需要零長度的數據包來銷毀最后一個數據包等于最大數據包的dTD. 一旦總字節數為0,或收到一個短數據包,dTD自動銷毀;
當dTD描述的數據包成功完成時, dTD中的活動位將會清除,并且當中中止位被清除時跟進下一個指針.當設置中止位時,Device Controller會flush 端點并停止對該端點的操作;
在一個數據包未完成時,dQH將指向錯誤的dTD, 并嘗試恢復,恢復手段為清除活動位來重新初始化dQH, 并在嘗試重新啟動端點之前跟新到下一個dTD指針;
注: 類似握手缺失或CRC失敗等數據包級操作控制器會自動重傳, 不需要與DCD進行交互;
中斷及批量端點總線響應
注:
-
BS Error->強制位填充錯誤;
-
NYET/ACK->NYET除非dTD描述的數據大于最大狀態即有剩余的數據包 then ACK(此處對ug585的表述不太理解) 根據抓包判斷正常傳輸返回ACK , 當返回NYET時下次傳輸Host會在下發OUT事務前先行下發PING包, 那么可以理解為NYET是向主機包括存在下一次接收句柄存在風險(當前包接收成功但沒有空間接收下一幀),Host下發PING包確認狀態后在下發OUT;
-
BTO->總線超時;
-
SYSERR->延遲FIFO大小合適 DCD有相應 此錯誤不會發生;
Device Endpoint Packet Descriptor Reference
Endpoint Queue Head Descriptos (dQH)
dQH用于所有的Device Controller傳輸的管理, 大小為48Bytes, 在實現時字節對齊至64字節;
在端點啟動時,硬件從系統內存中讀取dQH和第一個dTD, 并將其覆蓋在dQH的2~8 (雙字節),如下:
| 31:30 | Mult. 高帶寬管道Multiplier,該字段用于指示每個dTD執行的數據包數量 00: N個數據包 N的取值見chapter C, 非同步傳輸端點必須設置為 00; 01 : 1個事務, 10 : 2個事務, 11: 3個事務 .同步端點任選 |
| 29 | ZLT 見chapter C |
| 28:27 | 保留,設置為0 |
| 26:16 | 最大裝載長度, 對應關聯端點的wMaxPacketSize , 最大 0x400 |
| 15 | 設置時中斷, IOS, 被用于控制端點,指示USBINT是否響應接收 |
| 14:0 | 保留 設置為0 |
| Dword 1 | 當前dTD指針 |
| 31:5 | 指向傳輸覆蓋區域中表示的dTD的指針, 在端點啟動或隊列推進器件該字段由設備控制器修改為下一個dTD指針. 設備控制器使用當前dTD指針來定位正在進行的傳輸. 此字段僅由設備控制器硬件使用, DCD不能對其進行操作; |
| 4:0 | 保留 設置為0 |
| Dword 2 | 下一dTD指針及中止 dQH Dword:2 dTD Dword:0 |
| 31:5 | 下一個要處理的dTD的系統內存指針 |
| 4:1 | 保留 設置為0 |
| 0 | 中止傳輸 T; 0->鏈接到下一個dTD指針, 且地址有效; 1->中止傳輸,下一個dTD指針域無效 |
| Dword 3 | Total Bytes, MultO, and Status dQH Dword:3 dTD Dword:1 |
| 31 | 保留 設置為0 |
| 30:16 | Total Byte: 此次傳輸描述的字節數總量,在事務成功完成時進行遞減 DCD能存儲最大值為5*4K = 0x5000;(僅當Dword4偏移量為0時); 一般建議最大值取16KB; |
| 15 | 完成時中斷, 指示是否設置USBINT以響應設備控制器完成此dTD |
| 14:12 | 當前頁 , 器件模式保留 |
| 11:10 | Multiplier 覆蓋,用于傳輸同步數據包, |
| 9:8 | 保留 設置為0 |
| 7:0 | 設備控制器使用該字段將單個命令執行狀態返回DCD; 此字段包含在此dTD上執行的最后一個事務的狀態; Bit[7]活動狀態, bit[6]暫定狀態 bit[5]數據緩沖區錯誤狀態 bit[3]傳輸錯誤狀態 其余位保留 |
| Dword 4 | 第0頁緩沖區指針及當前偏移量 dQH Dword:4 dTD Dword:2 |
| 31:12 | Buffer Point : 4KB邊界對齊的系統內存地址 |
| 11:0 | 當前偏移量 |
| Dword 5 | 第1頁緩沖區指針及幀號 dQH Dword:5 dTD Dword:3 |
| 31:12 | Buffer Point : 4KB對齊的系統內存地址 |
| 11 | 保留 |
| 10:0 | 幀號 ,由設備控制器進行寫入,以指示分組完成的幀號; 通常用于將分組的相對完成時間關聯在ISO端點上; |
| Dword 6-8 | 第2-4頁緩沖區指針 dQH Dword:4-6 dTD Dword:6-8 |
| 31:12 | Buffer Point : 4KB對齊的系統內存地址 |
| 11:0 | 保留, 設置為0 |
| Dword 9 | 保留 |
| Dword 10 | 設置緩沖區字節 [31:24]->Byte3 , [23:16]->Byte2 , [15:8]->Byte1 , [7:0]->Byte0 |
| Dword 11 | 設置緩沖區字節 |
Endpoint Transfer Descriptor(dTD)
dTD向設備控制器描述給定傳輸中要 發送/接受 的數據的位置和數量;
實現時對齊到32字節;
DCD不能修改正在活動中的dTD任何字段, next dTD可以;
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-rnqM1kZS-1649168263521)(https://raw.githubusercontent.com/H-voyager/markdown-photo/main/usb-device/21_dtd.png)]
Endpoint Transfer Overlay Area(參考figure15-14)
控制器從內存中讀取dQH并鏈上一個dTD. dTD同樣從內存中讀取, 并寫入dQH的覆蓋區;
覆蓋區域的7個雙字空間代表設備控制器的事務工作空間. 端點準備好后, 設備控制器將把dTD復制到此dQH的這個空間.在傳輸未完成之前, DCD不能寫入隊列頭覆蓋區域或關聯的dTD. 傳輸完成后,設備控制器會將dTD寫回系統內存(添加狀態結果)并推進隊列指針;
如果鏈表存在后續, 則從內存中取出另外一個dTD并將其寫入dQH的傳輸覆蓋區域. 處理完鏈表,dQH寫回系統內存, 端點服務完成.
Device Controller 編程模型
設備控制器的功能是將內存映射中的請求傳輸到USB或從USB獲取. 設備控制器根據應用層協議對端點進行編程和初始化. 控制器執行一組鏈表傳輸控制符,dQH指向,設備控制器執行請求的數據傳輸.
設備控制器初始化
硬件復位之后,器件在Run/Stop位未置為1處于禁用狀態, 在禁用狀態下, 為防止放生連接,USB 的D+上拉電阻不活動. 為創建連接,須在設備連接發生之前為控制端點 0 設置dQH. 之后設備啟動,并進行USB協議的連接控制進行一系列的操作包括再復位,dQH是設備控制器可以存儲轉入的設置數據包的前提;
為達到初始化器件的目的,DCD必須執行以下操作:
設置控制器為器件模式, 向usb.USBMODE [CM] 位寫10
- 從主機模式轉換到設備模式需要在修改USBMODE之前復位設備控制器
- Set usb.OTGSC [OT] bit = 1.
分配并初始化dQH
- 至少為控制端點0 接受和發送初始化dQH\
- 控制端點的dQH初始化必須在端點使能之前;
非控制端點dQH初始化可以不再啟動端點之前初始化,但是一定要在使用端點之前;
向usb._ENDPOINTLISTADDR [31:11] 位寫入dQH的頭端點列表地址;
使能軟件中斷
- 在GIC中使能IRQ中斷(53/76)
- 在usb.USBINTR 寄存器中使能器件中斷 參考table15-2
- USB 中斷 (UI)
- USB錯誤中斷 (UEI)
- 端口狀態探測 (PCI)
- USB復位接受 (URI)
- DC延遲 (SLI)
使能Run Mode 設置Run/Stop位
- 設置運行位后,會發生 Device USB復位, DCD必須監測復位時間并按照總線復位的調整DCD狀態;
- 端點0僅設計為控制端點, 不需要進行ENDPTCTRL0寄存器配置;
管理傳輸描述符
端點功能在于指示DMA引擎在系統內存和TX/RX FIFO之間搬運數據;
每個端點存在兩個數據結構: IN 和 OUT ;
設備模式數據結構包括一個dQH和N個dTD, dQH定義數據傳輸類型并指向第一個dTD,dTD包括指向系統內存緩沖區的系統地址, USB數據在此由DMA進行讀寫;
存在一個dQH鏈表對24個dQH建立索引, 為建立一次傳輸,軟件需要去為IN/OUT事務構造dQH和dTD. 軟件必須在系統內存中為控制器維護一組一致的descriptors, schedules/lists,data buffers .當端點準備好傳輸數據時軟件啟動端點;
設備控制器將相關的dQH和dTD讀取到控制器的DPRAM中,DMA及協議引擎進行訪問. 當dTD的DMNA完成后, 控制器將"dTD + 傳輸結果"寫回系統內存.
當終止位T = 0(存在下一個dTD),則控制器從系統內存中獲取下一個dTD, 否則控制器停止處理端點dQH并將dQH寫回系統內存, 在一個較長的鏈表中,控制器將從系統內存與DPRAM之間反復讀寫dTD;
初始化dQH
DCD必須只在關聯端點未啟動且沒有未完成的dTD時修改dQH
Operational Model for Setup Transfers
DCD6應對設置傳輸包進行特殊處理, 設置傳輸不使用dTD, 而是將來自設置數據包的輸入數據存儲在dQH的8字節緩沖區內;
從dQH-RX中復制設置緩沖區內容到軟件緩沖區;
通過將 1 寫入usb.ENDPTSETUPSTAT中寫入相應位置來確認設置數據包;
- 確認必須發生在繼續處理下一設置數據包之前;
- 確認后,DCD將不能訪問dQH-Rx的數據緩沖區,DCD的來源只能是軟件緩沖區的數據副本;
檢查來自之前控制傳輸的未處理數據或者dTD,如果存在,則按照相應規則刷新端點;
- 設備控制器可以在先前的控制傳輸完成之前接收設置數據包,必須刷新正在進行的現有控制數據包并完成新的控制數據包;
利用傳輸描述符管理傳輸
建立一個傳輸描述符(dTD)
傳輸前需要為端點建立32字節內存對齊的dTD, 在系統內存中開辟8-DWord的一個dTD空間,
DCD執行一個dTD
DCD必須按照如下規則添加新的dTD:
- 在設備控制器到達dTD鏈表的末尾時, 添加新的dTD至鏈表末尾
判斷一個鏈表是否為空: 檢查管道是否為空
Link list為空:
Link list不為空:
傳輸完成
在初始化dTD并且相關端點已經準備好后,設備控制器將根據Host發起的請求執行傳輸, 如果設置了完成時中斷, DCD將收到USB中斷通知,或者DCD可以輪詢端點完成寄存器查找dTD的執行狀態. 執行dTD后, DCD可以通過狀態位判斷執行結果;
注: 多個dTD可以在單端點完成通知時完成. 完成通知后,DCD必須檢索dTD鏈表并退出所有已完成的dTD(活動位清除). 通過讀取已完成dTD的狀態字段,DCD可以通過以下狀態位判斷傳輸結果:
Active = 0 & Halted = 0 & Transaction Error = 0 & Data Buffer Error = 0
上述結果之外的所有結果均為失敗 ,DCD必須進行相應的措施;
除檢查狀態為之外,DCD必須讀取傳輸傳輸字節字段來確認實際傳輸的字節;
傳輸完成后, 傳輸的總字節數減去傳輸的實際字節數;
對于發送數據包,只有實際字節數達到0 后數據包才為傳輸完成;
對于接受數據包,Host可能會根據USB的可變數據包協議在傳輸中發送較少的字節數;
端點 Flushing/de-Priming
當接受到USB設備復位, 發生控制傳輸中斷,DCD必須flush位來對一個或多個端點進行卸載, 應用層面的停止傳輸同理; 實現步驟如下:
Device Error
控制器不自動handle的包錯誤如下:
除上表中同步傳輸外所有的傳輸類型的所有錯誤都由控制器處理(數據緩沖區溢出除外)
傳輸完成
在初始化dTD并且相關端點已經準備好后,設備控制器將根據Host發起的請求執行傳輸, 如果設置了完成時中斷, DCD將收到USB中斷通知,或者DCD可以輪詢端點完成寄存器查找dTD的執行狀態. 執行dTD后, DCD可以通過狀態位判斷執行結果;
注: 多個dTD可以在單端點完成通知時完成. 完成通知后,DCD必須檢索dTD鏈表并退出所有已完成的dTD(活動位清除). 通過讀取已完成dTD的狀態字段,DCD可以通過以下狀態位判斷傳輸結果:
Active = 0 & Halted = 0 & Transaction Error = 0 & Data Buffer Error = 0
上述結果之外的所有結果均為失敗 ,DCD必須進行相應的措施;
除檢查狀態為之外,DCD必須讀取傳輸傳輸字節字段來確認實際傳輸的字節;
傳輸完成后, 傳輸的總字節數減去傳輸的實際字節數;
對于發送數據包,只有實際字節數達到0 后數據包才為傳輸完成;
對于接受數據包,Host可能會根據USB的可變數據包協議在傳輸中發送較少的字節數;
端點 Flushing/de-Priming
當接受到USB設備復位, 發生控制傳輸中斷,DCD必須flush位來對一個或多個端點進行卸載, 應用層面的停止傳輸同理; 實現步驟如下:
Device Error
控制器不自動handle的包錯誤如下:
[外鏈圖片轉存中…(img-zdzCOdQY-1649168263522)]
除上表中同步傳輸外所有的傳輸類型的所有錯誤都由控制器處理(數據緩沖區溢出除外)
總結
以上是生活随笔為你收集整理的Zynq7000 USB2.0协议解析及USB控制器详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Rocket之加速器
- 下一篇： 缓冲技术之二：缓冲池BufferPool