请问你的 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.*