基于DWC2的USB驅動開發(fā)-0x03 DWC2 USB2.0 IP 架構介紹之接口和協議時序

本文轉自公眾號,歡迎關注)

基于DWC2的USB驅動開發(fā)-0x03 DWC2 USB2.0 IP 架構介紹之接口和協議時序 (qq.com)

前言

這部分以一些典型的傳輸為例,介紹控制器的處理過程。這部分內容比較重要,對于時序的理解有助于軟件編寫，尤其了解整個過程的先后順序，邏輯，比如什么時候產生中斷，什么時候硬件做什么，什么時候軟件做什么，這些都是驅動編寫需要了解的?？梢月毤毱?，后面編寫軟件調試過程還會結合寄存器狀態(tài)，結合調試過程不斷加深理解。

控制寫

如下以設備模式,DMA操作方式,16位utmi接口,SetAddress的Setup階段為例

注意以上5個關鍵過程

1. 軟件使能OUT端口,設置好DMA,準備好接收數據。
2. HOST發(fā)送Setup包過來,控制器收到并且硬件自動回復ACK。
3. 控制器通過DMA將Setup包的內容搬運到系統(tǒng)memory。
4. 然后控制器自動設置NAK位,NAK所有的IN和OUT端點,不再接收令牌包。

這里硬件自動NAK進行流控, 為什么這里要硬件自動NAK呢,這是為了避免持續(xù)的setup導致異常，因為由軟件中斷服務中再進行NAK比較慢，所以必須硬件做。所以驅動編寫一定要知道哪些是硬件做的哪些需要軟件做。

5. 產生接收setup中斷, 軟件讀出setup內容進行解析,然后清除NAK位,重新使能端口進行接收。

如下是狀態(tài)階段

SetAddress沒有數據階段,前面的Setup數據流是HOST->DEV,所以狀態(tài)階段數據流是DEV->HOST,即HOST過來IN請求數據,DEV返回0長包。

1. 軟件使能IN端點,配置DMA發(fā)送0長包。
2. 控制器認為此時數據還未就緒所以NAK主機的IN請求。
3. 控制器產生發(fā)送空中斷。
4. HOST繼續(xù)IN請求,此時控制器準備好了數據,所以返回了0長包。
5. 控制器產生發(fā)送完中斷,即0長包發(fā)送完通知軟件處理。

以上幾點一些個人理解暫時不確定:

為什么1已經使能了IN端點,配置好DMA了,2時間點在1的后面為什么還是NAK,這里應該是軟件DMA配置好,使能IN端點了,但是DMA還沒將0長數據包更新到TxFIFO(雖然0長包不需要復制負載數據但是還是有包頭包尾CRC等需要準備)，所以此時還沒有數據可以發(fā)送到USB總線上去所以是NAK

3這里產生發(fā)送空中斷指的是緩沖區(qū)空，而不是指的總線數據發(fā)送完，所謂的緩沖區(qū)空即軟件可以繼續(xù)配置下一個DMA準備下一個DMA搬運了。此時數據已經就緒到TxFIFO隨時都可以發(fā)送到USB總線了。

所以4這里 HOST再來IN請求時控制器就可以返回0長包了

然后5這里就產生發(fā)送完中斷(這里應該是真正的總線上數據發(fā)送完)。

所以什么時候產生什么中斷是編程需要了解的非常重要。

設備模式BULK OUT

這里順便提一下USB中的IN和OUT是以HOST的角度去說的。

比如IN指的是數據DEV->HOST

OUT指的是數據HOST->DEV。

不管是設備端還是主機端都是這個角度說的。

如下以包長為1的BULK OUT傳輸，DMA模式為例

1. 軟件設置好DMA,使能OUT端點.
2. HOST發(fā)送一個1字節(jié)長的BULK OUT包,控制器因為已經就緒接收,所以ACK該包，接收的數據在接收緩沖區(qū)。
3. 控制器通過DMA將接收緩沖區(qū)的數據搬運到系統(tǒng)memory。
4. 控制器產生接收完成中斷。中斷中就可以對數據進行處理。

設備模式BULK IN

如下以包長為1的BULK IN傳輸，DMA模式為例。

1. 此時發(fā)送FIFO中沒有數據,所以HOST來IN請求時,控制器返回NAK
2. 控制器產生TXFIFO空中斷,表示TXFIFO中沒有數據了,可以準備發(fā)送數據了。
3. 軟件配置好DMA和使能IN端點。
4. 控制器通過DMA將數據從系統(tǒng)memory搬運到TXFIFO中。在完成搬運前都是NAK主機的IN。
5. 完成數據搬運到FIFO，FIFO中有數據了，此時HOST再來IN，則控制器將緩沖區(qū)的數據發(fā)送到USB總線上去。
6. 控制器產生發(fā)送完中斷。

設備模式Interrupt OUT

以下以設備模式,DMA操作,中斷OUT傳輸252字節(jié)數據。和BULK OUT類似。

1. 軟件配置好DMA和使能OUT端點。
2. 控制器接收HOST發(fā)送的數據到接收緩沖區(qū)，并ACK。
3. 控制器通過DMA將接收緩沖區(qū)的數據搬運到系統(tǒng)memory。
4. 產生接收完成中斷。軟件可以處理數據了。

設備模式Isochronous IN

以下以設備模式DMA方式的ISO IN傳輸為例

1. SOF令牌，ISO的傳輸以SOF微幀為單位進行。
2. 控制器產生SOF中斷。
3. 軟件設置好DMA使能IN端點。
4. IN端點使能后，控制器開始通過DMA將系統(tǒng)memory的數據搬運到發(fā)送FIFO中去。
5. 下一個SOF到來并產生SOF中斷
6. 本次SOF的HSOT的IN請求，設備的FIFO中已經準備好數據所以可以發(fā)送到總線上去給HOST。
7. 產生發(fā)送完中斷。

主機模式 Isochronous IN

以下以主機模式DMA方式的ISO IN傳輸為例

應用程序必須在傳輸之前安排一個（微）幀的傳輸。

1. 控制器產生SOF中斷。
2. 軟件配置好通道信息以準備接收下一個微幀的數據。
3. 下一個SOF中斷。
4. 控制發(fā)送IN請求并接收設備返回的數據。
5. 控制器將接收到的數據通過DMA搬運到系統(tǒng)memory中。
6. 控制器產生接收完成中斷。

主機模式Slave操作方式Bulk Out傳輸

以主機模式 Slave操作方式 Bulk Out傳輸1個字節(jié)數據為例。

Slave模式需要CPU通過AHB總線去寫數據到發(fā)送FIFO，而不是DMA自動搬運。

1. 控制初始化配置好BULK OUT的通道。
2. 軟件將數據寫入TXFIFO中。
3. 控制器發(fā)送TXFIFO中的數據。
4. 發(fā)送完產生中斷。

總結

以上以各種典型的傳輸時序圖為例介紹了控制器的處理過程,把這部分放在開始寫代碼之前也是為了先有一個大概的整體了解，才能確定程序的框架流程如何設計。