正在摧毁协议处理器_自己编写MODBUS协议代码所踩过的坑

早在2008年左右，我就在设计的产品中使用Modbus协议与其它设备进行通信。

记得第一款是智能马达保护器，其作为Modbus从，与Modbus主设备进行通信。

这么多年来，一直都没有使用开源的Modbus协议代码，

而在在不断在自己编写的Modbus协议代码上进行优化，发现问题并解决。

自己写的代码用起来比较得心应用可以针对不同的平台进行优化，将处理器的性能发挥到极致。

在此期间，也踩过一些坑，现在做一些总结：

串口数据接收完之后，到通过IO口重新使用接收的时间间隔。

发送完成之后切换接收的延时时间

如上图所示的Td，按照Modbus协议的规定，接收完数据之后，必须要间隔3.5个字符对应的时间才能发送。

如果是9600bps的波特率，8位数据位，1位起始位，1位停止位，无奇偶校验位，则1个字符为10个 bit，对应1.04ms，3.5个字符对应3.5ms。

考虑到总线上的电容对传输延时的影响，建议在发送完数据1.7个字符的时间之后再使能接收。

对于这个时间，可能会犯一些错误，比如：

• 在发送完最后一个字节的发送完成中断中，直接将控制IO口使能485芯片的接收。殊不知，由于电容导致的信号延时，串口数据还没有完全发送到总线，485芯片就被置为接收状态，导致最后几个bit的数据误码；
• 没有正确理解发送完成中断以及发送缓存器空中断之间的差别；
• 发送完成中断一般是指串口数据已经从移位寄存器从端口送出。但是并不说明已经被送到RS485总线。从MCU的IO口到RS485总线还需要考虑隔离光耦、电容、RS485芯片的延时；
• 发送缓存器空中断是指腾出了缓存的位置，可以缓存数据。此时，上一个数据可能还在移位寄存器中被紧张有序地按位移出到IO口，此时把RS485芯片置为接收。还正在移位的数据就嗝屁了。

---

因此，

1. 一定要搞清楚选用的中断是发送完成中断还是缓存器空的中断；
2. 在发送中断中，不能立即切为接收，应当延时一段时间，我现在的做法是不管三七二十一，在发送中断中，如果判断为最后一个byte，则延时1.7ms将RS485设置为接收；
3. 不应该启动定时器进行延时，定时器资源很宝贵，应该在100us左右的定时器中断中，通过变量计数来进行1.7ms左右的延时；

MODBUS从设备多少时间会应答

Modbus是问答式的通信，主设备发送完数据之后，从设备会做出响应。

按照Modbus协议规定，从设备3.5个字符时间之后做出响应都是合法的。

不同的传感器应答响应时间各不相同。

有些差的传感器可能到几十ms才响应，有些3.5ms左右就立即响应了。

有些甚至没有按照Modbus的协议出牌，还没有到3.5ms左右的时间就响应了。

这就要求主设备在将RS485接收使能之后，立即进行接收状态。

如果是用串口中断进行接收，则应该注意在主程序中是否有关中断的操作，关中断的操作是否影响接收。

每一个串口数据之间的时间间隔

Ｍodbus根据数据之间的时间间隔来判断一桢消息的结束，需要保证一桢消息内的前后数据之间的间隔不超过3.5个字符。

而数据一般在发送中断中发送，有些人为了保证数据完整性，保证数据访问的互斥，很喜欢关中断来保护现场。

这种做法一不小心就会使发送两个数据的间隔超过3.5个字符。

特别是当波特率比较高时，更容易出现这种情况。

比如，当波特率为38400时，3.5 个字符仅为850us左右，在发送串口数据的时间内，中断关闭850us，Modbus通信就嗝屁了。

如果MCU支持DMA，建议使用DMA+定时器进行数据收发。

作为Modbus从设备时，收到数据之后，多少时间应答

按照Modbus协议要求，3.5个字符之后就可以应答。

有些Ｍodbus主设备可以是为了保证实时性，对这个应答时间要求比较苛刻。

比如我们前一段时间跟西门子的工控屏对接时，就碰到过这样的问题，

总线的波特率为19200bps，我们的设备在收到西门子的命令之后大概在5ms左右做出了应答。

但是西门子工控屏却判为错误。

之后，我们将应答时间缩短到2ms左右，与西门子的通信才变得正常(这个问题接下来还会再深入研究，可能还有其它原因)。

建议在3.5个字符之后，立即应答。