作者：sakumisu

背景

之前適配 DWC2 USB IP 的時(shí)候，主要是基于 st 的 hal 庫(kù)來(lái)走的，現(xiàn)在終于有空對(duì)此進(jìn)行一下重構(gòu)。

https://club.rt-thread.org/ask/article/dac2a83e018f6ad2.html

https://club.rt-thread.org/ask/article/b39785f4dd8a6032.html

排坑

ok，現(xiàn)在我們開(kāi)始一步步排坑

全局中斷 SOF

首先是全局中斷 SOF ,這是一個(gè)比較坑的，尤其是帶了 OS 以后，幾個(gè)意思，跟我 os 搶中斷呢？sof 中斷 1ms會(huì)觸發(fā)一次，很費(fèi)中斷。為什么會(huì)有這個(gè)中斷開(kāi)啟？后面再來(lái)說(shuō)，結(jié)論就是 dwc2 這個(gè)ip太辣雞，硬件做的很隨意，功能沒(méi)有做到硬件上去，而這個(gè) sof 主要就是給中斷傳輸和同步傳輸用的。

HCFG 中的 bit 0-1

這也是坑，我們直接看結(jié)論，人家手冊(cè)里說(shuō)了，每次設(shè)置時(shí)，需要復(fù)位，st 代碼中楞是一個(gè)字沒(méi)看見(jiàn)。小坑

HCINTMSK 中的 USB_OTG_HCINTMSK_NAKM

這里面中斷標(biāo)志那是相當(dāng)多，最坑的是什么，USB_OTG_HCINTMSK_NAKM,我可以說(shuō)，論壇出現(xiàn)的所有 NAK 的原因都是他造成的，什么枚舉 NAK,U盤 NAK，都是他。究其原因，NAK 表示當(dāng)前沒(méi)有準(zhǔn)備好，需要重試，但是其實(shí)并不需要，st 的代碼中，進(jìn)入 NAK 中斷以后會(huì)關(guān)閉當(dāng)前通道傳輸，然而，對(duì)于控制和批量傳輸這是沒(méi)有必要的，傳輸是可以等到完成的。開(kāi)了這個(gè)，就會(huì)造成，各種地方需要手動(dòng)重發(fā)，然后讀?HAL_HCD_HC_GetURBState，沒(méi)有必要，關(guān)掉該中斷給你帶來(lái)無(wú)限可能。

HAL_HCD_HC_SubmitRequest

大坑來(lái)了，此函數(shù)就是配置發(fā)送需要的 size、packet、buf地址等等。坑1：有 dma 沒(méi)見(jiàn)你用?？?：hc->xfer_len?并不能為所欲為的傳任何值?？?：開(kāi)了 fifo 不為空中斷，卻沒(méi)有該中斷處理。

?

修改

能用 dma 的全都用 dma

關(guān)閉 NAK 中斷，中斷和同步傳輸保留

HAL_HCD_HC_SubmitRequest 函數(shù)設(shè)計(jì)太拉稀，我們需要做一個(gè)調(diào)用一次，大小隨意，具體切包的實(shí)現(xiàn)在完成中斷中，最后達(dá)到滿意的大小后，釋放信號(hào)量，達(dá)到最大帶寬。比如我要發(fā)送 16K，我只管傳16K，里面怎么發(fā)，設(shè)計(jì)好就行，后續(xù)看我代碼吧?，F(xiàn)在的函數(shù)是不行的。

中斷和同步傳輸，由于硬件太坑，只能用定時(shí)器了，因?yàn)橹袛嗪屯?，調(diào)用類似?HAL_HCD_HC_SubmitRequest?的函數(shù)并不能幫我們完全的發(fā)出去，也就是即使我調(diào)用了，他也不一定會(huì)成功，相信看過(guò) rt 源碼的知道，drv_pipe_xfer?中有個(gè) delay函數(shù)。而我們的做法則是掛到定時(shí)器中，鏈表式發(fā)送。

最后是關(guān)于?HCTSIZ_XFRSIZ?這個(gè)寄存器 bits，需要格外注意， in 和 out 的含義是不一樣的，并且數(shù)據(jù)發(fā)送接收完成以后，進(jìn)入中斷，再讀取這個(gè)值，也是不一樣的含義（藏個(gè)謎底，后續(xù)代碼揭曉）

代碼已更新

支持 dma 模式下調(diào)用一次收發(fā)函數(shù)，長(zhǎng)度可達(dá) 16K 字節(jié)。并且 DMA 模式下自動(dòng)分包。

https://github.com/sakumisu/CherryUSB/blob/master/port/dwc2/usb_hc_dwc2.c