原厂的应答没问题啊
本来就是有仲裁机制，不需要关心发送和接收状态
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