在各個(gè)芯片的例程中，USB Host所用到的 USBHostTransact() 函數(shù)都會標(biāo)明 “本子程序著重于易理解,而在實(shí)際應(yīng)用中,為了提供運(yùn)行速度,應(yīng)該對本子程序代碼進(jìn)行優(yōu)化”?？梢钥吹狡渲杏腥舾傻却椭卦?，但請問應(yīng)該以何種思路來優(yōu)化？

您好，看您具體需求是什么樣的。比如說HID從機(jī)要求中斷傳輸，每10ms進(jìn)行一個(gè)端點(diǎn)2的IN事務(wù)，那么主機(jī)代碼里需要添加一個(gè)10ms觸發(fā)一次的定時(shí)器，在定時(shí)器中置標(biāo)志，來判斷主循環(huán)中下一個(gè)事務(wù)，是否要優(yōu)先進(jìn)行一個(gè)端點(diǎn)2的IN事務(wù)。等待和重試，相關(guān)于進(jìn)行事務(wù)的頻率，也是可以根據(jù)從機(jī)的要求修改的。

意思是否是，在HID設(shè)備用途中，在while(1)中調(diào)用 USBHostTransact() 讀取數(shù)據(jù)其實(shí)會有很多等待和重試從而造成浪費(fèi)，應(yīng)該盡量在HID設(shè)備的相同頻率來調(diào)用？

那么在主機(jī)查詢下游HUB端口時(shí)，因?yàn)橛芍鳈C(jī)發(fā)起通訊，是否不存在此種情況？實(shí)測接hub時(shí)一次枚舉需要3-4ms，很容易使藍(lán)牙匹配超時(shí)，這種情況下是否還有優(yōu)化空間？

另外對于發(fā)送頻率非常高的HID設(shè)備（某些鼠標(biāo)似乎能到幾千？），是否有辦法硬件FIFO？

主機(jī)邏輯是用戶安排的，是否重試根據(jù)項(xiàng)目各個(gè)接口的優(yōu)先級來安排。比如說USB優(yōu)先，BLE次之，那就先保證USB的運(yùn)行，BLE部分代碼做處理，拉大連接間隔或者寬限超時(shí)時(shí)間；BLE優(yōu)先，USB次之，那USB部分如果說占用時(shí)間長，可以拆分成多個(gè)事件，分散到不同事件中執(zhí)行，這樣可以在USB枚舉等耗時(shí)比較長的邏輯中穿插藍(lán)牙包，維持藍(lán)牙的通信，但可能會有USB枚舉不及時(shí)等問題，要添加重試或者其他處理。

如果代碼安排緊湊，發(fā)現(xiàn)重試次數(shù)多了浪費(fèi)時(shí)間，可以減少重試次數(shù)或者不重試，先釋放CPU執(zhí)行其他優(yōu)先級更高的邏輯，回頭再重試。

USB有DMA功能，但每個(gè)端點(diǎn)只能緩存一個(gè)包，沒有硬件FIFO緩存多個(gè)包，所以需要及時(shí)接收處理。

鍵鼠上報(bào)率要看芯片資源了。CH582建議做1k上報(bào)率，因?yàn)?82做dongle時(shí)，只支持全速USB，最短1ms上傳一個(gè)包。如果選用支持USB3.0的芯片，可以嘗試做4k甚至更高的上報(bào)率。