來源：公眾號【魚鷹談單片機】
作者：魚鷹Osprey
ID ：emOsprey

我們知道，傳輸事務解決了主機、設備之間交互一次數(shù)據(jù)的問題，但是有些端點是需要進行多次雙向傳輸或者多次單向傳輸?shù)模瑫r因為設備的功能不同，所需要的帶寬和傳輸特性也不同，那么就需要一個更上層的機制解決以上問題，四大傳輸應運而生。

控制傳輸（Control Transfers）、中斷傳輸（Interrupt Transfers）、批量傳輸（Bulk Transfers）、同步傳輸（Isochronous Transfers）稱之為四大傳輸。
接下來我們看看這些傳輸各自的特點，同時了解一下這些傳輸方式在生活中的應用。

控制傳輸

一種可靠的雙向傳輸，所有USB設備必須支持的一種傳輸方式，該傳輸一般發(fā)生在端點0 中，用于USB的枚舉、配置（也可能進行其他數(shù)據(jù)傳輸）等階段。而我們接下來需要詳細介紹的傳輸方式就是它。

當設備插入主機后，主機通過端點 0 （還記得前面說它是雙向端點嗎）進行控制傳輸，通過一系列的數(shù)據(jù)交互，主機可以了解設備有多少個接口，有多少可用的端點等各種設備信息。

你的設備能否被主機（電腦）正確識別，完全取決于控制傳輸能否正常進行，這是 USB 學習中最先遇到的攔路虎，也是很多人望而卻步的一個地方，但是希望大家通過魚鷹的介紹能夠真正掌握它。

在帶寬（所謂帶寬，可以認為主機對USB總線進行分時數(shù)據(jù)傳輸，比如1秒中使用100毫秒用于控制傳輸）使用上，高速端點的控制傳輸不能占用 20 %的微幀（125 us 一個微幀），全速和低速不能超過 10 %（1 ms 一幀

在控制傳輸中，為了實現(xiàn)完整的一次控制傳輸，一般由三個階段組成：

建立階段、數(shù)據(jù)階段（該階段可能沒有，由建立階段的數(shù)據(jù)決定）、狀態(tài)階段，每一個階段都由傳輸事務組成，即存在三個數(shù)據(jù)包的傳輸。

我們可以具體看看上面最簡單的無數(shù)據(jù)階段控制傳輸（其他傳輸類似）：

這里需要特別注意的是，建立階段一定是DATA0 數(shù)據(jù)包，之后如果有數(shù)據(jù)階段，將進行翻轉(zhuǎn)，變成 DATA1，并且在每次正確數(shù)據(jù)傳輸后都會進行一次翻轉(zhuǎn)，這個機制用于保證數(shù)據(jù)被正確接收，而不是發(fā)送方發(fā)送的重復數(shù)據(jù)包（如果對方?jīng)]有正確接收數(shù)據(jù)，DATAx不會翻轉(zhuǎn)

在狀態(tài)階段，一律使用 DATA 1進行回復，狀態(tài)階段的數(shù)據(jù)包中的數(shù)據(jù)為空，也就是說不攜帶任何數(shù)據(jù)。

同時，根據(jù)建立階段中的數(shù)據(jù)要求不同，比如要求發(fā)送數(shù)據(jù)或者接收數(shù)據(jù)，將使用相反的 IN 或 OUT 令牌完成狀態(tài)階段，比如建立階段主機要求發(fā)送 15 字節(jié)到設備中，那么數(shù)據(jù)階段將先使用 OUT 令牌發(fā)送數(shù)據(jù)，之后在狀態(tài)階段主機將使用相反的 IN 令牌獲得空數(shù)據(jù)包。

因為傳輸時，可能需要多次傳輸事務才能完成數(shù)據(jù)階段，那么如何判斷對方數(shù)據(jù)傳輸已經(jīng)完成，從而讓主機不再發(fā)送IN或OUT令牌包傳輸數(shù)據(jù)呢？

有兩種可能：

如果傳輸?shù)臄?shù)據(jù)大小剛好是端點支持數(shù)據(jù)大小的整數(shù)倍，比如一個端點最大數(shù)據(jù)包長度為64字節(jié)，如果傳輸128字節(jié)，就需要在最后發(fā)送一個空數(shù)據(jù)包。

而如果要傳輸127字節(jié)，那么因為最后一個包不是滿負載（只有63字節(jié)），所以也將認為數(shù)據(jù)傳輸完成。

也就是說，最后一個數(shù)據(jù)包一定不是滿載的，前面的數(shù)據(jù)包一定是滿載的。這代表了數(shù)據(jù)階段的結束。

當完成了以上幾個階段，一次控制傳輸才算完成。

正因為控制傳輸?shù)那闆r比較復雜，所以學習起來也比較麻煩。

中斷傳輸

中斷傳輸時一種可靠的單向傳輸方式，采用定時輪詢的方式收發(fā)數(shù)據(jù)，每次主機對中斷端點查詢時，如果設備有數(shù)據(jù)傳輸，則返回數(shù)據(jù)，否則NAK，表示未準備好。

同理，如果是主機發(fā)送數(shù)據(jù)，如果設備沒有準備好接收，也將使用 NAK 回復。

如果需要雙向傳輸，必須使用 IN 和 OUT 兩個端點。

中斷傳輸?shù)难舆t有保證，也就是說，可以在有限的延遲中完成傳輸，并且支持錯誤重傳（在下一個周期進行重傳），所以它是可靠的。因為可能產(chǎn)生錯誤重傳，所以中斷傳輸也會采用 PID 翻轉(zhuǎn)的機制保證收發(fā)端數(shù)據(jù)的同步。

中斷傳輸一般用于對延遲要求比較嚴格，同時數(shù)據(jù)量較小，比如我們常見的鍵盤、鼠標就是采用中斷傳輸方式。

當你的鼠標、鍵盤插入電腦后，電腦在枚舉配置成功后，就會按照描述符中的查詢時間定時發(fā)送 IN 令牌包，獲取所需的數(shù)據(jù)，如果設備沒有數(shù)據(jù)發(fā)送，則回復 NAK。

對于全速端點，中斷傳輸?shù)拈g隔在 1 ms 到 255 ms 之間，對于低速端點，間隔時間限制在10ms到255ms之間, 對于高速端點，間隔為2^bInterval-1×125us, bInterval的值在1到16之間。

CMSIS-DAP 調(diào)試器使用的就是中斷傳輸，全速模式下1 ms 64 字節(jié)一包數(shù)據(jù)，所以最大傳輸速率是64 K，速率不是很高，如果使用高速，可以達到125 us 1024 字節(jié)，還有一種高速高帶寬的中斷端點，125 us 微幀內(nèi)可以進行三次中斷傳輸，即125 us 內(nèi)可傳輸 3072 字節(jié)。

批量傳輸

批量傳輸是一種可靠的單向傳輸，但是和中斷傳輸不同，傳輸延遲沒有保證，它會盡可能的利用可以利用的帶寬完成傳輸（說白了，就是個撿漏的），適合數(shù)據(jù)量比較大的傳輸。
當然如果說總線上只有批量傳輸，那么延遲也是能保證的，畢竟沒人和它競爭帶寬。

現(xiàn)實中，U盤就是采用批量傳輸，因為它對時間延遲不是那么嚴格，只要可靠的完成大量數(shù)據(jù)的傳輸即可。

低速設備不支持批量傳輸，高速設備批量最大包長度為512字節(jié)，全速批量可以為 8、16、32、64，選擇余地比較大。

因為會錯誤重傳，所以需要 PID 的翻轉(zhuǎn)機制，即按照 DATA0 – DATA1 – DATA0 – DATA1……的方式翻轉(zhuǎn)，允許 3 次以下的傳輸錯誤，超過三次，主機將認為端點功能錯誤 （STALL），放棄該端點的傳輸，需要主機使用控制傳輸恢復該端點的功能。

注意上面的 STALL 回復，這個代表端點錯誤，一旦回復該 STALL，如果沒有主機干預，設備將一直使用 STALL 回復，說明該端點不支持該功能或者產(chǎn)生了錯誤。

同步傳輸

這種傳輸是四大傳輸中唯一不可靠的傳輸方式，但是好處就是可以保證帶寬，并且沒有延遲，而且因為是不可靠的傳輸，所以沒有握手包，也不支持 PID 翻轉(zhuǎn)，主機在安排這些傳輸事務時，同步傳輸擁有最高的優(yōu)先級。

高速同步端點最大包長度為 1024，全速為 1023。

高速端點在一個微幀內(nèi)僅允許一次同步傳輸事務，而高速高帶寬的同步端點可以在一個微幀內(nèi)傳輸三次，即3072 Byte / 125us。

在現(xiàn)實中，這種傳輸用于攝像頭、USB音響等，因為它們對實時性要求比較高，但是可以容忍錯誤（攝像頭偶爾出現(xiàn)了一幀有錯誤的畫面，沒多大關系，因為下一幀畫面馬上就會傳過來

在前面的介紹中，一直都有幀、微幀的身影，那么它是什么？

我們知道，令牌包中有一種特殊的包，稱之為 SOF （start of frame）包，格式如下：

CRC校驗為 5 bit，和 11 bit 的幀號剛好湊成 16 bit 兩個字節(jié)。

高速設備中每過 125 us 發(fā)出一個微幀，全速每過 1 ms 發(fā)出一幀，之后才會開始數(shù)據(jù)傳輸。

主機在每個幀（微幀）的開始傳輸一個SOF，每次幀號加 1，當達到 0x7FF 時，將清零重新開始計數(shù)。

看圖理解 SOF 和其他傳輸?shù)年P系：

CRC校驗為 5 bit，和 11 bit 的幀號剛好湊成 16 bit 兩個字節(jié)。

看上圖可以了解到，每過一定時間（1 ms或者 125 us），主機發(fā)出 SOF 包，接下來進行傳輸事務（四大傳輸中的一種），每一個傳輸事務中又包含了三個數(shù)據(jù)包（我們可以認為SOF就是 USB 總線中的時鐘信號

通過上圖，我們就可以理解幀、傳輸、傳輸事務、包之間的關系了。

再用另一個圖看看四大傳輸之間的關系：

可以看到，假如總線中有四類數(shù)據(jù)需要傳輸，那么主機將在每幀開始發(fā)送SOF包，然后優(yōu)先安排同步傳輸，之后安排中斷傳輸，其次是控制傳輸，最后才是批量傳輸（大容量傳輸），所以說批量傳輸是專業(yè)撿漏的。

版權聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/weixin_42876465/article/details/108250959