大容量輸出(Bulk-out)與控制輸出(Control-out),適用於「Ping協定」。輸出的含意是指從主機端送往裝置端。
「Ping協定」的出發點就是防止長時間大量資料傳送完畢之際,對方竟然傳回NAK信號,要求重新送一次。如此的狀態就代表著介面被佔掉的時間,成為浪費,介面的使用效率不佳。因此,才會規範了這個協定,期待可以提升介面匯流排的使用效率。
他的機制是這樣子的:主機端在傳送64個位元組(如Control Out傳送)或是512位元組(如Bulk Out傳送)的資料到裝置端之前,先行由主機端送出「Ping封包」,觀察其回應是ACK還是NAK,用來確認裝置是否準備就緒。這個概念與網路上的Ping指令是一致的思維。
規格書中,為了詳細描繪「Ping協定」的動作,利用了狀態遷移圖的方式,對主機端的狀態遷移以及HS快速裝置的狀態遷移,有很清楚的交代。
以主機端狀態遷移圖為範例來說,當送出「Ping封包」之後,如果得到NAK的場合,表示裝置端沒有接收的空間,如果執意地將DATA0/1封包丟往裝置端,很有可能的結局就是依然得到NAK的否定確認回應。因此,圖4的主機端狀態遷移圖,顯示如果送出「Ping封包」之後,得到NAK的場合,並不會傳送「OUT封包」以及「DATA封包」,而是再度傳送「Ping封包」,重複確認。
這就是「Ping協定」的基本精神。
接著下來,利用一個具體的實際範例來闡明「Ping協定」動作的細節。
請留意,從主機端送往裝置端時,使用放大鏡來觀察其細部的話,其走過的足跡卻是,從主機端經過USB介面匯流排,到達快速裝置的控制器,再經過裝置內部的局部匯流排(Local Bus),就可以到達讓裝置動作的韌體。其關連性是相當廣泛的。
以大容量輸出傳送(Bulk Out)來說,USB 2.0的主機端(通常是個人電腦),通常是針對裝置端控制器內的特定端點,傳送512位元組的封包。而裝置端控制器的接收端點,一般是利用兩個512位元組的FIFO(FIFO是First In First Out的元件,通常,是作為緩衝的用途)。
當緩衝器接收完主機端送過來的資料之時,會告知裝置內部的韌體,接收封包已經備妥。如此一來內部的韌體就會藉由局部匯流排,實行將緩衝器的資料傳送到系統的記憶體之中。資料傳送完了之際,會通知控制器,那麼控制器就可以騰出緩衝器的空間來。基於這樣子的思考,HS快速裝置,如何來達到介面匯流排使用的最高效率,就是不產生NAK、NYET的情況下,「OUT封包」、「DATA 0/1封包」以及「ACK」的順序遞送。這樣子的時間,有機會是“9.5 us”的光景。
所以,對於一個工程人員來說,韌體撰寫的應答時間以及資料處理時間,該如何地最佳化,是HS快速裝置設計者,要好好下功夫的一道習題。也是重要的一個環節。
2 則留言:
你好
請問你有寫過 Linux usb gadget driver 嗎?
可以跟你討論嗎?
謝謝
你好
請問你有寫過 Linux usb gadget driver 嗎?
可以跟你討論嗎?
謝謝
張貼留言