发现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小时不出问题。
离线
CubeMx生成的代码有问题吧，这个还不稳定，发现了很多bug
离线
几年前的CubeMx有很多Bug，生成的程序一般需要做些修改可以运行的。2018年以后生成的USB/CDC程序框架立即可用BUG很少了。
这个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失望。
离线
几年前的CubeMx有很多Bug，生成的程序一般需要做些修改可以运行的。2018年以后生成的USB/CDC程序框架立即可用BUG很少了。
这个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失望。
可能是cubemx生成代码的效率低造成的，看看能不能使用LL库，这个效率肯定会高些
离线