体育直播网站开发数据源获取推广品牌的方法
背景
前段时间接到一个项目，要求用主控用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(!(lsr&TIOCSER_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控制管脚的电平，只看到了两者是反向的，但是并没有放大去看最后一段电平的细节。导致遗漏了解决问题的线索。
- 一切问题发生都是有原因的。偶现问题并不好排查，但是我们可以尝试制作偶现问题发生的条件，看有没有可能成为必现问题。如果不能必现，可尝试通过脚本去不断运行在问题发生的场景，使其出现的概率提升。