早在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芯片置为接收。还正在移位的数据就嗝屁了。
因此
一定要搞清楚选用的中断是发送完成中断还是缓存器空的中断；
在发送中断中，不能立即切为接收，应当延时一段时间，我现在的做法是不管三七二十一，在发送中断中，如果判断为最后一个byte，则延时1.7ms将RS485设置为接收；
不应该启动定时器进行延时，定时器资源很宝贵，应该在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个字符之后，立即应答。
来源：头条号-IT自动化交流
原文链接：https://www.toutiao.com/i6894161680406675981/
1.做备忘|GD32 Arm MCU物联网开发者线上课程不容错过！
免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。