原创当RS485隔离遇见Freemodbus，你碰到问题了吗？

 2021-4-20 13:07  2520 30 3 分类: MCU/ 嵌入式

摘要：基于RS485物理接口的Modbus总线在工业控制中广泛应用。Freemodbus是一个免费的实用的协议栈，孔丙火（微信公众号：孔丙火）用它实现了一个从站。串口收发信号和RS485芯片的收发使能信号采用光耦进行了隔离，在测试过程发现了偶尔出现TimeOut的问题，经过查找及分析，发现是光耦信号延时导致的，给出了解决方案，并对问题进行了详细分析。

关键词：RS485 隔离 Freemodbus 光耦时序

1.问题来源

工业应用中，在进行RS485电路设计的时候，为了确保电气安全和抗干扰性，经常会做信号隔离，光耦隔离是常用的一种形式。Modbus协议是现场总线协议中比较常见的一种，其设计和使用简单，运行可靠，在可编程控制器、仪器仪表、传感器中使用广泛，其中，基于RS485物理接口的Modbus总线使用最多。Modbus是主从式的通信结构，一个系统中仅有一个主站，其他为从站。Freemodbus是一个免费的协议栈，仅支持从站。Freemodbus有专门的机构在维护，比较成熟，相对于自己编写的协议代码，运行更稳定，是开发者在研发时的常用选项。

近来，孔丙火（微信公众号：孔丙火）在设计一个基于Modbus-RTU接口的信号采集站，作为从站，把采集到的信号传输给PLC等主站设备。单片机采用STM32F103C8T6，RS485芯片：SP485EEN，接收和发送的隔离采用光耦PC410，485收发使能信号的隔离采用光耦EL357NB。RS485部分的原理图如图1所示。

图1

程序设计中，采用Freemodbus协议栈实现Modbus-RTU协议，串口速率为115200bps，数据位8位，停止位1位，无校验。

在使用Modbus主站软件（Modbus Poll）进行调试的过程中，孔丙火（微信公众号：孔丙火）发现通信过程中会出现TimeOut的错误，有以下几个特点：

a）并不是每一帧都会出错，但会不定时地出现；

b）主站询从站的频率越高，出错的几率越低，主站每30ms询一帧数据的时候基本不出错，但每500ms或1000ms询一次的时候，就会比较明显地出错。

2.查找过程

由于硬件电路是之前使用过的，刚开始并没有考虑是电路的问题。首先是从软件开始查找的。由于能够正常的回复数据，只是偶尔出错，因此软件的整体流程应该是通的，只是某个代码的细节有问题，孔丙火（微信公众号：孔丙火）把代码整个重新捋了一遍，也没有发现明显的问题。

后来，开始逐步排查，先把RS485部分的电路短接掉，用USB-TTL转换器直接连接单片机的串口收发管脚，进行收发数据的测试，结果一切都正常，无论主站的询问数据周期是多少，都不会出错。于是开始怀疑跟485相关的代码。

搞过485电路的朋友都知道，485电路仅仅是实现一个电平转换，另外由于485是半双工，需要外加一个收发使能控制，485芯片实现TTL电平与差分电平的转换。涉及到代码，就是多一个管脚，用来控制收发使能。虽然这一步没有测试出问题，但在反复试的过程中，倒是有一点意外收获，孔丙火（微信公众号：孔丙火）分享一下。使能485芯片的发送语句，必须在使能串口发送中断（发送为空中断）之前，否则通信是无法成功的。原因分析：发送为空中断在使能后，是立即进入中断的，使能485发送的代码无法执行，发送没有使能，但已开始发送数据，这种情况下，发送是肯定不会成功的。这个点给我了启发，是不是发送的时序有问题，导致发送失败呢？

于是开始分析485的收发电路，由于信号是隔离的，最有可能出现问题的地方是光耦，就从光耦开始查起。开始查阅PC410和EL357NB的数据手册，开始是担心光耦前后的限流电阻跟光耦的电流传输比是不是不匹配，导致光耦导通不充分，后经分析电路参数没有问题。然后开始分析光耦的时序，经过光耦隔离的信号肯定会延时，延时的不同步会不会导致问题呢？果然，PC410和EL357NB的传输延时还是有差别的，PC410的传输延时在几十ns，而EL357NB的传输延时在1us左右，程序代码做了如下修改：在使能485发送管脚后，延时一段时间后（1us左右，无需太精确），再使能串口的发送中断，经测试，TimeOut的错误了。

3.结论及分析

（1）问题就出在光耦的信号传输延时上，在485电路的设计之初，单片机的串口收发脚采用高速光耦进行隔离，收发使能脚由于不需要频繁切换，采用一般光耦即可。正是由于这个设计，在使能485收发和使能发送中断同时执行的时候，在单片机的串口发送部分（从发送缓存区到硬件管脚，单片机内部完成，无需用户代码干预）处理比较快的时候，就会导致485还没有使能发送状态，单片机已开始向485芯片发送数据，就会导致发送出错，Modbus主站软件（Modbus Poll）收到的是不完整的错误的帧，就是看到的TimeOut错误。但在单片机的串口发送部分处理的不那么快的时候，就不会出现这个错误，这是错误不定时出现的原因。

（2）使能485发送管脚后的延时，不能采用HAL_Delay()函数，Freemodbus协议栈的收发使能在vMBPortSerialEnable()，由于在调此函数之前已经禁掉了中断，而HAL_Delay()函数是基于系统时钟中断定时的，因此不能使用。由于此处不需要精确地定时，只要能满足两种光耦延时的时间差即可，可以使用空语句进行定时，大体算一下时间即可。孔丙火（微信公众号：孔丙火）的代码如图2所示。

图2

（3）在最初的问题中，为什么主站询的快的时候错误少，反而询的慢的时候错误多？这个问题没有完全思考清楚，但孔丙火（微信公众号：孔丙火）有一些心得。元器件都会有一些寄生电容，在电平转换的时候，可以认为电容要先进行充电或放电，因此会有一个斜坡，在主站询的快的时候，电平转换快，在电平改变的时候，电容在上一次的过程中还没有完全放电或充电完毕，这个时候进行反方向的改变需要的时候就会短，可以对冲两种光耦时间差的影响。不知道我这种说法大家是否可以理解，更深层次或者更确切的原因，也欢迎高手指点，或者大家行进讨论。

文章在公众号（孔丙火）同步推出，欢迎查看更多系列文章。

单片机、ARM、现场总线、PLC、嵌入式软硬件的设计经验分享，秉承“点点滴滴皆智慧”的理念，以实际项目为单元阐述知识点，一起分享，共同交流。