测试过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 FROM 222.90.95.*
FROM 222.90.95.*

这个真没有。

原厂人员说用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 FROM 222.90.95.*
FROM 222.90.95.*

从对话看确实是BUG，但他们有不改的底气也能理解。
一般CAN驱动报文接收函数不用这个位来判断接收是否完成，通过中断标志位来判断更加直接有效。
这个位一般只在“查询当前是否正在接收的函数”里面用到，而这个函数并不常用，去跟厂家反馈这个BUG的人应该很少，所以就造成现在这种局面了。

【 在 spadger 的大作中提到: 】
: 这个真没有。
: 原厂人员说用FIFO来判断，然后我给他解释FIFO存储的单位是帧，接收的过程中数据还
: 没有进入FIFO，所以没法用FIFO来判断。然后他就说不支持你要的这个功能，无法判断
: ...................
--
FROM 122.238.143.*

FAE太拽了
【 在 spadger (void*) 的大作中提到: 】
: 这个真没有。
: 原厂人员说用FIFO来判断，然后我给他解释FIFO存储的单位是帧，接收的过程中数据还
: 没有进入FIFO，所以没法用FIFO来判断。然后他就说不支持你要的这个功能，无法判断
: ...................
--
FROM 49.7.60.*

对，就是USBCAN卡。目标是周立功的品质，TB开源的价格。

问题是客户反馈的，在极端的CAN负载率下数据会出错。负载轻一点就没事。

查了很久定位到一个usb的硬件bug上，然后想通过判断can总线状态来规避，然后又踩到
can的硬件bug。

周立功的USBCAN卡做得确实不错，不过毕竟老产品时间已经很久了，卖的也太贵，用新
芯片可以做得更好。我这个性能比它老产品强一些，他的新产品没对比过，体积比它小
很多。tb的开源的不行的，代码我看过，完成度差得远。

国内周立功是认真做技术的。


【 在 ECUCoder (Engineer) 的大作中提到: 】
: 你是在搞USB-CAN卡么？我把国内外的USB-CAN卡全测试了一遍，从Vector两三万的到淘宝开源一百块的一共十几种，性能差别巨大，最后选了周立功最新款的，性能一流，价格适中。
: 淘宝开源一百块的或者三四百块那些，跟周立功的老产品性能差不多或者差一些。
: 国外那几款贵的，比周立功的老产品性能好，但是比不上周立功的新产品。
: ...................
--
修改:spadger FROM 222.90.95.*
FROM 222.90.95.*