关于RS485自动收发那些天坑

对于 RS485 ，大家应该都很熟悉了，在 modbus 协议中最常用。

但最近鱼鹰在调试 RS485 时遇到了不少问题。

首先，我们知道 RS485 属于半双工，同一时刻，只能收或者发。

像这种情况，我们需要一种机制控制它的收发，既可以是软件，也可以是硬件。

硬件
一般RS485芯片，都会提供一个控制引脚完成收发工作。

这个引脚可能由用户控制，也可能由芯片自动控制（一般比较贵），还有第三种可能是，设计一种自动收发的电路（应该没有超脱三界之外的吧）。

自动收发电路很多，有用三极管控制的，也有用缓冲器的（好像是吧），电路大致如下：

图来源于网络

因为 UART_TX 空闲电平为高，因此三极管导通，RE 接地，默认为发。

但是我还看过一种用 S8550 实现的电路，基极接地，三极管默认（空闲）不导通。

我不是电子工程师，无法判断两者电路的好坏，但我感觉默认不导通更好，功耗更低，另外即使引脚未配置（刚上电，肯定没那么快配置），那么也不会影响到总线上的其它节点通信，这个涉及到各个 485 节点上电时序问题。

这种电路好像因为三极管开关频率限制，无法做到很高频率（一般115200，市面上购买的模块基本都是类似这种电路）。

总之一句话，电路需要默认处于接收状态，保证不会干扰总线通信，否则只要其中一个节点默认状态不是接收，那么无法通信（因此，如果无法通信，不如查一查是否有节点状态不对，而不是首先怀疑芯片烧掉了）。

另外其中一个节点发送，其它节点必须保持接收，不要发送数据，否则数据肯定不是你想要的。

这种有频率限制，那是否有那种频率没限制，同时不需要买贵的 RS485 自动收发芯片的方案呢？

还真有，这要看你的 MCU 芯片本身是否支持了。

比如 IMX93，就可以实现（参考 IMX93RM.pdf，62.3.4）。

https://community.nxp.com/t5/i-MX-Processors/RS485-iMX93/m-p/1896764#M225674
官网论坛也有对此实现方法：https://community.nxp.com/t5/i-MX-Processors/RS485-iMX93/m-p/1896764#M225674
特别注意这里使用 RTS 引脚，而不是 CTS（其它芯片可能是用RTS）。

设备树配置如下（一般在arch/arm64/boot/dts/freescale/xxx 下，引脚描述文件

pinctrl_uart7: uart7grp {fsl,pins =
;};&lpuart7 { uart-has-rtscts; rts-gpios = <&gpio2 7 GPIO_ACTIVE_HIGH>; linux,rs485-enabled-at-boot-time;
// rs485 abilitata fin da subito al boot rs485-rts-active-high; rs485-rts-delay = <1 1>;};
最终的效果是：

来源官网论坛

当你发送数据时，DE 引脚会被芯片自动控制电平状态（默认为低电平），从而实现不需要由用户控制的自动收发功能，并且没有频率限制（但受串口自身频率限制）。

软件
说完硬件，再说软件。

其实很多软件或驱动是会带上 DE 引脚的控制（硬件挖坑，软件负责填坑），比如如果你的开发板不支持上面的功能，那大概率这颗芯片的Linux串口驱动会带上该功能。

还有开源软件 libmodbus 也考虑了这个引脚的控制。只是从效率和省心的角度，当然是自动收发爽了。

为了使用 485 的功能，不管 MCU 是否支持，都需要使能 485 模式，只是可能参数上需要进行调整。下面是硬件支持的配置：

#include #include #include #include #include int fd = open(“/dev/ttyLP7”, O_RDWR); if (fd < 0) { } struct serial_rs485 rs485conf = {0}; /* enable RS485 mode: / rs485conf.flags |= SER_RS485_ENABLED; / set logical level for RTS pin equal to 1 when sending: / rs485conf.flags |= SER_RS485_RTS_ON_SEND; / set logical level for RTS pin equal to 0 after sending: / rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); / Set delays for RTS if needed / rs485conf.delay_rts_before_send = 0; rs485conf.delay_rts_after_send = 0; / Enable full-duplex mode if supported / // rs485conf.flags |= SER_RS485_RX_DURING_TX; if (ioctl(fd, TIOCSRS485, &rs485conf) < 0) { / Error handling */ }
Python代码

port = serial.Serial(port=“/dev/ttyLP6”, baudrate=115200, timeout=2, write_timeout=2)port.rs485_mode = serial.rs485.RS485Settings()
shell 脚本，注意关闭回显：

stty -F /dev/ttyLP6 115200 cs8 -cstopb -parenb -echoecho “dddd” > /dev/ttyLP6
系统
从系统角度，我们也要知道一些基础知识。

比如，串口设备名称一般是 /dev/tty*。

通过命令 udevadm info 可以反查看该设备的硬件（设备树）信息：

udevadm info /dev/tty* |grep DEVPATH=/devices/platform
输出：

DEVPATH=/devices/platform/soc/107d001000.serial/tty/ttyAMA10
这样我们可以知道，ttyAMA10 设备是芯片上的 107d001000 串口。

另外，我们可以通过系统启动信息查看挂载的串口：

dmesg | grep -i fsl-lpuart
刚插入的设备不知道挂载在哪个/dev/tty* 目录下，同样可以通过上面的类似命令找到：

dmesg | grep -i tty
设备树节点查看路径：

/sys/firmware/devicetree/base/soc@xx/bus@xxx/serial@xxxx
脚本直接控制 IO：

gpioset gpiochip0 14=1 gpioset gpiochip0 14=0
这里面的 gpiochip0 和 14 也不是随便选的，并且 chip 的选择和我们常规的想法不同，具体可看 SDK 文档说明。

设备树编译：

dtc -I dts -O dtb -o /path/to/your-device-tree.dtbo /path/to/your-device-tree.dts
总之，要在 Linux 环境中调试好串口驱动，远比 MCU 环境更复杂，需要掌握知识也更多。

声明：本内容为作者独立观点，不代表电子星球立场。未经允许不得转载。授权事宜与稿件投诉，请联系：editor@netbroad.com