linux 485调试——由单片机开发过渡到linux开发走过的弯路记录

1）项目初期

（1）由于未使用过linux上的485，对其的工作模式与普通232的区别不甚了解。主要担心半双工的工作模式控制，涉及驱动问题。

（2）遂采用开发板的例程，进行简单测试。实际上当时并没有仔细测试。发现有专门的485的例程，说明存在使用的可能性。

（3）考虑到485属于大众化的东西，应该有现成的、成熟的解决方案。

（4）在硬件设计时，直接采用引脚控制。与开发板的默认引脚不一样。

2）硬件完成制板后的测试

（1）先是通过修改设备树文件，进行测试。前期就已经发现，发送使能引脚置高后不能置低。测试用例与开发板例程一样，以为是驱动问题。期间边熟悉设备树，边熟悉驱动流程和IO，边熟悉下载问题花费了大量的时间。

（2）暂时不能解决，后发现开发板现象与其一样。转入到手动配置IO，由于简单修改输出无效，甚至死机。后采用IO导出的方式予以处理。以至于不影响后续的应用使用。

3）具体应用时的问题

（1）采用导出后的IO进行操作，年前发现始终不能回读成功。年后测试发现，使用脚本设置IO的时间长达20ms。后发现可以采用读写文件的方式（借鉴modbus的485处理）。

（2）遂再次研究485驱动问题。两方面解决，一是IO设置的时间能够减少，这个存在调度不确定性的根本问题。而是修改驱动，能够底层处理。

（3）在分析过程中，锁定485驱动和485例程使用不对两大方面。

（4）在测试用例方面，后经使用发现，通过禁止SER_RS485_ENABLED可以拉低引脚。认为应该发送后禁止。不过在之后的使用中发现，禁止时间大有讲究，太长影响接收，太短影响发送，先经过计算实现当前功能。

（5）在101，读取噪音传感器等都是正常的情况下，开始进行透传的功能是现场测试。发现数据包丢失的问题。接收四十多个自己发现只收到最后几个字节。重新考虑485驱动问题。

4）进一步解决发现

（1）手动延时无法灵活适用各种场合，linux系统调度的不确定性，决定了延时的不准确性，出问题是个概率事件，此法只能应急。

（2）现阶段若不能解决驱动问题，后续在硬件设计时采用硬件流控制，等驱动弄好后再改过来。

5）当前方案

（1）重新考虑驱动框架时候通过仔细阅读英文“ RS485 SERIAL COMMUNICATIONS”文档发现，里面清楚写着各种使用方式，涉及用户空间和内核空间。尤其在用户空间发现，SER_RS485_RTS_ON_SEND，SER_RS485_RTS_AFTER_SEND，delay_rts_before_send，delay_rts_before_send配置参数。说的很详细。之前阅读过测文档，由于恐惧英文，并没有仔细阅读，依赖例程。

（2）后查阅驱动关键词的rs485-gpio-txen ， sport->txen_gpio，SER_RS485_RTS_AFTER_SEND，imx.c 文件把能够证明（1）条的正确性。

（3）修改用例测试，示波器捕捉正常，串口接收正常。但是发送前的延时10ms，并没有达到预期，说明理解还需加深。

（4）只要使能就会置高发送，由于长时间至高，导致接收不正常——暂时解决办法，上电及发送一串字符再使用。

在波特率为115200是，回传电脑接收的时候，前面会多一个0.波特率低的话没有这个问题。

 

6）小结与教训

（1）依赖例程，没能充分消化吸收参数。——针对不熟悉的东西，不能有惯性思维，应该找到根本出处，仔细阅读，减少采坑。仔细阅读的时间花费远小于采坑的时间。

（2）针对例程应该仔细测试。