1.引言
Modbus是工业领域重要的协议，物理层有常见的RS485双绞线和TCP，所以又常说Modbus 485开发和Modbus TCP开发。
前者就是串口通信，比较简单。后者涉及到网络协议，复杂度高出好几个层次。
但是如果有稳定的TCP通信做铺垫，这两种Modbus的区别就不大了，都是数据包的解析而已，能共用大部分代码。
本文不讨论Modbus协议如何读写一个Register或Coil之类的，这些东西看看文档或者网上搜下博客教程就知道了。
本文目标是讨论如何写一个稳定的Modbus通信驱动，由于Modbus TCP对Modbus的操作除了有个特殊的7字节包头和无CRC外，其他部分和Modbus 485没有区别，因此本文对Modbus TCP同样有参考意义。
2. RS485通信
部分应用场景下并没有使用Modbus协议，而是简单的串口通信，然后加上和校验等检查，传输层使用RS485，这类应用可以归为RS485通信的范畴。
其实个人感觉，都做到这个份上，还不如直接用Modbus来做，复杂度高不出多少，好处却有很多。比如可以借助Modbus大量的流行测试工具做系统测试。可以把系统做成一个标准品，也利于客户使用和测试。另外有现成的通用协议，总比自己定的协议稳定度高。
比如我曾见到过的几个公司的产品：
这是一个电机控制器，使用RS485通信，但本质就是串口通信，加上了头0x4A，和结束符0D,0A，以及和校验。
这是一家BMS产商的说明书，RS485通信，和上面一样，就是基于RS485的串口通信而已。
这类驱动程序，需要从稳定性和易读性来考虑，如果稳定性较差会造成系统控制故障，如果易读性差就会造成难以维护，这些控制指令之间差别很小，如果一个一个单独写命令，非常容易出错。对应举措如下：
1）避免每个指令写一部分代码，需要统一处理，比如校验函数，发送函数，接收函数等。
通信协议已知，从中可以知道通信的实际数据长度（不包含包头包尾和校验的部分），所以可以控制读写多少个字节，并且可以知道什么时候启动校验，那些数据参与校验计算。
2）为指令建立指令列表，这样后来需要添加功能，就可以直接把指令字加入列表即可。
3）适当抽象。为每个指令的动作写回调函数，这样就可以在应用层，用一句简单的回调函数指针直接操作具体的动作函数，而不是应用逻辑层操作具体的驱动层面的接口。
4）超时，必须有超时机制。通信失败怎么处理？通信了一般线断了怎么处理？不能让系统死等后面的几个字节发过来。
5）新手和一些小公司经常会不注意的出现一个问题——不关闭通信端口。
如果通信都是由你发起的，那么无论此次通信是完成还是超时或失败，都应该关闭通信端口。
因为从合理的逻辑上来说，此刻之后都不应该再有数据过来打扰系统的工作。
网友评论
