打印
[应用相关]

AT32不同芯片的USB 驱动[交流并持续更新]

[复制链接]
366|1
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
lvben5d|  楼主 | 2022-9-7 10:49 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 lvben5d 于 2022-9-8 07:24 编辑

由于目前用到了AT32F403A,这款芯片的USB缓冲区 如果不使用,还可以被CAN0或1霸占。 跟我之前调试好的AT32F4X5 具备独立1280字节的缓冲区是不同的。当然我是有可能既用USB也用一个CAN通道~
库函数也略有一些不同点,比如AT32F403A 可以霸占CAN0 CAN1的所有1280RAM,成为双端口的 SRAM 缓冲区。 双端口的好处,应该是MCU 控制USB收和发分开的时候,就可以尽快访问内存控制器了吧? 加快了以前 单SRAM必须 一个读或写完,才可以进行下一个。(好像CAN0 CAN1无法同时霸占掉 1280BYTE 参看RM_AT32F403A_407_407A_CH_V2.03   381页 24.3.3 USB缓冲区)


个人从实际应用出发感觉:除了EP0 占用了收和发EP 各最大64字节 (实际可以少几个字节,根据设备描述符最大字节设计),其余缓存实战中,如果是USBFS模式 一个包最大64字节,
收包这边 很容易要做成 软件层面的叠包处理,我一般把USB D这边 第一个包的包头作为区分后续要不要叠包的head 然后跟着包的长度指示字节(2Byte) 为什么是2Bytes, 因为上位机更新FLASH (我目前435 的1个FLASH Page是1024字节) 上位机解析HEX文件后加协议包头、长度 、SN 、内容 、CRC8 一共是1030字节。  
如果我们上传内容一次超过64字节,那么我们是自己拆包分发呢,还是直接把超过64字节的数据 塞入USB EP TX FIFO里,让USB驱动层去处理拆包分发,减少应用层麻烦 (这个我后面有空去测试下,哪个方便实战)。 我记得我以前用GD USBFS Dev,可以塞入大于64字节内容,交给USB驱动层去上传(需要确认下)

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

95

主题

746

帖子

12

粉丝