嵌入式 Linux 板子上做 Modbus RTU 开发听起来就是“打开串口、发报文、收报文”三件事可真到了现场调试你会发现卡壳的地方全在细节里设备节点选错、termios 参数没配对、485 方向切换闪了一下、CRC 校验不过、从机偶发无响应……这些才是消耗时间的重头戏。这篇文章我会从串口配置、RTU 报文解析、读写程序的工程化写法再到调试工具和经典 485 故障排查完整走一遍实际项目的处理思路给准备在嵌入式 Linux 上接 Modbus 传感器的朋友一份可以直接抄作业的参考。1. 嵌入式Linux下做Modbus RTU和单片机开发差在哪1.1 两种开发思路的差异之前用 STM32 做从机很多人会移植 FreeModbus v1.6在标准库或者 HAL 库基础上挂一个串口中断再写一个定时器用来判断帧间隔。那时候的每一帧数据、每一个字节基本都在自己的掌控范围内从机收到请求后要在中断里快速组织应答报文。这是一种典型的前后台裸机思路实时性靠中断保证。到了嵌入式 Linux 平台情况完全变了。系统里跑的可能是 Linux 内核上层有进程、线程、调度器。你不可能再去注册一个串口中断然后在自己驱动的回调里处理 Modbus 报文这么做既没效率也不好维护。更常规、更工程化的做法是在用户态直接打开串口设备文件配置好串口参数然后通过读写文件描述符的方式收发 Modbus RTU 帧。协议栈方面如果只是作为主机去采集传感器数据甚至可以考虑不依赖现成协议栈自己封装一个精简的 RTU 主站或者直接用libmodbus这种被广泛使用的库。这两种思路的差异本质上是“我该关注到什么粒度”的差异。在单片机上你关心的是一个字节一个字节怎么收发在嵌入式 Linux 上你更关心的是系统怎么帮你管理串口资源、缓冲区、超时时间以及你的应用逻辑该怎么组织。1.2 为什么说 Linux 上更适合直接用户态读写Linux 下的串口被抽象成 tty 设备对应用层来说就是一个普通文件。你打开它配置好属性然后 read、write操作方式和文件 I/O 几乎一样。这意味着你根本不需要关心底层 UART 控制器怎么初始化、中断怎么触发、FIFO 怎么调度内核的串口驱动框架已经把这些处理好了。更重要的是Linux 的串口驱动自带内核级缓冲区。即使你的应用程序在某一段时间内因为进程调度被延迟了已经到达串口的字节也不会立刻丢失它们会待在内核缓冲区里等你来读。这对于 Modbus RTU 这种一次最多一两百字节的报文来说容错空间相当大。另外Linux 上调试也方便。你可以写一个很小的测试程序纯粹收发字节看原始数据也可以用现成的调试工具模拟主站、模拟从站快速定位问题在协议层还是物理层。这种“用工具辅助验证”的开发模式在单片机裸机环境下没那么顺手。1.3 付出代价实时性和确定性当然Linux 不是万能的。它有一个必须正视的问题实时性不如裸机。进程可能被更高优先级的任务抢占内核也有调度延迟所以如果你严格按照 RTU 协议的帧间隔来判断一帧报文是否结束就要格外注意时间精度。好在 RTU 帧间隔通常是 3.5 个字符时间对于 9600 波特率大概是 3.9ms对于 115200 波特率只有 0.3ms 左右。在 Linux 用户态如果内核抢占延迟比较高单纯靠程序卡时间判断帧结束是有风险的。我自己的处理原则是如果波特率不高9600、19200直接靠 read 阻塞配合超时就行问题不大如果是 115200 以上或者现场环境干扰比较大那就考虑把帧间隔检测放到内核驱动层或者用一个实时线程加pthread_setschedparam提高调度优先级来处理。最稳妥的方式还是不要让 Linux 调度的不确定性直接影响你的 RTU 帧解析判断。2. 串口配置设备节点、termios参数与实际踩坑点2.1 设备节点到底选哪个嵌入式 Linux 板子上串口对应的设备节点五花八门。最常见的是这么几类设备节点典型场景/dev/ttyS0、/dev/ttyS1标准 16550 串口很多 ARM 板的调试串口在这里/dev/ttyUSB0USB 转串口芯片CH340、CP2102、FT232 等/dev/ttyAMA0Raspberry Pi树莓派等平台的 PL011 串口/dev/ttymxc0NXP i.MX 系列处理器的串口/dev/ttyO0TI 老款平台AM335x 等的串口第一件要做的事就是确认你这块板子外接传感器的那路串口到底是哪一个设备节点。别想当然地把调试串口和业务串口搞混。调试串口通常会被 getty 或者系统日志占用你打开它去写 Modbus 数据很有可能会被系统当成终端输入处理报文发不出去、收到的数据还是乱码甚至整个调试终端都直接卡死。确认设备节点后还要确认它当前是否被其他程序占用。可以用lsof /dev/ttyUSB0或者fuser /dev/ttyUSB0检查如果输出为空说明没有被占用可以放心打开。这一步看起来简单实际项目里不少人在这里耽误过时间。2.2 权限问题与环境准备当前用户去打开串口经常会碰到 Permission denied。原因很简单串口设备默认属于 root 或 dialout 组。你有两个解决办法把当前用户加入 dialout 组然后重新登录终端sudo usermod -a -G dialout $USER临时修改设备节点权限适合快速验证sudo chmod 666 /dev/ttyUSB0如果是产品部署阶段不建议用 chmod 666也不建议在启动脚本里 chmod 777最好用 udev 规则把设备和用户组绑定保证每次插拔后权限一致。例如新建/etc/udev/rules.d/99-usb-serial.rules写入KERNELttyUSB[0-9]*, GROUPdialout, MODE0660然后执行udevadm control --reload-rules udevadm trigger。2.3 termios 参数配置一个都不能错Modbus RTU 最常见的串口参数组合是波特率 9600也有 19200、115200、8 个数据位、无校验位、1 个停止位也就是 8N1。很多国产传感器默认就是这个配置。也有一部分设备默认是偶校验8E1这个必须从传感器数据手册确认清楚。下面是一段我常用的 C 语言串口配置代码摘取核心部分#include termios.h #include fcntl.h #include unistd.h #include string.h int uart_set_attr(int fd, int baudrate, int data_bit, int parity, int stop_bit) { struct termios opt; if (tcgetattr(fd, opt) ! 0) { return -1; } // 以原始模式工作避免终端行规则干扰数据 cfmakeraw(opt); // 设置输入输出波特率 speed_t speed B9600; switch (baudrate) { case 9600: speed B9600; break; case 19200: speed B19200; break; case 115200: speed B115200; break; default: return -1; } cfsetispeed(opt, speed); cfsetospeed(opt, speed); // 数据位 opt.c_cflag ~CSIZE; switch (data_bit) { case 8: opt.c_cflag | CS8; break; case 7: opt.c_cflag | CS7; break; default: return -1; } // 校验位 switch (parity) { case N: // 无校验 opt.c_cflag ~PARENB; opt.c_iflag ~INPCK; break; case E: // 偶校验 opt.c_cflag | PARENB; opt.c_cflag ~PARODD; opt.c_iflag | INPCK; break; case O: // 奇校验 opt.c_cflag | PARENB; opt.c_cflag | PARODD; opt.c_iflag | INPCK; break; default: return -1; } // 停止位 if (stop_bit 1) { opt.c_cflag ~CSTOPB; } else if (stop_bit 2) { opt.c_cflag | CSTOPB; } else { return -1; } // 启用接收关闭硬件流控 opt.c_cflag | (CLOCAL | CREAD); opt.c_cflag ~CRTSCTS; // 关闭软件流控 opt.c_iflag ~(IXON | IXOFF | IXANY); // 非规范模式VTIME0VMIN1即等着读一个字节 opt.c_cc[VTIME] 0; opt.c_cc[VMIN] 1; // 清空缓冲再写入新配置 tcflush(fd, TCIOFLUSH); if (tcsetattr(fd, TCSANOW, opt) ! 0) { return -1; } return 0; }这段配置里有几个细节值得解释一下cfmakeraw(opt)这一步很关键。它会把串口设置为非规范模式禁用回显、禁用信号字符、禁用行编辑防止串口驱动把收到的字节当成终端控制字符处理。如果不设置 raw 模式Modbus 数据里某些字节比如 0x03、0x11、0x13可能被终端驱动特殊处理导致帧数据被吞掉或改写。opt.c_cflag | (CLOCAL | CREAD)是必须的CLOCAL忽略调制解调器控制线CREAD使能接收。有人忘了加CLOCAL程序打开串口后一旦 DCD 电平变化串口可能会被自动关闭这在嵌入式板子上挺坑的。VMIN1, VTIME0表示阻塞读read 至少等到一个字节才返回。这个配置对于 Modbus 主站来说相对简单但后面在超时处理部分我会讲为什么这个组合不是最优的。提示如果你的设备是 RS485 接口这还只是完成了 UART 通道配置485 方向切换是另一件大事后面单独说。2.4 打开串口的正确方式打开串口时建议使用O_RDWR | O_NOCTTY | O_NDELAYint fd open(/dev/ttyUSB0, O_RDWR | O_NOCTTY | O_NDELAY); if (fd 0) { perror(open serial port failed); return -1; }几个标志位的含义O_NOCTTY告诉系统这个串口不要成为控制终端否则你按 CtrlC 之类的信号可能直接发给这个串口应用O_NDELAY使得 open 本身不阻塞DCD 信号对 open 的影响被忽略。打开之后建议再调用一次fcntl(fd, F_SETFL, 0)把串口切回阻塞模式方便后续阻塞读。3. RTU报文与CRC16读一个传感器寄存器到底发生了什么3.1 一条读取请求报文的结构Modbus RTU 的每个请求帧格式很简单本质上就是一串字节。用功能码0x03读保持寄存器举例主机发给从机的请求一般长这样字节位置内容示例值0从机地址0x011功能码0x032-3起始寄存器地址大端0x00004-5寄存器数量大端0x00026-7CRC16低字节在前0x84 0x0A注意 CRC 是低字节在前。假设从机地址是0x01功能码是0x03从寄存器地址0x0000开始连读 2 个寄存器那么这一帧完整的字节序列是01 03 00 00 00 02 C4 0B对不少做工程出身的朋友来说这里的“寄存器地址”经常和“寄存器编号”搞混。Modbus 协议文档里说的地址有 0-based 和 1-based 两种说法例如有些传感器上标注“保持寄存器地址是 40001”那对应到协议报文里的地址其实是0x0000。所以在写代码前务必把传感器手册上的寄存器编号和你在报文中填的地址两者的换算关系搞清楚否则你会读到一堆看似合法、实际完全用不上的数据。3.2 CRC16-Modbus 的实现RTU 模式下的校验算法是 CRC16-IBM/MODBUS多项式是 0x8005初始值是 0xFFFF输入输出都需要做位反转处理。一个很常见的实现是用查表法查表法比逐位计算快得多在嵌入式 Linux 上更是毫无压力static const uint16_t crc_table[256] { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0281, 0xC240, // ... 完整 256 项查找表 }; uint16_t modbus_crc16(const uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { uint8_t index (crc ^ data[i]) 0xFF; crc (crc 8) ^ crc_table[index]; } return crc; }发送的时候把crc拆成两个字节低字节在前uint16_t crc modbus_crc16(frame, frame_len_without_crc); frame[frame_len_without_crc] crc 0xFF; frame[frame_len_without_crc 1] (crc 8) 0xFF;接收的时候可以把收到的整个帧包括 CRC 两个字节一起重新计算 CRC如果结果为 0说明校验通过。这个判断方式很优雅也方便写通用校验函数。注意我见过不少新手把 CRC 发反了发成了高字节在前导致从机一直不应答。如果碰到从机毫无响应的情况先用逻辑分析仪或者串口调试工具看原始字节确认 CRC 字节顺序运输对。3.3 应答帧解析与数据装配接着上面的例子从机正常应答的帧长和请求有关。读 2 个寄存器应答帧大概是字节位置内容示例值0从机地址0x011功能码0x032后续字节数N0x043-4第 1 个寄存器值大端0x02 0x2B5-6第 2 个寄存器值大端0x00 0x647-8CRC16低字节在前0x...寄存器值默认是大端高字节在前。很多传感器会把 16 位整数的符号位放在最高位解析的时候要用int16_t而不是uint16_t去解释否则负温度会被解析成很大的正数。如果传感器返回的是 32 位浮点数比如用 2 个寄存器存一个 IEEE 754 float那还要注意字序是大端还是小端。不同厂商定义不同有些是先高寄存器后低寄存器也就是 AABB 顺序有些是低寄存器在后直接按float指针强转很危险稳妥的做法是用位移方式手动拼出来uint32_t raw ((uint32_t)reg_hi 16) | reg_lo; float value; memcpy(value, raw, sizeof(value));如果你不确定厂商的具体字节序可以先拿寄存器原始值对比一下传感器手册里的示例值确定顺序后再写解析逻辑。3.4 用 libmodbus 省心了不少如果项目里的设备数量多、寄存器范围广不想自己维护 CRC 和帧解析我建议直接用libmodbus它是 Modbus 主从站开发的主流 C 库源码开源交叉编译也容易。#include modbus/modbus.h modbus_t *ctx modbus_new_rtu(/dev/ttyUSB0, 9600, N, 8, 1); if (ctx NULL) { fprintf(stderr, modbus_new_rtu failed: %s\n, modbus_strerror(errno)); return -1; } // 设置串口为 RS485 模式由 libmodbus 内部的 IOCTL 控制方向 modbus_set_serial_mode(ctx, MODBUS_RTU_RS485); modbus_set_slave(ctx, 1); // 从机地址 modbus_set_response_timeout(ctx, 0, 200000); // 200ms uint16_t regs[8]; int rc modbus_read_registers(ctx, 0x0000, 2, regs); if (rc 2) { printf(temp raw: %u\n, regs[0]); } modbus_free(ctx);modbus_new_rtu的第二个参数是波特率第三个是校验位第四个是数据位第五个是停止位。MODBUS_RTU_RS485这个模式要求在编译时开启了--enable-rtu-rs485它会调用 Linux 内核的TIOCSRS485ioctl 来做收发方向自动切换。如果你自己写协议栈那 485 方向切换就得自己处理。要么通过 RTS 引脚控制要么通过 GPIO 控制 485 芯片的 DE/RE 引脚。方向切换的时序很关键必须保证发送完成后数据线上的最后一个字节已经全部移出移位寄存器才能把方向拉回接收。经验值是在发送结束后加一个小延时或者用tcdrain(fd)等待数据完整发出再切换方向不然最后一个字节会被截断从机自然没有任何响应。4. 读写程序的工程化实现超时、重试、轮询调度4.1 从阻塞读到超时控制的思路前面串口配置部分用的是VMIN1, VTIME0这种模式下 read 会一直阻塞到收到字节。但 Modbus 通信是“发请求、等应答”的模式如果从机掉线或者故障read 可能一直等下去程序挂在阻塞读上后续轮询逻辑全部停摆。所以主站程序里一定不能无限制等待必须设置超时。有几种常见实现方式使用select或poll监听串口描述符的可读事件设置一个超时时间使用alarm信号配合阻塞 read直接设置 termios 的 VTIME。我推荐第 1 种最干净也最可控。一个简洁的帧接收函数可以这么写#include sys/select.h #include sys/time.h int wait_for_data(int fd, int timeout_ms) { fd_set rdfs; struct timeval tv; FD_ZERO(rdfs); FD_SET(fd, rdfs); tv.tv_sec timeout_ms / 1000; tv.tv_usec (timeout_ms % 1000) * 1000; int ret select(fd 1, rdfs, NULL, NULL, tv); if (ret 0 FD_ISSET(fd, rdfs)) { return 1; // 有数据可读 } return 0; // 超时或错误 }select 返回后再用 read 去读串口缓冲区。一次 read 不一定能把 RTU 帧全部读出来Linux 串口驱动可能因为调度原因把一帧数据分成了几段。所以接收逻辑建议维护一个缓冲区不断把新数据追加进去直到凑够一帧或者超时。在我实际项目中我会把“帧结束检测”分成两步第一步根据收到的最终数据判断是否已经达到请求报文对应的应答长度比如读 N 个寄存器应答长度就是3 N*2 2第二步在两次 read 之间的时间间隔超过 3.5 个字符时间时判定帧结束。这个“字符间隔超时”在 Linux 上做不精确但作为兜底判断够了。4.2 重试机制与从机故障隔离Modbus 主站读传感器不能只发一次请求就完事。现场环境里从机可能因为电磁干扰丢帧也可能因为自身程序跑飞了暂时不应答。所以合理的重试机制是必须的。我自己的做法是对同一从机的同一请求最多重试 3 次。第一次超时后延迟 20ms第二次超时后延迟 50ms第三次超时后延迟 100ms。如果三次都失败就把该从机标记为离线并且不再频繁请求它而是把它放到一个较慢的轮询队列里比如每 5 秒才探测一次。这样避免因为某个从机掉线导致整条总线的轮询周期被拖垮。这里有个隐蔽的坑如果总线上有多个从机某个从机连续无应答你不能一直卡在它身上。应该给每个从机的请求都设一个最大时间预算超了就切到下一个从机。整个轮询周期的稳定性取决于你对单点故障的处理能力而不是某个从机响应有多快。4.3 多从机轮询与总线占用Modbus 是半双工协议同一时刻总线上只能有一个设备发言。轮询多个从机时程序结构上建议做成“请求-应答-延时-下一请求”的串行循环不要开多线程同时往同一个串口写数据那样会直接把总线打乱。伪代码大致如下typedef struct { uint8_t slave_addr; uint16_t start_reg; uint16_t reg_count; uint16_t values[64]; int offline; } sensor_node_t; while (1) { for (int i 0; i node_count; i) { sensor_node_t *node nodes[i]; if (read_device(node, retry_count) 0) { node-offline 0; } else { node-offline 1; } usleep(20 * 1000); // 帧间间隔 } sleep(poll_interval_sec); }4.4 日志与现场排错信息记录做工业现场应用日志系统一定要有。我要求程序至少输出以下信息每次请求的原始字节十六进制每次应答的原始字节十六进制CRC 校验结果超时、重试、切换从机的事件。有了这些日志现场出了问题才能快速定位是物理层问题、协议层问题还是设备配置问题。等客户拿一个“有时读不到数据”的截图来找你如果日志里什么都没有那才是真的难办。5. 调试工具与经典故障485主从机单独正常、接一起就不行的根因5.1 用好 Modbus 调试工具开发阶段强烈建议准备 Modbus 调试工具。很多人提到Modbus Poll和Modbus Slave这两个是 Windows 下的经典工具分别用来模拟主站和从站。在 Linux 环境下除了用 Wine 跑它们之外我更推荐开源方案QModMaster。QModMaster 的界面简洁支持 RTU、TCP可以配置串口参数、读寄存器、写寄存器还能以十六进制方式显示原始报文。调试过程可以分成三步先用 QModMaster 作为主站去读待接入的传感器确认传感器地址、寄存器地址、波特率、校验方式这些参数都能对上再用 Modbus Slave 工具或者自己写个简单从站程序模拟传感器让被测板子作为主站去读它验证板端串口和协议栈是否有问题最后把真实传感器接上组合联调。如果第一步都读不到数据那问题基本在传感器配置、物理连接上和你的板子没关系。如果第一步正常、第二步失败那就要检查目标板的串口配置、波特率、电平转换等。用工具分层隔离是排查复杂现场问题最有效的方式。5.2 经典故障485主机从机单独测试正常接一起不正常这个问题在 Modbus 485 通信里出现频率极高主机接一个 USB 转 485 工具测试从机正常从机接到实际控制器上或者主从设备用短跳线直接对连反而不通。为什么会这样通常指向这几点第一A/B 线反接。485 总线上的 A 和 B 不是随便接的A 对应差分负端B 对应差分正端。不同厂商的设备对外接口丝印不太一样有的标 A/B有的标 D/D-有的标 485/485-含义可能各不相同。单独调 USB 转 485 工具时你按它的丝印接对了换到另一台设备时如果没有查手册直接按颜色对颜色很容易接反。接反的表现是所有设备都是“存在”但全部无应答或乱码。第二没有共地。这个坑非常隐蔽。485 是差分信号理论上不依赖共地但它对共模电压有严格要求。当两个设备距离较远、各自供电地电位不一致时共模电压可能超出收发器允许范围导致芯片无法正常识别差分信号。表现出来的现象就是两个设备单独和 USB 转 485 模块测都正常但它们俩直连就是不通信。解决办法是在总线一端把 485 收发器的 GND 和设备的信号地连起来或者使用带隔离的 485 模块。第三缺少终端电阻。如果通信距离短几米以内、节点数少不加终端电阻也能工作但链路可能处在临界状态稍微有点干扰就丢包。当通信距离超过十几米或者波特率超过 19200 时建议在总线首尾两端各并联一个 120Ω 终端电阻。但是要注意如果只是两个设备近距离测试加上终端电阻反而可能因为驱动能力不足导致信号幅值下降通信失败。所以你可以先不加终端电阻测试不行再加或者先加一端再看情况。第四485 方向切换时序。很多 485 芯片是半双工单向驱动发送时必须把 DE 拉高发送完再把 DE 拉低。如果方向切换不及时比如发送完最后一个字节还没移出寄存器就把 DE 拉低了最后一个字节就被截断从机收不到完整请求自然不应答。使用tcdrain(fd)确保底层 FIFO 数据全部发送完毕再延时一小段甚至 1ms 就够切换方向这个现象就能消除。第五串口参数不一致。这看起来最基础但我真见过不少次。主机配置 9600 8N1从机实际是 19200 8E1两边都不报错就是不通信。尤其是从机是那些老式的仪表、传感器默认出厂配置五花八门。遇到通信不上第一件事别急着动代码先把两边串口参数逐项核对一遍。5.3 排查链路逻辑用原始字节说话当通信异常时我最常做的事情是接一个 USB 转 485 调试器并联在总线上用串口调试助手监听总线上的原始数据。注意这里的监听工具必须在同一波特率下才能解析出有效字节。通过监听你能看到主站是否真的把请求帧发出去了CRC 字节对不对从站有没有应答帧应答帧内容是否是异常码比如 0x83、0x02 表示非法寄存器地址总线上有没有多个主站在同时发数据导致冲突。如果监听不到任何数据说明主站那边压根没发出来问题在主站串口配置或发送逻辑如果看到请求帧但看不到应答说明从站没收到正确请求问题在物理链路或从站参数如果看到请求和应答都在但主站程序里收不到那问题在主站的接收解析逻辑。5.4 实测案例传感器在 Windows 下正常Linux 板子上乱码有一次做项目传感器在 Windows 串口助手下发 Modbus 请求应答完全正常。同样一套参数用嵌入式 Linux 板子去读收到的数据全是乱码CRC 几乎从来没有通过过。排查了半天最后发现是板子的串口驱动默认把“校验位”相关的输入标志打开导致收到的字节和你发送时不一致。解决方式就是在 termios 配置里明确设置opt.c_iflag ~INPCK关闭输入奇偶校验检查、opt.c_iflag ~ISTRIP关闭剥离开最高位。这两个标志不处理干净即使你在 c_cflag 里设置了无校验位内核输入路径还是可能对字节做额外处理最终 read 出来的数据和线路上实际的数据不一致。这类问题之所以隐蔽是因为单独用 Windows 工具测试时工具已经在后台把串口属性全部初始化为最合适的值而 Linux 下你必须自己负责每一项标志位。这也再次说明串口配置不是写个波特率就完事你需要完全理解 termios 里那些标志位的含义并用“最原始的模式”工作。6. 写完主站代码之后的现场测试清单程序写完不要急着接传感器先按下面顺序做一遍自检能省很多现场时间。用串口回环测试把 TX 和 RX 短接验证串口驱动和收发链路正常用 QModMaster 或者 Modbus Slave 模拟从站验证自己的主站程序能正常读写接真实传感器先用调试工具读一遍把传感器的寄存器参数、字节序确认清楚再让板子直接对接真实传感器对比调试工具和板子读到的原始报文看是否一致。如果每一步都通过协议层面基本就稳了。剩下的就是物理链路的抗干扰能力这部分只能在现场环境里去验证和优化。7. 一点个人体会嵌入式 Linux 上做 Modbus RTU 开发真正的难点从来不是 Modbus 协议本身。协议帧格式、CRC16、寄存器映射这些都是固定的、可以查文档的东西花半天就能搞清楚。真正花时间的是串口配置里那些琐碎的标志位、485 方向切换的时序、现场环境下的干扰和信号完整性问题。这些经验很难从手册里直接学到基本要靠一个个现场问题积累出来。我个人的建议是把串口配置和 Modbus 报文收发拆成两个独立模块底层模块只负责字节收发和超时控制对外提供简洁接口上层模块只关心寄存器读写、数据解析和业务逻辑。这样一旦现场出现物理层问题你不需要去翻业务代码底层模块自己就能单独测试。借用 Linux 的开发哲学——“每个工具只做好一件事”嵌入式应用代码的维护成本会低很多。后面如果你要扩展 Modbus TCP、或者把主站改成从站实现这套分层思路也能平滑迁移。