德州市建设工程质量监督站网站,紧急大通知请记住新域名,app软件推广文案的范文,开发小程序多少报价背景
前段时间接到一个项目#xff0c;要求用主控用485和MCU通信。将代码调试好之后#xff0c;验证没问题就发给测试了。测试测的也没问题。
但是#xff0c;到设备量产时#xff0c;发现有几台设备功能异常。将设备拿回来排查#xff0c;发现是485通信有问题#xff…背景
前段时间接到一个项目要求用主控用485和MCU通信。将代码调试好之后验证没问题就发给测试了。测试测的也没问题。
但是到设备量产时发现有几台设备功能异常。将设备拿回来排查发现是485通信有问题偶现通信失败。
排查思路
复现问题
发给测试之前功能都验证了很多次但是并没有发现通信失败的问题。设备拿到手第一时间就尝试复现通信失败的问题也没有成功。
于是写了一个脚本不断的和MCU通信看什么情况下会失败。
果然在通信若干次后发现日志异常主控接收数据出现了错乱。
接着继续跑脚本想看下什么情况下会失败。但是每次通信异常的时机都是随机的没有规律。
观察了下错乱的数据和正确的数据做了对比也没有什么发现。
清空buf
接收的数据出现了异常第一个想到的是是不是接收buffer不干净有其他数据干扰呢
尝试在接收buffer和发送buffer之前手动清空下buf。确保不会有其它数据干扰。
重新跑脚本和MCU 通信但是仍会失败。
收发时序
光看是什么办法了。上示波器看下主控和MCU的时序的。
正常来讲主控和MCU的485控制管脚应该是正好反向的电平。即主控485控制管脚高电平发送的时候MCU的485控制管脚应该是低电平。
问题复现时对比了管脚的电平确实是反向的没有问题。这也排除了收发时序对不上的问题。
(绿色的是MCU的485控制管脚黄色的是主控的485控制管脚) 收发数据正确
小示波器没有解码的功能只能找硬件来量下主控的RX和MCU的TX。确认下到底是主控接收的不对还是MCU发的不对。 显然是主控接收的数据有问题了。
仔细观察会发现绿色波形这里有个半高电平覆盖了黄色的低电平。导致第一帧出错了后面的数据也都错乱了。 又重新复现了几次发现每次失败时都是这种现象。那为什么这里会有个半高电平呢
确认问题
和硬件对着原理图经过一番讨论硬件给到的结论是485芯片的RX管脚接了3.3V的上拉只有当485芯片的使能管脚拉高时RX才会有3.3V的半高电平出现。硬件怀疑是485控制管脚和MCU的时序没对上。
不过我之前也量了主控和MCU的485控制管脚的电平看了是对的难道是我看错了
接着又重新量了主控和MCU的485控制管脚发现确实有问题具体如下图。两者有1.5ms的高电平是重合的这或许就是问题所在 又重新复现了几次问题发现每次通信失败时都会有一段高电平是重合的。
到这里基本也就明确了问题原因主控和MCU的485控制管脚时序没对上
寻找问题根因
从波形找出了问题所在回归串口编程继续看下代码吧。把重点放在了时序切换的代码上。
代码里面在切换485管脚时有这样两段代码。 以下只是伪代码 代码一
setdir(SEND) //切换为发送状态
write() //发送数据
tcdrain(fd) //判断是否写完
setdir(READ) //切换为读状态代码二
do
{ioctl(fd,TIOCSERGETLSR,lsr) //判断发送buffer是否写完
}while(!(lsrTIOCSER_TEMT)) //如果TX为空返回TIOCSER_TEMT这两段代码都是和485管脚切换相关的根据不同情况走不同逻辑出问题的代码走的是代码一片段。
tcdrain 和 TIOCSERGETLSR
那这两段代码有什么区别呢
tcdrain是应用层控制tty的一个函数调用 tcdrain()函数后会使得应用程序阻塞 直到串口输出缓冲区中的数据全部发送完毕为止。
ioctl(fd,TIOCSERGETLSR,lsr)是获取tty 设备的线路状态寄存器( LSR )的值。
这两段代码最大区别就是延时不同
tcdrain()是等待fd所引用的串口设备数据传输完毕。虽然在物理上数据已传输完毕时但Linux对硬件实时性高对于用户请求的实时性较低。所以操作系统会有延时导致tcdrain()多停留几ms从而导致数据发送完后485管脚的控制方向不能及时切换。
如果对接的485设备接收和应答的延迟小于tcdrain()的延时那方向切换不及时将导致数据接收丢失。这就是问题根因所在。
那为什么操作系统会有延时呢
这个得说说Linux工作队列相关机制对于硬件操作Linux处理的很及时但是对于数据Linux可能将其交给系统的下半部的内核线程去处理这就可能导致用户的系统调用存在一定的延时而485通信对时间要求又很严格1ms的延时就会导致数据错乱。
总结
严谨细致。在问题发生时我也去量过主控和和MCU 485控制管脚的电平只看到了两者是反向的但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。一切问题发生都是有原因的。偶现问题并不好排查但是我们可以尝试制作偶现问题发生的条件看有没有可能成为必现问题。如果不能必现可尝试通过脚本去不断运行在问题发生的场景使其出现的概率提升。
