可以使用USB2.0介面進行全雙工通訊么，雙方都可以主動發送么？

01-21

兩塊嵌入式ARM晶元間，想通過USB2.0介面進行通訊

USB 2.0協議要求設備必須一個是Host另一個是Device，所有的請求都必須由Host發起，Device自己決定是否要給予正確的回應。有一個特例就是OTG，理論上USB-OTG是允許Host和Device互相切換的，但驅動特別複雜，也沒有明確的設備可以在連接的狀態下動態切換。

所以你如果兩塊ARM晶元用USB通信，就必須要一個做Host，另一個做Device，Host負責供電和發起請求。Device不可以主動發起請求。不要被協議規範的字眼迷惑，Interrupt傳輸也是由Host發起的，不是Device發起的。

如果為了簡單起見，建議用串口，RS232既簡單由好用。一個簡易的USB協議棧也要幾十K的binary code，摺合代碼也得上千行了。

------------------------補充------------------------

USB2.0是半雙工傳輸，匯流排上的信號可以理解為：主機發送請求-&>設備回應請求，這種模型。

USB2.0 EHCI控制器需要設置一堆控制器，需要設置伴侶晶元(1.1控制器)或者embinedTT（大概叫這個名字），要設置傳輸隊列，USB協議棧不適合簡單通信模型，USB驅動部分比網卡驅動複雜很多倍，雖然網路協議棧很大，但網卡驅動很簡單，一個C源文件，幾百行就可以搞定，但一個USB控制器驅動需要幾個C源文件，上千行代碼。

---------------------再次補充---------------------

不建議用USB協議棧的原因是：

1、傳輸距離短，USB協議規範是5米，5米的話RS232也是滿足的，相比乙太網100米來說5米簡直太短了。

2、帶寬一般，雖然2.0號稱是480Mbps，實際能利用的帶寬大概只有80%左右，並且還要進行封裝，如果換成千兆乙太網，性能會好很多。

3、協議棧太複雜，相關文檔很難找到。對比而言網路控制器的開發就簡單多了。

關於開發協議棧，我多說點：

USB開發分為3部分：控制器開發、協議棧開發、驅動開發。其中最難的部分是控制器開發，USB2.0是傳輸協議規範，並不是控制器技術規範。而控制器本身又需要大量代碼，以EHCI控制器為例，僅僅這個驅動，寫出來就夠難受的了，無數的寄存器，還要在內存里建立複雜的數據結構才能完成傳輸。而激活了控制器是不夠的，你需要在控制器驅動之上編寫支持USB2.0規範的協議棧代碼，包括URB支持、USBD支持、各種描述符的解析等等，這些比網路協議棧複雜多了。並且網路協議棧的RFC很好找，中文的也很好找，但USB的中文規範翻譯的都不太好。

當你搞定了EHCI和USB2.0傳輸，那麼你還要在你的協議棧之上增加設備驅動，這個驅動就簡單多了，但要根據你的傳輸模型來設計，比設計一個TCP傳輸模型要複雜多了。

以上工作全完成，需要幾萬行代碼，編譯完成以後需要200K-1M左右的內存來運行。

然後，一切都完成了嗎？不，你只完成了一半。

USB同網路協議棧的區別就是分host協議棧和device協議棧，二者是完全不同的，因為你是要互連，所以另外一個板子上就要開發device協議棧，device協議棧相對比較輕量級，但同樣需要開發成本，一個標準的device協議棧需要50K-200K的運行內存，開發代碼應該不少於一萬行。

然後，你兩個板子就可以互連通信了。

你以為這樣就完事了？還沒完。

支持device協議棧的板子很少，USB控制器不是對等的，兩個EHCI控制器無法互連，而支持device協議棧的設備都不是標準的EHCI控制器，多數情況下這些板子就根本不帶有EHCI控制器，這種板子開發USB2.0會更難，因為你根本找不到開發手冊，比如一般的MHCI或者SHCI控制器，只有很少很少的資料。而且我就沒見過中文的USB Device Stack規範。

那麼你想想你的開發成本吧，先要學習標準的USB2.0規範，搞清楚EHCI是怎麼回事，然後去研究一些偏門的設備，研究MHCI/SHCI是怎麼回事，再在上面分別實現USB Host Stack和Device Stack，之後還要在這之上設計不同的兩個通訊用的驅動，需要1M的運行內存，幾萬行代碼，你覺得這樣的開發成本可以接受嗎？

為什麼我建議用網路或者RS232，因為這是對等的協議，兩個設備的驅動開發完全一致，區別只是上層的部分的一點點內容，並且資料很多，很容易找到可以移植的代碼。

----------------------------------------------------

USB各種規範的規模（全英文）：

《Universal Serial Bus Specification Revision 2.0》- USB2.0協議規範，650頁

《Enhanced Host Controller Interface Specification for Universal Serial Bus》 - EHCI規範，155頁

《Universal Host Controller Interface (UHCI) Design Guide》 - USB UHCI（1.1）規範，47頁

《On-The-Go Supplement to the USB 2.0 Specification》 - OTG規範，53頁

還有若干class device規範我就不列出來了，MHCI的規範我沒有找到，應該也不會太少，相比網路協議棧的RFC，這方面的中文資料實在是太少了。

找不到用USB的理由。

同一塊board上的晶元嗎？

還不如直接用GPIO自己寫一個協議來得快。

或者GPIO模擬IIC。

不同board，走Ethernet，你要傳得遠可以把報文發到交換機上，然後電轉光，選擇太多。

就算是不帶系統，IP棧也比USB棧要高效。

需要供電？PoE走起。

抗干擾？USB太不給力了。

不知道你的信息量有多大，晶元間通訊，一般都使用SPI 、UART 、IIC。SPI和UART可以實現全雙工,但 IIC 不行。但是IIC（I2C）用的線少。各有優缺點，USB的好處在於熱拔插和使用範圍廣，但是真的不適合晶元間通訊。