STM32早期的USB-FS比后期105/107到F2和F4上面的OTG-FS的效率高

zhjerry

发现STM32早期的USB-FS比后期105/107到F2和F4上面的OTG-FS的效率高。这两天在折腾一个F103的项目升级，使用USB/CDC将ADC转换的数据连续不断地传到LinuxPC上，平均数据约100KByte/S. 72M的F103可以做到永远不出问题，使用CubeMx配置的F401可以使用72、84、96、108、120M的主频，设置不同的USB端点FIFO深度（0x40、0x80、0xF0）, 隔不了多久就会有传输无法继续看门狗重启，能做到最好的情况是6小时不出问题。

eric2013

这是程序设计问题。

zhjerry

这个F401的主程序是从F103移植过来的，只不过F103的基础是USB/CDC标准库，F401的基础是最新的CubeMx生成的USB/CDC框架。
要传输的数据一部分来自本机的ADC、一部分通过串口DMA收集的其他单片机数据（大约增加7份数据量），串口收集部分是使用DMA方法逐分机顺序进行所以基本不占用主机CPU处理时间只是增加了需要通过USB的数据量。
F103的程序有10来年的运行基础。使用4S的看门狗，每次传输一包数据（数据包大于3KB或间隔大于32ms进行一次传输），传输完成喂狗。
现在F401的程序折腾2周了。1. 如果没有串口收集的数据只传本机的ADC数据，F401也可以做到永远不出问题。2. 如果串口收集数据只接收一路，再加上本机的ADC数据F401也可以做到永远不出问题。3. 正常工作应该收集7份数据，F401就不行了，不定期看门狗重启。
现在只能怀疑F401的USB传输效率，对F401失望。

caicaptain2

cubemx里面有个大坑，Hal定时的优先级是最高级别的0，如果你的中断函数中不适用hal的延时，一定把它调到较低。 其二，cubemx里面有大量复杂的回调函数，占用中断时间。最好手动优化一下。

zhjerry

老手了，这些都是必须注意的.
由于USB和I2S只有HAL，其余都使用的LL。
在开机阶段借用一下HAL提供的SYSTICK中断，这个系统1ms定时在我自己的8K频率的I2S（ADC）中断起来后就被停止了有我自己的中断给接管了，毕竟1ms中断也满耗时的。自己的中断函数0级中断，内部不可能有延时。全系统只有USB使用2级中断和ADC的0级中断，其他各种外设如UART的DMA等都基于ST的HAL/LL库改造得到，不再使用中断。 ST的HAL/LL库开启所有的中断条件引发大量的判断效率极低，使用回调函数也一样效率低下。 现在的方法是参考库里面的启动过程修改为自己的过程，在中断服务里面直接短路各种服务， 这样总体效率和原来的库函数编程方法一样了。大循环使用状态机控制多个任务和数据流。 系统能长时间运行就不会有基本问题。