这些CAN外设，都是参考的STM32的CAN外设，寄存器接口都是一样的。

GD显然对这个位的理解出了问题。

软件中判断CAN是否在发送是很容易做到的，方法很多。由于硬件接收在软件处理之前，
软件要判断CAN硬件是否在接收数据，只能通过硬件提供的这个位来进行。我希望软件判
断到真正CAN总线空闲以后再发送数据，没有这个位还真做不到。起因是因为USB的一个
硬件bug，想通过CAN判断到总线空闲以后再发送来规避，结果CAN也有硬件bug

对于已经大规模出货的芯片这个确实没办法，但是芯片改版，或者新设计的芯片，CAN的
这个问题要不要修正？就是个问题。


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