您尚未登录。

楼主 #1 2020-07-13 11:06:58

zhjerry
会员
注册时间: 2019-12-03
已发帖子: 43
积分: 33

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

发现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小时不出问题。

离线

#2 2020-07-14 17:12:10

liuchangyin
会员
注册时间: 2020-03-17
已发帖子: 204
积分: 199

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

CubeMx生成的代码有问题吧,这个还不稳定,发现了很多bug

离线

楼主 #3 2020-07-14 17:47:05

zhjerry
会员
注册时间: 2019-12-03
已发帖子: 43
积分: 33

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

几年前的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失望。

离线

#4 2020-07-18 18:51:43

liuchangyin
会员
注册时间: 2020-03-17
已发帖子: 204
积分: 199

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

zhjerry 说:

几年前的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库,这个效率肯定会高些

离线

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn