- 主题:一个GD32的CAN外设硬件bug
擦,原来我已经有这么大的影响力了。我和科比合砍82分。
【 在 feiy (null) 的大作中提到: 】
: 你这个帖子,直接导致 兆易科技 股价暴跌了啊
--
修改:spadger FROM 222.90.95.*
FROM 222.90.95.*
你太较真了。
【 在 spadger 的大作中提到: 】
: 他们的理解是受了RS485的影响,完全是错误的。国外的STM32,国内的雅特力都没有问题。
: 1M波特率下,1us一个IO中断你是认真的么,而且这芯片还支持CANFD,数据域能到5M
: 追求极限才能把产品做好,比如我可以用8051做usb-blaster做到比别人stm32版本还高的性能。
: ...................
--
FROM 117.132.11.*
原厂的应答没问题啊
本来就是有仲裁机制,不需要关心发送和接收状态
fifo有数据就行
【 在 spadger (void*) 的大作中提到: 】
: 标 题: Re: 一个GD32的CAN外设硬件bug
: 发信站: 水木社区 (Tue Jan 4 19:11:25 2022), 站内
:
: 这个真没有。
:
: 原厂人员说用FIFO来判断,然后我给他解释FIFO存储的单位是帧,接收的过程中数据还
: 没有进入FIFO,所以没法用FIFO来判断。然后他就说不支持你要的这个功能,无法判断
: CAN是否在接收数据。
:
: 通过这个事情,对GD原厂挺失望的,他们对待产品和技术的态度配不上目前的市场地位
: ,以后选型会多向其它厂家靠拢,雅特力和沁恒都比他们好得多。
:
: 以下是对话节选:
:
: GD:我找人测了下,默认是处于接收状态,如果是发送数据时,会处于发送状态,发的
: 时候会变 0,其他都是1
:
: ME:这种行为模式没有用处,因为实际需要的是硬件在接收数据才置1,而且其它厂家人家也是这么定义的
:
: GD:设计就是这样,那就只能别这么用
:
: ME:那应该如何判断CAN硬件在接收数据?有别的方法也行
:
: GD:没有办法,就我跟你说的判断帧数量
:
: ME:我说过了,没法根据帧判断,CAN总线在接受数据的时候,数据还没进FIFO,一帧接
: 收完了才会进FIFO
:
: GD:我知道你意思,那就无解啦,无法识别正在接收状态
:
: ME:好吧,只能尽量避免用这个芯片了,这个IP不知道是自研的还是外购的,STM32F10
: 3是没有这个问题的
:
: GD:自研
:
: ME:那别家应该没这个问题,你们可以对比下友商的产品
:
: GD:知道,设计人员对这个理解与别人有偏差,这就跟485接口类似
:
: ME:就是受了RS485的影响,485不支持多主,发送完数据要设置为接收,问题CAN是支持
: 多主的,没有这个问题,所以是芯片bug,不是特性
:
: GD:485没有仲裁机制,CAN有仲裁机制,现在这个特性你认为是BUG那就是,他不影响正
: 常使用,只是你刚好想要用的点有点特殊,无法满足你的应用场景
:
: ME:这个位相当于没有,是不是bug,你们要确认,涉及到新芯片是否会更新的问题。
:
: GD:我回你了啊,我们设计是我跟你说的那样,这个你能理解为他是bug,也能理解为他
: 为设计特性
:
: ME:我明白了,那就是以后新型号也不会更改。
:
:
:
: 【 在 ECUCoder (Engineer) 的大作中提到: 】
: : 如果原厂技术认为这不是BUG的话说明应该还有其它手段来辅助判断是否正在接收数据,否则也太无赖了。
:
:
: --
:
: ※ 修改:·spadger 于 Jan 4 19:16:28 2022 修改本文·[FROM: 222.90.95.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 222.90.95.*]
--
修改:spadger FROM 222.90.95.*
FROM 223.147.29.55
你不需要,不代表别人不需要。硬件既然设计这个功能,就是有这个需求。
别的不说,设计USBCAN卡,想做的好一点,这个位肯定就要用到。
【 在 ralfak (菜园和包子) 的大作中提到: 】
: 原厂的应答没问题啊
: 本来就是有仲裁机制,不需要关心发送和接收状态
: fifo有数据就行
: ...................
--
FROM 222.90.95.*
缺少较真的人,就是这个bug能存在接近9年的原因。
【 在 liu7894 (liupan) 的大作中提到: 】
: 你太较真了。
--
FROM 222.90.95.*
国产看来真不能用
【 在 spadger 的大作中提到: 】
: 测试过GD32E103,GD32F303,都有这个问题,其它型号有待确认,大概率GD32全系CAN外
: 设都有这个问题。
:
: CAN状态寄存器的bit9 RS表示接收状态,实际测试,CAN初始化退出睡眠模式以后RS位就
: 是1,进入初始化模式以后RS位清零,退出初始化模式以后
: ..................
发自「今日水木 on SM-G7810」
--
FROM 111.196.56.*
这就是芯片厂家不写勘误表的原因
【 在 woaiwoer 的大作中提到: 】
:
: 国产看来真不能用
: 【 在 spadger 的大作中提到: 】
: : 测试过GD32E103,GD32F303,都有这个问题,其它型号有待确认,大概率GD32全系CAN外
: : 设都有这个问题。
#发自zSMTH@Note 8 Pro暖手宝
--
FROM 222.90.95.*
请问你的 USB-CAN 适配器与上位机之间用的什么协议?
我找到了两组协议,实质上都是 串口 与 CAN 之间的协议:
1. Linux SLCAN:ASCII 表示
https://github.com/linux-can/can-misc/blob/master/docs/SLCAN-API.pdf
2. Atmel(Microchip) 的某个老协议:二进制表示
https://www.microchip.com/content/dam/mchp/documents/OTH/ApplicationNotes/ApplicationNotes/Atmel-32208-Users-Guide-for-USB-CAN-Demo-on-SAM4E-EK_Application-Note_AT02985.pdf
【 在 spadger (void*) 的大作中提到: 】
: 标 题: 一个GD32的CAN外设硬件bug
: 发信站: 水木社区 (Tue Jan 4 15:45:15 2022), 站内
:
: 测试过GD32E103,GD32F303,都有这个问题,其它型号有待确认,大概率GD32全系CAN外
: 设都有这个问题。
:
: CAN状态寄存器的bit9 RS表示接收状态,实际测试,CAN初始化退出睡眠模式以后RS位就
: 是1,进入初始化模式以后RS位清零,退出初始化模式以后RS=1
:
: 然后整个使用过程中这个RS位一直都是1,本来这个位是指示CAN硬件有没有在接收数据
: 的,现在完全失去了意义。
:
: CAN的一帧很长,需要上百个位,持续数百微秒,硬件接收完了完整一帧才会放入FIFO,
: 软件才能查询到,所以如果软件想知道硬件是否在接收数据,这个接收指示位就很重要
: ,如果这个位行为异常,软件通过RX管脚来判断是否CAN正在接收数据非常困难。
:
: 实测STM32和AT32的这个RS位行为是正常的,只有接收数据的时候才会置1,可以判断CAN的
: 接收状态。
:
: 联系过GD原厂,确认了这个问题,GD32的CAN外设无法通过硬件判断CAN外设是否在接收
: 数据,还有更坏的消息:原厂不认为这是bug,也不打算在新产品型号中更改。
:
: 好消息是他们的CAN IP是自研的,所以这个bug应该是GD32芯片独有的,不会影响其它厂
: 商的产品。
:
:
:
: --
:
: ※ 修改:·spadger 于 Jan 4 16:23:40 2022 修改本文·[FROM: 222.90.95.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 222.90.95.*]
--
修改:spadger FROM 222.90.95.*
FROM 111.196.243.*