企业官网建设流程全解析

接手嵌入式Linux项目，十有八九逃不过跟Modbus打交道。尤其是工业现场那些传感器、变送器、PLC，别看协议老，胜在稳定可靠，一个串口就能把温度、湿度、压力、液位这些数据老老实实传回来。我最近刚做完一个基于ARM Linux主板的Modbus RTU采集项目，从串口配置到应用层读写，踩了不少坑也攒了不少经验，这篇就完整梳理一遍，给正在嵌入式Linux上折腾Modbus的朋友做个参考。

先说下项目背景，方便大家对号入座：主控是Cortex-A7内核的ARM Linux开发板，运行Debian文件系统，通过TTL电平串口外接一个RS485转接板，挂了三台Modbus RTU协议的传感器，分别是温湿度变送器、风速仪和光照度传感器。要求每分钟轮询一次，把数据解析后通过MQTT上报到云端。这篇文章就围绕这里面最核心的串口配置和RTU读写来展开。

注意：文中所有代码均基于Linux C实现，如果你用的是Python或者Go，原理完全一样，串口参数、帧格式、CRC校验这些底层逻辑是通用的，换语言只是换了个API壳子。

1. 整体思路拆解：先把Modbus RTU的底细摸清楚

1.1 Modbus RTU到底是什么，跟其他模式有啥区别

Modbus协议分好几种，最常见的就是RTU和TCP。TCP走以太网，RTU走串口（RS232/RS485）。RTU模式下，数据是以二进制字节流的形式在串口上传输的，一帧报文包含地址码、功能码、数据区和CRC校验，格式非常紧凑。

这里有个容易犯迷糊的地方：Modbus RTU和Modbus ASCII。ASCII模式是把每个字节拆成两个ASCII字符传输，报文长度翻倍，效率低一截，现在工业现场已经很少用了，默认都是RTU。RTU报文每个字节直接发原始十六进制，比如要发一个0x03，串口上就是实实在在的一个字节0x03，而不是字符"03"。

既然做嵌入式Linux开发，本质上就是把串口当成一个文件来读写。Linux下一切皆文件，串口设备节点通常是/dev/ttyS0、/dev/ttyUSB0这类，打开文件、配置参数、读写数据，跟操作普通文件没有本质区别，只是中间多了个termios结构体的配置过程。

1.2 为什么选RS485而不是RS232

工业传感器长距离传输首选RS485，原因很直接：RS232只能点对点，传个十几米就衰减得厉害；RS485是差分信号，抗干扰能力强，理论传输距离能到1200米，而且支持挂多个设备（一条总线上可以并联32个节点），正好符合多传感器采集的场景。

但RS485有个特点必须注意：它是半双工通信。也就是说，同一时刻要么发要么收，不能同时进行。这就引出了嵌入式Linux开发中那个著名的坑——方向切换。RS485转接板上通常有个DE/RE引脚，控制收发方向，高电平发送、低电平接收。在裸机或RTOS下这个好办，直接拉GPIO就行；到了Linux下就麻烦了，因为应用层和驱动层中间隔着一层，你没法在发送前瞬间把GPIO拉高。

解决思路有两条：一是在设备树里配置串口的RTS引脚作为方向控制（很多RS485转接板出厂就把RTS和DE/RE连好了），Linux内核的串口驱动支持RTS在发送时自动拉高，发完自动拉低，这个叫硬件自动方向控制；二是应用层通过ioctl手动控制GPIO，但时序上很难做到精确，容易丢数据。实测下来，最好用的是第一种，后面会详细讲怎么配置。

1.3 设备地址和功能码，这两张表背下来

做Modbus开发，设备地址和功能码是绕不开的两个基础概念。Modbus RTU总线上每个从站必须有一个唯一的地址，范围是1到247（0是广播地址，一般不用）。主机向从站发起请求时，报文第一个字节就是这个地址；从站应答时，返回的报文第一个字节也是自己的地址，这样主机就知道是谁回的消息。

功能码决定了你要对从站做什么操作，最常用的三张表我直接列出来：

传感器数据采集基本用功能码0x03和0x04就够用。具体用哪个，得看传感器手册说明。比如我手头的温湿度变送器，温度存在保持寄存器地址0x0000，湿度存在0x0001，用0x03读；风速仪则是输入寄存器映射，用0x04读。这里没有统一标准，每个厂家的寄存器映射表都不一样，拿到传感器第一件事就是找手册，查清楚地址和数据类型。

2. 串口配置实操：stty和termios的完整姿势

2.1 串口参数怎么定，传感器的波特率敢不敢信

Modbus RTU的串口参数看起来就那几个：波特率、数据位、停止位、校验位。但实际项目里我吃过大亏：某个风速仪传感器，手册上写着默认波特率9600，结果实际拿回来一测，发出去的请求石沉大海，用逻辑分析仪一抓波形才发现，这货实际工作在19200。厂家出厂配置和手册不一致，这种事儿在工业设备里真不少见。

所以第一步不是写代码，而是确认参数。几个办法：看传感器拨码开关的位置（很多设备上有波特率拨码）、用厂家的上位机软件读取当前配置、或者干脆用串口助手一个个波特率试。我个人建议，直接从设备外壳标签或出厂配置单上确认，最保险。

确定好参数后，在Linux下最快验证串口通不通的办法，就是直接敲stty命令：

# 配置串口参数，假设设备节点是/dev/ttyS0 stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb raw

这条命令的含义是：波特率9600，8位数据位（cs8），1位停止位（-cstopb），无校验（-parenb），原始模式（raw）。stty配置完，可以用stty -F /dev/ttyS0 -a查看当前参数，确认配置生效。

提示:stty命令里-号开头表示关闭该选项，不带-表示开启。比如-cstopb就是关掉2位停止位，用1位；-parenb是关闭校验位。这个方向搞反了，串口配置分分钟出错。

2.2 拿到传感器手册，先把寄存器表读懂

配置串口之前，先花十分钟把手里的传感器手册读完。每个Modbus传感器的寄存器映射表，基本长这样：

这个表就是整个开发的核心依据，后续所有代码都是围着它转的。特别注意两点：一是数据格式，是整数还是浮点？是原码还是补码？是直接读出来就是真实值，还是需要除以10/100/1000？二是字节序，Modbus RTU报文里数据是高位在前（大端），但某些传感器厂家会搞出小端来，这就要在解析的时候自己调整。

我遇到过最坑的案例：某个液位传感器，寄存器里存的是32位浮点，占了两个寄存器地址。结果厂家文档里没写明是大端还是小端，我用默认的大端解析出来数值完全不对，最后用modbus poll工具反复比对才试出来是反的。所以这里强烈建议：拿到传感器先不用写代码，用现成的Modbus调试工具把数据读出来，确认数据格式和寄存器映射没问题了，再进开发阶段。

2.3 termios结构体逐项配置，这些坑必须注意

如果不想每次都用命令行，要在C代码里配置串口，核心就是termios结构体。下面这段代码是标准的配置模板，每一项我都加了注释：

#include <termios.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdio.h> int uart_config(int fd, int baudrate) { struct termios opt; // tcgetattr把当前串口参数读出来，在原有基础上修改，避免漏配置 if (tcgetattr(fd, &opt) != 0) { perror("tcgetattr"); return -1; } // 配置波特率，一些平台不支持非标准波特率，9600和115200最稳 cfsetispeed(&opt, baudrate); cfsetospeed(&opt, baudrate); // 设置为原始模式，不能让内核做任何输入输出处理 cfmakeraw(&opt); // 禁用流控，Modbus RTU不用硬件或软件流控 opt.c_cflag &= ~CRTSCTS; // 禁用硬件流控 opt.c_iflag &= ~(IXON | IXOFF | IXANY); // 禁用软件流控 // 8数据位，无校验，1停止位 opt.c_cflag &= ~CSIZE; opt.c_cflag |= CS8; opt.c_cflag &= ~PARENB; opt.c_cflag &= ~CSTOPB; // 使能接收，CLOCAL表示忽略调制解调器控制线 opt.c_cflag |= (CLOCAL | CREAD); // 设置读取超时和最小读取字节数，这个非常关键，下边详细讲 opt.c_cc[VTIME] = 50; // 单位是0.1秒，这里就是5秒超时 opt.c_cc[VMIN] = 0; // 不要求最小读取字节数 // 配置生效，TCSAFLUSH表示等所有输出完成后刷新输入缓冲区 tcsetattr(fd, TCSAFLUSH, &opt); // 清空缓冲区，避免历史数据干扰 tcflush(fd, TCIOFLUSH); return 0; }

这里重点说两个容易被忽视的细节：

第一，cfmakeraw这个函数把终端设置成"裸设备"模式，禁止了所有输入输出处理——包括回车换行转换、信号生成、回显等。做串口通信一定要用这个函数，否则内核会把某些特殊字符偷偷处理掉，比如0x0D被转换成0x0A，你发的Modbus帧就已经不是原始帧了。

第二，VTIME和VMIN这两个参数共同决定了read函数的阻塞行为。VMIN=0表示不等到数据就返回，配合VTIME超时时间；VMIN=1表示至少等到1个字节才返回。对于Modbus RTU这种请求-响应模式，我推荐VMIN=0、VTIME=50，这样read会最多阻塞5秒（50×0.1秒），如果没有数据就返回0，方便应用层做超时判断。如果改成VMIN=1、VTIME=0，read会一直阻塞等待数据，应用层就没法做超时控制了。

2.4 拿到设备节点，权限问题先解决

嵌入式Linux上，串口权限是个很常见的坑。开发板上/dev/ttyS0默认属于root用户（通常属于dialout组），如果你用普通用户跑程序，open("/dev/ttyS0", O_RDWR | O_NOCTTY)会直接返回-1，errno是Permission denied。

解决办法有几个：

# 方法一：临时给设备节点加权限 chmod 666 /dev/ttyS0 # 方法二：把当前用户加入dialout组 usermod -a -G dialout $USER # 方法三：用udev规则设置开机自动授权 # 添加 /etc/udev/rules.d/99-serial.rules 文件，内容： # KERNEL=="ttyS0", MODE="0666"

我用得最多的是方法三，一劳永逸。嵌入式开发板的udev规则写好后，重启就生效，不用每次开机都手动chmod。

另外一个容易掉进去的坑：O_NOCTTY这个标志。打开串口设备时，如果不用这个标志，程序收到Ctrl+C之类的终端信号时，串口会跟着响应，导致程序莫名其妙地退出。标准写法就是open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY)，O_NDELAY表示打开时不阻塞（即使串口线没接好也能正常打开）。

3. Modbus RTU核心实现:CRC校验、报文组帧和解析

3.1 CRC16校验从原理到代码，一条条算给你看

Modbus RTU的报文结尾是两个字节的CRC16校验码，这个校验码的计算是整个协议里最基础也最关键的部分。它的算法是：一个16位的寄存器初始化为0xFFFF，把报文中每个字节依次和寄存器低位异或，然后右移8次，每次右移后如果最低位是1，再与0xA001异或。这个过程说直白点就是"逐字节处理+循环移位+多项式异或"。

CRC在Modbus RTU里是低位在前传输的。计算得到16位CRC值后，先发低字节，再发高字节。比如算出来CRC是0x1D9C，报文中就要先发0x9C再发0x1D。这个字节序颠倒是刚入坑时最容易写错的地方，就算CRC算对了，字节序反了照样被从站拒绝。

下面给一个通用的查表法实现，比按位运算快很多，单片机和嵌入式Linux都能跑：

#include <stdint.h> // 预生成的CRC16-Modbus查找表 static uint16_t crc_table[256]; void crc16_init(void) { for (uint16_t i = 0; i < 256; i++) { uint16_t crc = i; for (int j = 0; j < 8; j++) { if (crc & 0x0001) crc = (crc >> 1) ^ 0xA001; else crc >>= 1; } crc_table[i] = crc; } } // 计算CRC16，返回值为CRC校验值 uint16_t modbus_crc16(uint8_t *buffer, uint16_t length) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < length; i++) { crc = (crc >> 8) ^ crc_table[(crc ^ buffer[i]) & 0xFF]; } return crc; }

查表法的原理是把每个可能的字节异或结果预先算好存进数组，运行时直接用索引查表，省去了逐位循环的8次运算，在嵌入式环境里能省不少CPU时间。对RTU应用来说，帧长也就8个字节左右，按位算也不会慢到哪去，但养成用查表法的习惯没坏处。

3.2 报文组帧：请求帧和响应帧格式拆开看

Modbus RTU请求帧的格式固定如下：

拿我手头的风速仪举例，地址是0x01，要读地址0x0000的输入寄存器，组帧如下：01 04 00 00 00 01 CRC_LOW CRC_HIGH。这个报文一共8个字节，写入串口后等待从站响应。

从站正常响应的帧格式：

比如风速仪返回的温度数据是十进制100，换算成16进制是0x0064，响应帧就是01 04 02 00 64 CRC_LOW CRC_HIGH。如果读到的寄存器值需要工程换算（比如除以10），这一步放在解析阶段处理。

如果发生异常（比如从站地址不对、寄存器地址超范围），响应帧会是这样：

异常码的含义需要查Modbus协议规范，0x01是非法功能、0x02是非法地址、0x03是非法数据值、0x04是从站设备故障。

3.3 串口读写实操：一次完整的传感器数据读取过程

组好帧之后，写串口发出去，然后读串口等响应。这里有两个容易出错的地方：一是发送后马上read会读到空，因为从站处理数据需要时间；二是received数据里可能夹杂着前一次通信的残留数据。所以发送前后一定要做tcflush(fd, TCIOFLUSH)清空缓冲区，读完也要根据帧长度判断是否收完整了。

下面给一个完整的函数，读取指定从站的多个寄存器：

// 读取Modbus RTU从站数据，功能码支持0x03/0x04 // 返回读取到的字节数，失败返回-1 int modbus_read_registers(int fd, uint8_t slave_addr, uint8_t func_code, uint16_t start_addr, uint16_t reg_count, uint8_t *rx_buf, int rx_buf_size) { uint8_t tx_buf[8]; int tx_len = 0; uint16_t crc; int ret; // 组帧 tx_buf[tx_len++] = slave_addr; tx_buf[tx_len++] = func_code; tx_buf[tx_len++] = (uint8_t)(start_addr >> 8); tx_buf[tx_len++] = (uint8_t)(start_addr & 0xFF); tx_buf[tx_len++] = (uint8_t)(reg_count >> 8); tx_buf[tx_len++] = (uint8_t)(reg_count & 0xFF); crc = modbus_crc16(tx_buf, tx_len); tx_buf[tx_len++] = (uint8_t)(crc & 0xFF); tx_buf[tx_len++] = (uint8_t)((crc >> 8) & 0xFF); // 发送前清空缓冲，避免残留影响 tcflush(fd, TCIOFLUSH); ret = write(fd, tx_buf, tx_len); if (ret != tx_len) { perror("write"); return -1; } // 注意：写完后需要等待从站响应，可以在这里加一点延时 usleep(50000); // 50ms，根据从站响应速度调整 // 读响应，设置超时5秒 ret = read(fd, rx_buf, rx_buf_size); if (ret < 0) { perror("read"); return -1; } if (ret < 5) { printf("响应帧太短：%d字节\n", ret); return -1; } // 校验响应帧地址和功能码是否匹配 if (rx_buf[0] != slave_addr) { printf("地址不匹配：期望0x%02X，实际0x%02X\n", slave_addr, rx_buf[0]); return -1; } if ((rx_buf[1] & 0x7F) != func_code) { // &0x7F是为了去除异常标志位 printf("功能码异常：0x%02X\n", rx_buf[1]); return -1; } // 校验CRC（rx_buf中最后两个字节是CRC） crc = modbus_crc16(rx_buf, ret - 2); uint16_t recv_crc = (uint16_t)(rx_buf[ret-2] | (rx_buf[ret-1] << 8)); if (crc != recv_crc) { printf("CRC校验失败\r\n"); return -1; } return ret; }

这个函数里有个参数需要单独强调：usleep(50000)这个延时。有些从站处理速度慢，你发完请求马上read，它可能还没准备好响应，读到的是空数据。延时时间根据从站响应速度调整，一般50ms到200ms都行。轮询多个传感器时，这个延时也会影响整体周期，需要平衡。

3.4 RS485方向切换：Linux下的三种做法

如果用的是RS485转接板，方向控制是绕不开的问题。根据硬件设计不同，Linux下有三种应对方案：

方案一：设备树配置RTS自动方向控制（推荐）

如果你的RS485转接板把DE/RE接到了串口的RTS引脚上，可以在设备树里配置串口为RS485模式。以全志、NXP等常见平台为例，设备树节点里加上：

&uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; rs485-rts-active-high; // RTS高电平使能发送 linux,rs485-enabled-at-boot-time; status = "okay"; };

配置好之后，内核串口驱动会在每次write后自动控制RTS引脚电平，应用层不需要做任何额外操作。这个方案最省心，稳定性最好，我强烈推荐优先使用。

方案二：应用层操作GPIO控制方向

如果硬件上方向控制引脚接的是独立GPIO，应用层可以在发送前把GPIO拉高（进入发送模式），发完再拉低。但这个方案有个隐患：write返回后数据可能还在串口FIFO里没发完，你立刻拉低方向引脚，最后几个字节就会被切断。解决的办法是发送后加延时，或者用tcdrain函数等待数据排空：

// 拉高GPIO使能发送 gpio_set_value(dir_gpio, 1); write(fd, tx_buf, tx_len); tcdrain(fd); // 等待所有数据发送完毕，重要！ usleep(100); // 再给硬件一点点余量，一般几位微秒到几百微秒 // 拉低GPIO使能接收 gpio_set_value(dir_gpio, 0);

方案三：用ioctl操作TIOCMBIS/TIOCMBIC控制RTS

如果不改设备树，代码里也能直接控制RTS：

int flag; ioctl(fd, TIOCMGET, &flag); // 获取当前DTR/RTS状态 flag |= TIOCM_RTS; // RTS置高 ioctl(fd, TIOCMSET, &flag); // 发送 write(fd, tx_buf, tx_len); tcdrain(fd); // 发送完把RTS拉低 flag &= ~TIOCM_RTS; ioctl(fd, TIOCMSET, &flag);

这个方法胜在不用改设备树，但跟GPIO方案一样，存在发送排空问题。实测中，如果系统负载高，数据从应用层到串口FIFO再到真正发出的延迟会变大，那100微秒的延时不一定够，数据被截断的几率就上来了。能用方案一，就别贪方便用方案三。

3.5 数据解析：从原始寄存器值到真实工程值

拿到从站响应后，最后一步就是解析数据。这一步容易出现千奇百怪的问题。拿温湿度传感器举例，响应数据是0x01FC，那你读到的寄存值就是0x01FC = 508。如果手册上写"温度值=寄存器值/10"，那真实温度就是50.8摄氏度。如果寄存器里存的是32位浮点，就要两个寄存器拼在一起再解析。

解析代码没有太多技术含量，但有个常见的坑：数据类型的符号位。有些传感器温度带负值，寄存器里存的是有符号数，直接按uint16_t读出来会得到一个很大的数。这种情况要先判断最高位是否为1，如果为1则要转成负数：

int16_t raw = (int16_t)reg_value; // 强制转换为有符号数 float real_temp = (float)raw / 10.0f; // 温度/10得到真实值

另外，某些传感器支持两字节数据的高低位颠倒（小端模式），这种只能对照手册或者实测确认。我的建议是，拿到真实传感器后先用Modbus调试工具手动发几帧，把返回数据跟实际物理量对应起来，验证字节序和比例系数，再写死到代码里，避免后期返工。

4. 调试工具与排查技巧：modbus poll/slave一类的上位机利器

4.1 为什么强烈建议先调试再写代码

很多新手拿到传感器就一头扎进C代码里，写完了才发现读出来的数据不对，这时候排查起来既费时间又难定位——到底是串口配置问题，还是组帧问题，还是解析问题，分不清楚。

我的习惯是：拿到传感器先不上代码，直接在上位机上用Modbus调试工具把数据读通。Windows下常见的工具有Modbus Poll（作为主机去读从站）、Modbus Slave（模拟从站），这类工具能自动生成CRC、自动识别帧格式，人工肉眼就能看到寄存器数据的变化，对起验证来非常方便。

用Modbus Poll操作步骤如下：

1. 打开软件，菜单栏选Setup -> Read/Write Definition。
2. 从站ID填传感器的地址（比如1），功能码选03或04。
3. 起始地址填0，数量填要读的寄存器个数（比如2个）。
4. 串口设置里选对应COM口、波特率、数据位8、停止位1、无校验。
5. 点确定后，工具会周期性自动轮询，窗口里直接显示每个寄存器的值。

如果工具能正常读到数据，说明传感器通信链路没问题，接下来就是纯写代码的活；如果工具也读不到，那问题基本出在硬件连接、串口参数或传感器配置上，跟你的代码无关。这个排查思路能省下好几个小时的调试时间。

4.2 Linux下没有现成poll工具，自己写个轮询脚本也不难

如果开发环境在服务器上，没有Windows桌面工具，也可以写个简单的Python脚本模拟Modbus主机，用modbus_tk或pymodbus库快速验证。比如用pymodbus，几十行就能搞定：

#!/usr/bin/env python3 import serial from pymodbus.client import ModbusSerialClient client = ModbusSerialClient( method='rtu', port='/dev/ttyS0', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=2 ) if client.connect(): # 读保持寄存器，从站地址1，起始地址0，读2个寄存器 result = client.read_holding_registers(0, 2, slave=1) if not result.isError(): print("温度原始值: %d" % result.registers[0]) print("湿度原始值: %d" % result.registers[1]) else: print("读取失败: ", result) client.close() else: print("串口连接失败")

这个脚本相当于一个简化版的Modbus Poll，验证串口链路够用了。写Python脚本的时候需要注意，pymodbus库的版本不同，API差异还挺大，下面这个示例是基于较新版本写的，旧版本可能不需要slave参数而是unit。

4.3 排查问题三板斧：硬件、参数、代码

做Modbus RTU调试，问题无外乎三大类：硬件层、参数层、代码层。我的排查顺序就是这样：

第一板斧查硬件。用万用表量RS485的A/B线电压，静态时A对B的电压应该在2V到6V之间（空闲态）；把设备的串口发送端接到逻辑分析仪或示波器上，按下发送按钮，观察是否有波形。如果连波形都没有，那就是硬件连接或驱动的问题。

第二板斧查参数。确认波特率、数据位、停止位、校验位四项是否完全一致，尤其注意有些传感器标称"8E1"（8位数据，偶校验，1位停止位），你配成"N81"就通讯不上，报文完全被忽略。我校验位这个坑踩过不止一次，面板上根本看不出区别，但就是不通。

第三板斧查代码。串口配置有没有加raw模式？CRC算对没有？高低字节是不是反着发了？延时够不够？响应超时设置的合不合理？这些问题挨个排查。建议在关键节点加打印，把发出的字节流和收到的字节流都打出来，用肉眼看二进制数据和期望是不是一致。很多问题在打印面前一目了然。

5. 常见问题速查：直接照着排查就行

我把这些年做Modbus RTU遇到的高频问题整理成一张表，方便大家对号入座：

除了表格里的内容，还有一个实战里经常偷袭成功的问题：总线末端没接终端电阻。RS485总线两端应各接一个120欧姆的终端电阻，如果线缆长度超过几十米还没接，信号反射会导致数据错误。短距离（几米内）不接也能跑，但稳定性大打折扣。工程上建议默认接上，省心。

6. 优化思路与经验补充：除了通，还要稳

6.1 超时机制和重试策略，别让卡死拖垮整个系统

Modbus RTU通信是典型的请求-响应模式，如果从站掉线或线路故障，read可能一直等下去。因此在应用层必须设计超时重试机制。我的做法是：每次通信设置5秒超时，连续3次失败判定该从站离线，通过MQTT上报离线告警，同时不再阻塞后续设备的轮询。

#define MODBUS_TIMEOUT_COUNT 3 int fail_count = 0; while (1) { // 读取所有传感器 int ret = modbus_read_registers(fd, slave_addr, func, start_addr, reg_count, rx_buf, sizeof(rx_buf)); if (ret > 0) { fail_count = 0; // 解析数据并上报 } else { fail_count++; if (fail_count >= MODBUS_TIMEOUT_COUNT) { // 上报传感器离线 printf("从站%d离线\n", slave_addr); fail_count = 0; } } sleep(60); // 每分钟轮询一次 }

注意轮询多个从站时的逻辑：不要因为一个从站超时，就卡住后面所有从站的采集。把每个从站的数据采集独立成一个函数，逐个调用，每个都有独立的超时控制。这样即使某个从站出问题，其他传感器还能正常工作。

6.2 用libmodbus库替换裸串口，值不值得

我上面的代码都是基于裸串口手写组帧、CRC、解析，这套逻辑在所有Linux设备上通用，没有额外依赖。但如果项目里Modbus从站特别多，或者涉及大量写入操作，直接用libmodbus这个开源库能省掉很多重复代码，它还天然支持RTU和TCP切换。

libmodbus的基本用法：

#include <modbus/modbus.h> modbus_t *ctx; uint16_t regs[10]; // 初始化RTU模式，指定串口设备、波特率、校验位等 ctx = modbus_new_rtu("/dev/ttyS0", 9600, 'N', 8, 1); if (ctx == NULL) { perror("modbus_new_rtu"); return -1; } modbus_set_slave(ctx, 1); // 设置从站地址 // 读取保持寄存器，起始地址0，读2个寄存器 int rc = modbus_read_registers(ctx, 0, 2, regs); if (rc != 2) { printf("读取失败: %s\n", modbus_strerror(errno)); } modbus_close(ctx); modbus_free(ctx);

库最大的优势是在modbus_read_registers内部已经处理好了报文组帧、CRC校验、超时重试等逻辑，而且对RS485方向控制的适配也做得比较完善（通过modbus_rtu_set_serial_mode可以启用RTS方向控制）。但它也有体积和移植性的代价，低端嵌入式设备交叉编译时可能遇见依赖问题。

我的建议是：如果项目只有一两个从站，手写完全够用，代码可控性好，出了问题也容易定位；如果从站数量多、功能码复杂度高、后续还要扩展TCP，那直接上libmodbus，把时间花在业务逻辑上更划算。

提示:用libmodbus时，串口打开后会默认设置raw模式，但依赖内核的串口驱动和RS485方向控制。如果你的主板平台比较小众，设备树没配好RS485模式，还是要用上面说的TIOCMBIS方式手动控制方向，库和底层驱动都不是万能的。

7. 项目结束后的几点体会

代码写完、数据通了只是第一步，真正考验人的是长期运行稳定性。我这次项目上线后大概跑了两周，遇到过两次偶发性通信失败，排查到最后是RS485总线上两个从站的上电时序问题——一个风速仪初始化速度慢，主机上电后立刻去读它，它还没就绪就放弃响应了。最后在应用层加了上电后延时5秒再开始轮询，问题就消失了。

还有一个参数值得提一下：中断间隔时间。Modbus RTU规定帧与帧之间要有至少3.5个字符时间的静默间隔，从站拿这个间隔来识别一帧数据的结束。如果应用层连续发送两帧数据时间间隔不足，从站可能把两帧混在一起解析，导致CRC失败或者数据错乱。在Linux下，因为系统调度和串口缓冲的原因，连续write两帧数据可能间隔极短，所以轮询多个传感器时，建议在两帧之间主动加上几毫秒延时（具体时间根据波特率算：9600波特率下，1个字符约1ms，3.5个字符约3.6ms；115200下约0.3ms），稳妥起见我习惯加5ms以上。

最后关于Modbus RTU的学习路径，我最真实的建议是：先拿一块RS485转USB模块，接一个真实的传感器，从Modbus Poll开始读数据，建立对协议的整体感知；然后再看协议文档，了解帧格式、功能码、CRC这些底层细节；最后才是写代码。很多人一上来就啃协议栈源码，结果被各种细节劝退。实际项目里，8个字节的请求帧背熟了，Modbus开发已经能应付九成场景了。先把这九成做好，剩下的遇到一个查一个，踩坑多了自然就熟了。