×
问题出现的背景
需要写一个新的电机的驱动，使用can通讯，驱动比较简单，很快就写好了。自己单独测试一个电机的时候没有问题，正反转测什么的都很正常。本以为事情会很顺利，但是在测两个电机的时候，却发现很严重的问题，经常左电机不装或者是右电机不转。
问题的解决步骤
方案一：
1. 遇到这种问题通常都是加上一个延时，觉得可能就是发的太快了，时许上可能有问题，但是我们的系统是一个实时的系统延时的时间不能太长。
2. 经过测试发现加延时可能较小出现这种问题的概率，但是不能解决这个问题，最终车子还是无法正常运行，没办法这个方案不行。
分析：
既然加延时不行的话，只能去找为什么电机不装。使用can转usb将数据抓出来之后，发现电机不转是由于，有帧丢失。每个电机发数据需要2帧数据，两个电机也就是4帧数据。但是只能抓到3帧数据。丢失了一帧数据。那么这个可能是由于can的发送邮箱不够，导致的丢帧
背景知识：
发送
3 个发送邮箱
发送报文的优先级特性可软件配置
记录发送 SOF 时刻的时间戳
接收
3 级深度的2个接收 FIFO
14 个位宽可变的过滤器组 － 由整个 CAN 共享
标识符列表
FIFO 溢出处理方式可配置
记录接收 SOF 时刻的时间戳
因此接下来，我分析就是要检查can邮箱空闲的的寄存器个数，看是否是因为连续发送4帧数据的时候，can空闲的邮箱不够用了。
因此我在每次发送之前，检查这个寄存器的26,27,28位，统计可使用的邮箱个数。
方案二：
发送之前统计可使用的邮箱个数，只有在有邮箱的时候，我们才会发送新的数据。
结果：
结果出乎意料，每次发送的时候显示的邮箱个数，都是3个，也就是说根本就没有出现邮箱不够用的情况 。方案二不可行。
继续分析：
发现跑的时候，这个位经常会被置1，不是因为邮箱不够丢失数据，而是由于仲裁丢失数据。
进一步验证：
发现这个寄存器每次回复的都是邮箱0，因此跟家判断不是邮箱不够的问题。每50ms发4帧数据是完全够用的。
方案三：
因为发送数据的id，比从机回复的id要大因此，发送时可能会因为，id较大，同时抢占can的时候会导致数据帧仲裁丢失。
因此开启can的自动重发功能。
使用hal库的话也就是一句话：
g_sCAN_Handler[dwDevice].Init.NART = DISABLE;//开启自动重发
结果问题，完美解决
『本文转载自网络,版权归原作者所有,如有侵权请联系删除』
热门文章
更多
用PIC16F627制作的可调倒计时提醒器
APP下载
登录
