作者：sakumisu

背景

之前適配 DWC2 USB IP 的時候，主要是基于 st 的 hal 庫來走的，現在終于有空對此進行一下重構。

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

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

排坑

ok，現在我們開始一步步排坑

全局中斷 SOF

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

HCFG 中的 bit 0-1

這也是坑，我們直接看結論，人家手冊里說了，每次設置時，需要復位，st 代碼中楞是一個字沒看見。小坑

HCINTMSK 中的 USB_OTG_HCINTMSK_NAKM

這里面中斷標志那是相當多，最坑的是什么，USB_OTG_HCINTMSK_NAKM,我可以說，論壇出現的所有 NAK 的原因都是他造成的，什么枚舉 NAK,U盤 NAK，都是他。究其原因，NAK 表示當前沒有準備好，需要重試，但是其實并不需要，st 的代碼中，進入 NAK 中斷以后會關閉當前通道傳輸，然而，對于控制和批量傳輸這是沒有必要的，傳輸是可以等到完成的。開了這個，就會造成，各種地方需要手動重發，然后讀?HAL_HCD_HC_GetURBState，沒有必要，關掉該中斷給你帶來無限可能。

HAL_HCD_HC_SubmitRequest

大坑來了，此函數就是配置發送需要的 size、packet、buf地址等等。坑1：有 dma 沒見你用。坑2：hc->xfer_len?并不能為所欲為的傳任何值。坑3：開了 fifo 不為空中斷，卻沒有該中斷處理。

?

修改

能用 dma 的全都用 dma

關閉 NAK 中斷，中斷和同步傳輸保留

HAL_HCD_HC_SubmitRequest 函數設計太拉稀，我們需要做一個調用一次，大小隨意，具體切包的實現在完成中斷中，最后達到滿意的大小后，釋放信號量，達到最大帶寬。比如我要發送 16K，我只管傳16K，里面怎么發，設計好就行，后續看我代碼吧。現在的函數是不行的。

中斷和同步傳輸，由于硬件太坑，只能用定時器了，因為中斷和同步，調用類似?HAL_HCD_HC_SubmitRequest?的函數并不能幫我們完全的發出去，也就是即使我調用了，他也不一定會成功，相信看過 rt 源碼的知道，drv_pipe_xfer?中有個 delay函數。而我們的做法則是掛到定時器中，鏈表式發送。

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

代碼已更新

支持 dma 模式下調用一次收發函數，長度可達 16K 字節。并且 DMA 模式下自動分包。

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