初调D211的CAN通讯，最初是很正常的，可实现不同波特率下的数据正常收发。之后的测试卡的一塌糊涂
1- 发送卡壳；
2- CANH，CANL线缆短路，断路卡壳；
3- 设备波特率与总线波特率不一致时候卡壳。
卡壳有些是不可恢复的只能重新开机，有些是断开总线连接后可以恢复。
优化后的CAN通讯设计要点：
1.一定要把aic_can_hal.c文件中的hal_log_err()语句注释掉。主要是因为can通讯时有些error会被频繁触发，如果不关闭，所有线程都会被憋死，因为这属于中断响应。
2. can初始化时要选择自测模式而不是normal模式
hal_can_ioctl(&can, CAN_IOCTL_SET_MODE, (void *)CAN_SELFTEST_MODE);
按官方所说，自测模式属于发送不管，发送是否生效，用户可自己通过别的方式加以判断。
很多情况下数据本就是发不出去的比如线缆断路，短路，并不需要sdk函数本身来保证发送是否成功，否则CAN也会出现卡壳。
3. 发送安全机制：
. 设置一tx_done变量，在收发中断函数中tx_done=1。
. 发送每一帧报文前先判断tx_done是否为1.如果=1直接发送，如果=0说明之前的报文未发送完毕。等待10ms且每隔1ms判断一次，等待过程注意让出线程。
. 如果累计10ms后tx_done依然为0，说明总线异常，可能是D211设备异常，也可能是线缆异常。软件重启CAN外设来保证D211设备是正常的。
. 重启CAN外设后，即直接发送不再判断，如果tx_done=1属于正常发送；否则属于重启后发送。发送后tx_done=0.
这样的话，对于每次发送任务，不管总线有无异常，总会执行所需要的发送任务。如果属于CAN外设驱动问题，在软件重启CAN外设后自然会恢复。如果属于线缆问题，线缆正常后也会第一时间恢复发送。
经过这样一番倒腾后，D211的can运行还是挺稳的。完美。。
最近编辑记录 tomas (2024-09-09 17:34:58)
离线
使用d133也是遇到类似问题，最开始的版本，can总线上已经有其他设备在收发信息，d133上电，有几率卡死，好像是接收错误。后来sdk更新了，这个问题不再出现了，但是如果总线上其他设备上电晚，d133先上电，没有其他can接收设备，则d133 can发送卡死，还恢复不了...
离线
1.在1.0.6版本中，hal_log_err已修改，收发出错时不再显示打印信息
2.发送数据时，设置了超时时间，如果总线异常导致数据发不出去，超时后会退出，不会卡死
3.can总线上已经有其他设备在收发信息，d133上电卡死的问题，是因为RTT CAN框架在设置波特率之前就打开了中断，波特率不匹配导致，这个问题已修复。
4.d133先上电，没有其他can接收设备，则d133 can发送卡死，这个通过问题2已解决，也是RTT CAN框架的bug
离线
CAN总线比较特别，有仲裁机制，也要求错误节点不得影响整个总线。
最好自己来实现错误处理。
离线
@ArtInChip
那就太好了，稍后试试1.0.6。
离线