一个注释掉prink语句引发的modbus通讯问题

一个注释掉prink语句引发的modbus通讯问题
1）核心板是：正点原子stm32mp135d 核心板
2）底板自行开发，使用了一个GPIO口作为RS485的方向控制
3）驱动代码是stm32_usart.c
4）mosubs rtu模式，RS485有方向控制

问题现象

开发版测试中小伙伴反馈使用modbuspoll 连接开发版通讯不正常
modbus rtu方式。
通讯报错：

问题分析

接收的数据字节是不足的

中间定位过程比较曲折，就是反复修改测试。

发现和代码中printk语句相关，加上的时候通讯正常，去掉后就不正常了
通过之前经验和豆包也基本确定和延时时间有关。
具体代码如下（rs485方向切换前后）
根据豆包的建议延时10-50us。 就是这个反复测试都不行，改成延时1ms也不行。后续看printk打印时间耗时约5ms，测试5ms不行。迷惑不解，反复怀疑。

因为本身代码在中断中，这么延时本就不合理。此时测试使用的波特率是9600。

问题解决

后续想到一招通过不同延时时间看通讯回应收到的协议长度

发线延时时间还需要加长。 最终发现9600波特率下。延时12ms可以准确收到数据。

最总反复确认的延时时间：

回溯总结

【modbus rtu问题总结】这次modbus rtu问题比较怪异，回溯总结一下：
现象：modbus rtu通讯不正常。 原因是当时调试时加了printk驱动到代码。调试完成后，因为影响性能将调试语句去掉后打的包。打包之后图省事就没有再自测。恰恰就是因为去掉了貌似无用的调试语句，所以出问题了。
以下是最终定位原因：RS485方向控制线，切换到收时，要保证发送完成（延时），这里要printk起到了延时作用。发送的切换同理； 否则收发数据就会不全。而且波特率不一样，这个延时也不一样。这里反复测试才最终确定了问题和响应的延时时间。 最终解决。

作为码农任何一个字符的修改都需要测试验证和回溯，尤其是嵌入式领域。

修改位置供其他猿参考

1）RS485方向口初始化：

2）发送完成切换为接收的位置（此处代码位于中断，较长延时是不太合适的）

3）切换为发送的位置

4）读写函数

5）设备树参考

6）头文件