在各个芯片的例程中，USB Host所用到的 USBHostTransact() 函数都会标明 “本子程序着重于易理解,而在实际应用中,为了提供运行速度,应该对本子程序代码进行优化”。可以看到其中有若干等待和重试，但请问应该以何种思路来优化？

您好，看您具体需求是什么样的。比如说HID从机要求中断传输，每10ms进行一个端点2的IN事务，那么主机代码里需要添加一个10ms触发一次的定时器，在定时器中置标志，来判断主循环中下一个事务，是否要优先进行一个端点2的IN事务。等待和重试，相关于进行事务的频率，也是可以根据从机的要求修改的。

意思是否是，在HID设备用途中，在while(1)中调用 USBHostTransact() 读取数据其实会有很多等待和重试从而造成浪费，应该尽量在HID设备的相同频率来调用？

那么在主机查询下游HUB端口时，因为由主机发起通讯，是否不存在此种情况？实测接hub时一次枚举需要3-4ms，很容易使蓝牙匹配超时，这种情况下是否还有优化空间？

另外对于发送频率非常高的HID设备（某些鼠标似乎能到几千？），是否有办法硬件FIFO？

主机逻辑是用户安排的，是否重试根据项目各个接口的优先级来安排。比如说USB优先，BLE次之，那就先保证USB的运行，BLE部分代码做处理，拉大连接间隔或者宽限超时时间；BLE优先，USB次之，那USB部分如果说占用时间长，可以拆分成多个事件，分散到不同事件中执行，这样可以在USB枚举等耗时比较长的逻辑中穿插蓝牙包，维持蓝牙的通信，但可能会有USB枚举不及时等问题，要添加重试或者其他处理。

如果代码安排紧凑，发现重试次数多了浪费时间，可以减少重试次数或者不重试，先释放CPU执行其他优先级更高的逻辑，回头再重试。

USB有DMA功能，但每个端点只能缓存一个包，没有硬件FIFO缓存多个包，所以需要及时接收处理。

键鼠上报率要看芯片资源了。CH582建议做1k上报率，因为582做dongle时，只支持全速USB，最短1ms上传一个包。如果选用支持USB3.0的芯片，可以尝试做4k甚至更高的上报率。