1. 为什么嵌入式Linux开发绕不开Modbus这关这几年做嵌入式Linux项目从工控网关、数据采集器到边缘计算盒子十有八九都要跟Modbus打交道。特别在工厂自动化、光伏监控、环境监测、农业大棚这些场景里传感器、PLC、电表、温控器现场设备几乎清一色支持Modbus RTU或者Modbus TCP。你要是不把这套协议玩明白做出来的设备基本没法跟现场的老旧系统对接。我最早接触Modbus是在一个变电站环境监控项目里需要同时采集几十个温湿度传感器、水浸传感器和门磁开关的状态传感器全部走RS485总线协议就是Modbus RTU。当时第一版代码用read()硬刚结果问题一堆——偶发超时、数据错位、波特率不匹配导致整个总线卡死。后来把串口配置、超时机制、CRC校验这些细节全部理清之后代码才真正稳定下来。这篇文章我想从嵌入式Linux的角度把Modbus RTU开发的完整链路拆开讲一遍包括串口怎么配、RS485方向切换怎么处理、报文格式怎么解析、CRC校验怎么写、多从机轮询的时序怎么设计以及我在实际项目中踩过的一些坑。适合正在做嵌入式Linux应用开发、需要对接RS485/RS232传感器或设备、或者想搞明白Modbus RTU底层细节的朋友。需要提前说明的是本文所有代码示例基于Linux系统下的C语言实现开发板是常见的ARM Cortex-A系列平台串口设备节点为/dev/ttySx或/dev/ttyUSBx。不同板子串口编号可能不同但原理完全一致。另一种常见的场景是用Modbus TCP走以太网但RTU是Modbus的根理解了RTU的报文结构和状态机TCP只是把报文原封不动装进TCP帧里而已难度反而更低。所以这篇文章先把RTU啃透。2. 串口配置别以为open()之后就能直接收发很多刚接触嵌入式Linux串口开发的人第一反应是open(/dev/ttyS0, O_RDWR | O_NOCTTY)之后直接read/write。确实能跑但你会发现数据经常莫名其妙地丢、乱码、卡死。原因很简单串口默认配置波特率9600、数据位8、无校验、1停止位即8N1跟你的设备不一致或者你根本没设置原始模式终端驱动把特殊字符处理逻辑插进来了。2.1 termios结构体才是串口配置的核心Linux串口配置全靠termios这套接口。关键参数就几个波特率、数据位、校验位、停止位、流控、原始模式。我贴一段实际在项目中使用的配置函数这段代码基本可以通用#include termios.h #include unistd.h #include fcntl.h #include string.h #include stdio.h #include errno.h int uart_set_attr(int fd, int baudrate, int data_bits, char parity, int stop_bits) { struct termios opts; if (tcgetattr(fd, opts) ! 0) { perror(tcgetattr); return -1; } // 设置为原始模式避免终端驱动干扰数据 cfmakeraw(opts); // 清空波特率位重新设置 cfsetispeed(opts, baudrate); cfsetospeed(opts, baudrate); // 数据位 opts.c_cflag ~CSIZE; switch (data_bits) { case 5: opts.c_cflag | CS5; break; case 6: opts.c_cflag | CS6; break; case 7: opts.c_cflag | CS7; break; case 8: opts.c_cflag | CS8; break; default: return -1; } // 校验位 switch (parity) { case N: // 无校验 opts.c_cflag ~PARENB; opts.c_iflag ~INPCK; break; case E: // 偶校验 opts.c_cflag | PARENB; opts.c_cflag ~PARODD; opts.c_iflag | INPCK; break; case O: // 奇校验 opts.c_cflag | PARENB; opts.c_cflag | PARODD; opts.c_iflag | INPCK; break; default: return -1; } // 停止位 if (stop_bits 1) { opts.c_cflag ~CSTOPB; } else if (stop_bits 2) { opts.c_cflag | CSTOPB; } else { return -1; } // 禁用硬件流控大多数RS485/RS232传感器用不到 opts.c_cflag ~CRTSCTS; // 启用接收 opts.c_cflag | CREAD | CLOCAL; // 原始输入输出不处理特殊字符 opts.c_lflag ~(ICANON | ECHO | ECHOE | ISIG); opts.c_oflag ~OPOST; opts.c_iflag ~(IXON | IXOFF | IXANY | BRKINT | ICRNL | INLCR | IGNCR); // 设置读取超时和最小字节数这是防止read卡住的关键 opts.c_cc[VTIME] 10; // 1秒超时单位0.1秒 opts.c_cc[VMIN] 0; // 不等待最小字节数 // 清空缓冲区并应用配置 tcflush(fd, TCIOFLUSH); if (tcsetattr(fd, TCSANOW, opts) ! 0) { perror(tcsetattr); return -1; } return 0; }这里面最容易忽略的是cfmakeraw()。这个函数等价于手动设置一大串标志位把串口变成“裸”通道——不处理回车换行转换、不echo、不把CtrlC当信号、不做任何行缓冲。没有这一步你读到的数据可能被内核驱动篡改过。另一个关键点是VMIN和VTIME的搭配。我见过很多人直接把这两个值设成0结果read()变成非阻塞轮询CPU占用率飙升有人设成VMIN1结果read()在收不到一个字节的情况下永远阻塞程序没法做超时处理。我实测下来RTU场景推荐VMIN0、VTIME10也就是1秒超时这样read()最多阻塞1秒就会返回0你可以基于这个返回值做超时判断不会卡死整个轮询逻辑。2.2 打开串口时要注意的细节打开串口时建议使用O_RDWR | O_NOCTTY | O_NDELAY。其中O_NOCTTY防止串口成为控制终端否则你在终端里按CtrlC会往串口发信号导致程序被中断O_NDELAY打开时不阻塞即使串口没有载波信号也能正常打开int uart_open(const char *dev_path) { int fd open(dev_path, O_RDWR | O_NOCTTY | O_NDELAY); if (fd 0) { printf(open %s failed: %s\n, dev_path, strerror(errno)); return -1; } // 恢复为阻塞模式让read可以等待数据 int flags fcntl(fd, F_GETFL, 0); flags ~O_NDELAY; fcntl(fd, F_SETFL, flags); return fd; }这个先open再清掉O_NDELAY的操作是我从内核驱动开发的朋友那里学来的避免open阶段被卡住同时确保后面的read能正常阻塞等待数据。实际项目中如果直接用O_RDWR | O_NOCTTY打开在部分USB转串口芯片上偶尔会出现open成功但读取立刻返回EOF的情况加这一步能规避。2.3 RS485方向切换是最大的隐性坑Modbus RTU走RS485总线时是半双工通信——同一时刻只能发或者只能收。标准RS485芯片比如MAX3485、SP3485有一个DE/RE引脚高电平发送、低电平接收这个引脚通常由GPIO控制或者由串口芯片的RTS引脚自动控制。嵌入式Linux下有两种做法做法一RTS自动方向控制硬件自动切换在设备树里配置串口节点时使能rs485模式例如uart2 { status okay; pinctrl-names default; pinctrl-0 uart2_pins; rs485-rts-active-low; // RTS低电平有效根据硬件连接调整 linux,rs485-enabled-at-boot-time; };内核的8250驱动会在发送数据前自动拉高/拉低RTS发送完成后自动恢复你完全不感知。这是最推荐的方案时序由内核保证非常稳定。做法二应用层GPIO手动切换如果你的板子没启用内核级RS485支持就得在应用层每次收发前手动切换GPIO。这里有个极其容易踩的坑写完数据后不能立刻把GPIO切回接收模式必须等串口FIFO里的数据全部发完。void rs485_set_dir(int gpio_fd, int tx_enable) { struct gpiohandle_request req; // 设置GPIO输出高低电平 ioctl(gpio_fd, GPIOHANDLE_SET_LINE_VALUES_IOCTL, data); } // 发送数据 void modbus_send(int uart_fd, int gpio_fd, const uint8_t *buf, int len) { rs485_set_dir(gpio_fd, 1); // 切换到发送模式 // 关键先清空串口缓冲区确保之前残留的数据不会混入本次发送 tcflush(uart_fd, TCOFLUSH); write(uart_fd, buf, len); // 关键等待数据全部发出tcdrain阻塞直到发完 tcdrain(uart_fd); rs485_set_dir(gpio_fd, 0); // 切回接收模式 }tcdrain()这个函数是很多人的盲区。只调用write()只是把数据写进了内核缓冲区不代表已经通过UART发送完毕。如果在数据还在内核缓冲时直接把GPIO切到接收模式后面半截报文会被截断从机收到残缺帧直接丢弃。用tcdrain()等一次发送完成实测能解决九成以上的“主机发出去从机没响应”问题。我在一个项目上就遇到过主机发查询帧从机偶尔能响应偶尔完全没反应。用示波器一抓发现发送波形后面一截被“砍”掉了——正是GPIO切得太快所致。加tcdrain之后问题彻底消失。3. Modbus RTU报文结构读和写到底在传什么3.1 请求帧和响应帧的逐字节拆解Modbus RTU协议本身不复杂核心就是一套“地址功能码数据校验”的帧结构。我用一个读保持寄存器的例子来拆解主机发送请求帧读从机地址1的保持寄存器起始地址0x0000读2个寄存器字节值含义00x01从机地址10x03功能码读保持寄存器2-30x00 0x00起始寄存器地址4-50x00 0x02寄存器数量6-70xC4 0x0BCRC16校验值低字节在前从机正常响应帧字节值含义00x01从机地址10x03功能码20x04数据字节数2个寄存器 × 2字节3-60x00 0x64 0x00 0xC8寄存器0值100寄存器1值2007-8CRC16校验值看到规律了吗RTU就是问一句、答一句的标准主从协议。主机发出请求从机必须响应从机不会主动上报数据。这意味着你要循环轮询每次轮询一个或几个从机拿到数据后解析入库。CRC校验值放在帧末尾低字节在前。计算范围从第一个字节从机地址到数据最后一位不包括CRC本身。3.2 04和03功能码一个读传感器数据的实际例子Modbus功能码很多但做传感器采集时90%只用两个0x03读保持寄存器Holding Register一般用于PLC、变频器等可写参数0x04读输入寄存器Input Register一般用于传感器只读数据很多温湿度传感器、光照传感器把测量值放在输入寄存器里用0x04读。我把一个真实的温湿度传感器读取代码贴出来// 生成读输入寄存器的请求帧 int modbus_read_input_regs(uint8_t slave_addr, uint16_t start_reg, uint16_t reg_count, uint8_t *frame) { frame[0] slave_addr; frame[1] 0x04; // 功能码读输入寄存器 frame[2] (start_reg 8) 0xFF; // 起始地址高字节 frame[3] start_reg 0xFF; // 起始地址低字节 frame[4] (reg_count 8) 0xFF; // 寄存器数量高字节 frame[5] reg_count 0xFF; // 寄存器数量低字节 uint16_t crc crc16_modbus(frame, 6); frame[6] crc 0xFF; // CRC低字节先发 frame[7] (crc 8) 0xFF; // CRC高字节后发 return 8; // 返回帧长度 } // 解析响应帧中的温度数据 float parse_temp_from_response(const uint8_t *resp, int len) { // 假设传感器返回的是有符号16位整数单位0.1℃ int16_t raw (resp[3] 8) | resp[4]; return (float)raw / 10.0f; }这里注意传感器数据可能有很多编码方式有的直接是int16整数值单位℃有的是放大10倍或100倍的定点数还有的是IEEE 754浮点数拆成两个寄存器。拿到数据后先查数据手册确认格式别上来就直接除以10。3.3 写寄存器和写线圈控制类场景有些应用不只是读数据还要控制比如远程开关继电器、设置设备参数。常用的写功能码有0x05写单个线圈继电器开关0x06写单个寄存器0x0F写多个线圈0x10写多个寄存器以写单个线圈为例请求帧是从机地址 0x05 线圈地址2字节 开关状态0xFF00表示开0x0000表示关 CRC。响应帧和请求帧一模一样从机原样返回。这个“原样返回”是RTU协议的一个特点可以作为写操作成功的判断依据——比对请求帧和响应帧一致就说明从机收到了。3.4 异常响应处理别无视功能码0x83、0x84实际项目中从机不一定每次都正常响应。当请求有误时从机会返回异常帧功能码最高位置1比如0x03变0x83然后跟一个异常码。常见的异常码含义异常码含义常见原因0x01非法功能码从机不支持该功能0x02非法数据地址寄存器地址超出范围0x03非法数据值寄存器值超出范围0x04从机设备故障传感器或PLC内部错误我在解析响应时会先判断功能码最高位int modbus_response_valid(const uint8_t *resp, int len, uint8_t req_func) { if (len 5) return -1; // 帧太短至少5字节才合理 if (resp[1] 0x80) { // 异常响应 printf(从机返回异常功能码0x%02X异常码0x%02X\n, resp[1], resp[2]); return -1; } if (resp[1] ! req_func) { printf(功能码不匹配期望0x%02X收到0x%02X\n, req_func, resp[1]); return -1; } return 0; }4. CRC16-Modbus计算手写还是查表4.1 CRC校验原理和代码实现CRC16-Modbus是RTU帧的“防伪标识”。由于RS485现场环境电磁干扰大、线路老化偶尔会出现数据位翻转。如果不用CRC校验你可能会把一片乱码当传感器数据存进数据库。CRC虽然不能修复错误但能可靠地检测出错误。算法要点多项式0x8005多项式反序为0xA001初始值0xFFFF结果低字节在前发送。两种实现方式按位计算和查表法。按位计算版本代码量小速度慢适用于数据量小的场合uint16_t crc16_modbus(const uint8_t *data, int len) { uint16_t crc 0xFFFF; for (int i 0; i len; i) { crc ^ data[i]; for (int j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }查表版本速度快5~10倍适合高频轮询或CPU性能弱的平台static const uint16_t crc_table[256] { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, // ... 256个表项生成方式见下文 }; uint16_t crc16_modbus_fast(const uint8_t *data, int len) { uint16_t crc 0xFFFF; for (int i 0; i len; i) { crc (crc 8) ^ crc_table[(crc ^ data[i]) 0xFF]; } return crc; }查表法快的原因很简单把8位数据的CRC结果预先算好存起来运行时直接查表异或。我在ARM Cortex-A7上实测按位算法处理一帧约20字节数据耗时约20微秒查表法不到5微秒。对每秒轮询几十个从机的场景差距明显。如果你嫌手写256个表项麻烦可以用按位版本在程序启动时动态生成表。把两种方式结合既避免手抄表项出错又有查表速度void crc_table_init(uint16_t *table) { for (int 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; } } table[i] crc; } }4.2 CRC校验失败的排查思路如果你的程序发出去的帧CRC看起来不对先用PC上的串口调试助手比如Modbus Poll或者我自己比较常用的Python pymodbus库验证报文排除从机问题后再回来看代码。常见原因有两个CRC字节序搞反了。低字节在前、高字节在后这是RTU的规定。很多人第一次写会放反从机直接静默丢弃。CRC计算范围算错了。CRC只计算从从机地址到数据字段最后一字节不包括请求帧末尾的CRC本身。我在实际调试时有个土办法用在线CRC计算工具搜“CRC16 Modbus计算器”即可把你要发的报文输进去算出标准CRC值然后跟你程序里打印出来的比对。两次一致CRC这块就稳了。5. 轮询设计如何在嵌入式Linux下高效管理多个从机5.1 并发模型选型单线程轮询 vs 多线程现场设备通常不止一个一条RS485总线上可能挂了十几个从机。这时候程序架构怎么设计很关键。最稳妥的架构是单线程事件循环轮询或者每从机一个工作线程两种我都写过单线程轮询一个while循环按地址依次发请求等响应解析再发下一个。优点是逻辑简单、不会因为多线程同时操作串口导致数据交叉缺点是如果某个从机响应慢整个总线都要等。适合从机数量≤16、响应时间稳定的场景。我的做法是维护一个从机配置表typedef struct { uint8_t addr; uint16_t start_reg; uint16_t reg_count; uint8_t func_code; uint16_t poll_interval_ms; // 轮询间隔 int timeout_ms; // 超时时间 } slave_config_t; slave_config_t slaves[] { {0x01, 0x0000, 2, 0x04, 1000, 200}, {0x02, 0x0000, 4, 0x03, 2000, 300}, {0x03, 0x0000, 2, 0x04, 1000, 200}, // ... };主循环while (1) { for (int i 0; i slave_count; i) { slave_config_t *s slaves[i]; if (time_since_last_poll(s) s-poll_interval_ms) continue; // 没到轮询间隔跳过 lock_serial(); // 如果还有其他线程也要访问串口 int len modbus_read_input_regs(s-addr, s-start_reg, s-reg_count, tx_buf); write(uart_fd, tx_buf, len); tcdrain(uart_fd); // 等待发送完成 int rlen wait_for_response(uart_fd, s-timeout_ms); if (rlen 0 modbus_response_valid(rx_buf, rlen, 0x04) 0) { parse_and_store(s, rx_buf, rlen); } unlock_serial(); } usleep(10000); // 10ms调度粒度 }每从机一个线程每个从机一个独立线程各自读写串口。优势是单个从机卡住不影响其他从机但这种方案必须给串口加锁mutex否则两个线程同时write会造成帧交叉从机收到垃圾数据。我一般不建议除非你的从机响应时间差异巨大比如一个50ms响应另一个400ms响应且总线数据量不大。5.2 超时处理1.5个字符 vs 3.5个字符Modbus RTU有两个时序参数是协议明确定义的但很多人忽略帧内字符间隔不能超过1.5个字符时间超过则视为帧不完整帧间间隔至少3.5个字符时间作为报文结束标志含义是什么在9600波特率下1个字符1起始位8数据位1停止位约1.04ms那么帧内字符间隔应小于1.56ms帧间间隔应大于3.64ms。这个要求在实际工程里尤其在Linux非实时系统上很难严格做到所以通用做法是靠固定长度判断帧完整——你发出读N个寄存器的请求就能预先算出响应帧长度3地址功能码字节数 N×2 2CRC。收到足够的字节数就算一帧完成。// 计算响应帧预期长度 int expected_resp_len(uint8_t func_code, int reg_count) { if (func_code 0x03 || func_code 0x04) { return 3 reg_count * 2 2; // 地址功能码字节数数据CRC } // 其他功能码根据情况单独算 return 8; }等待响应的函数用poll()实现int wait_for_frame(int uart_fd, uint8_t *buf, int expected_len, int timeout_ms) { struct pollfd pfd; pfd.fd uart_fd; pfd.events POLLIN; int total 0; while (total expected_len) { int ret poll(pfd, 1, timeout_ms); if (ret 0) { printf(等待响应超时\n); break; } int n read(uart_fd, buf total, expected_len - total); if (n 0) { total n; } } return total; }用poll而不是read直接等是因为read的超时粒度依赖VTIME设置没法针对不同协议动态调整。poll可以精确控制每个从机的超时时间灵活得多。5.3 日志和状态输出现场排查靠的是这个这部分是经验之谈。我在项目里一定会加一个调试模式把所有收发帧的原始hex数据打出来。现场出了问题拿日志一对比马上能定位是主机侧还是从机侧问题void dump_hex(const char *tag, const uint8_t *buf, int len) { printf([%s] , tag); for (int i 0; i len; i) { printf(%02X , buf[i]); } printf(\n); } // 发送前打日志 dump_hex(TX, tx_buf, tx_len); // 收到响应打日志 dump_hex(RX, rx_buf, rx_len);同时记录每个从机的通信状态连续失败次数、最大响应时间、最近成功时间。这些统计信息在项目验收和排查时是最大的底气。6. 实战案例读取RS485总线上的温湿度传感器前面把基础讲完了现在用一个完整案例串一遍。假设我手头有一个RS485接口的温湿度传感器从机地址0x01波特率96008N1使用功能码0x04读取输入寄存器起始寄存器0x0000连续读2个寄存器寄存器0为温度有符号int16单位0.1℃寄存器1为湿度无符号int16单位0.1%RH完整代码如下基于前面所有的知识点串联#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include termios.h #include poll.h #include errno.h // 前面定义的函数uart_set_attr、crc16_modbus、modbus_read_input_regs等 int main(int argc, char *argv[]) { const char *dev /dev/ttyS1; // 根据板子实际串口修改 int baudrate B9600; // 1. 打开串口 int fd open(dev, O_RDWR | O_NOCTTY); if (fd 0) { perror(open serial); return -1; } // 2. 配置串口参数 if (uart_set_attr(fd, baudrate, 8, N, 1) 0) { printf(串口配置失败\n); close(fd); return -1; } // 3. 构建请求帧读从机0x01的输入寄存器0-1 uint8_t tx_buf[8]; uint8_t rx_buf[64]; int tx_len modbus_read_input_regs(0x01, 0x0000, 2, tx_buf); dump_hex(TX, tx_buf, tx_len); // 4. 发送请求 write(fd, tx_buf, tx_len); tcdrain(fd); // 5. 等待响应预期长度为 3 2*2 2 9字节 int rx_len wait_for_frame(fd, rx_buf, 9, 500); if (rx_len ! 9) { printf(响应长度错误实际收到%d字节\n, rx_len); close(fd); return -1; } dump_hex(RX, rx_buf, rx_len); // 6. CRC校验 uint16_t calc_crc crc16_modbus(rx_buf, rx_len - 2); uint16_t recv_crc rx_buf[rx_len - 2] | (rx_buf[rx_len - 1] 8); if (calc_crc ! recv_crc) { printf(CRC校验失败: 计算0x%04X, 接收0x%04X\n, calc_crc, recv_crc); close(fd); return -1; } // 7. 验证功能码 if ((rx_buf[1] 0x80) ! 0) { printf(从机返回异常码: 0x%02X\n, rx_buf[2]); close(fd); return -1; } // 8. 解析数据 int16_t temp_raw (rx_buf[3] 8) | rx_buf[4]; uint16_t hum_raw (rx_buf[5] 8) | rx_buf[6]; float temp (float)temp_raw / 10.0f; float hum (float)hum_raw / 10.0f; printf(温度: %.1f℃, 湿度: %.1f%%RH\n, temp, hum); close(fd); return 0; }这段代码把前面所有知识点都串起来了串口配置、帧构建、CRC校验、超时等待、异常判断、数据解析。在实际项目里你只需要把它扩展成多从机轮询、加数据库存储或者MQTT上报即可。7. 现场问题排查实战三类高频故障的处理思路最后这部分我把实际项目中遇到过的问题归个类按出现频率排序给一套完整的排查链路。7.1 完全没响应从机像死了一样表现主机发查询帧从机无任何返回示波器看不到从机的UART波形如果接的是RS232或总线上只有主机波形RS485。排查顺序查接线A连A、B连B别接反。GND不接的话部分设备会不稳定。这是最基础也最容易被忽略的。查波特率从机设9600主机配115200数据肯定是垃圾。可以通过示波器量信号位宽粗算波特率量一个bit的时间取倒数。查地址帧里的从机地址跟DIP拨码开关或者从机配置对不对。地址不对从机直接忽略整个帧。查RS485方向切换前文说的tcdrain问题大概率出在这。用串口调试工具直连从机把从机单独接到电脑上用Modbus Poll或串口助手发指令。如果PC能通板子不通问题在网络层如果PC也不通问题在从机侧或接线。7.2 响应时有时无随机丢包表现轮询10次能成功6~7次失败时读到超时。排查顺序查干扰RS485是差分信号抗干扰能力强但布线时如果与动力电缆走同一线槽还是有被干扰的风险。先把线缆跟动力线拉开距离试试。查终端电阻长距离传输时总线两端要各接一个120Ω匹配电阻。没接的话信号反射会导致边缘数据位采样错误。距离短10米问题不大距离长了必须加。查串口缓冲区溢出嵌入式Linux下如果读取不及时内核缓冲区可能溢出丢数据。检查一下是不是没有及时read或者read逻辑被其他耗时操作卡住。查帧间间隔如果主机发的太急两个帧之间的间隔低于3.5个字符时间从机会把两帧误认为一帧导致解析失败。在轮询循环中加一个适当延时。7.3 数据对不上解析出来全是乱码或者固定偏移表现能收到响应CRC校验也过了但解析出来的值跟实际环境不符。排查顺序先看数据格式寄存器是int16还是uint16是不是放大10倍的定点数是不是IEEE 754浮点数拆成两个16位寄存器查从机手册确认编码方式。大端小端搞反Modbus协议规定高字节在前。检查你的拼接逻辑是不是(buf[3] 8) | buf[4]有人写成(buf[4] 8) | buf[3]数据直接不对。寄存器地址偏移有些传感器的寄存器地址从1开始编号而Modbus地址从0开始差一个偏移。比如手册上写“寄存器地址1表示温度”你实际请求的地址应该是0。我在项目里遇到过最离谱的一次传感器返回温度比实际高50℃。各种排查之后发现手册上写的温度寄存器地址是0x0001但实际要读0x0000厂商文档有误。这种问题只能通过把寄存器区间的值全部dump出来跟实际值对比来定位。8. 最后一个建议先用现成工具验证再动手写代码如果你是第一次做Modbus RTU开发我强烈建议先别急着写代码。在PC上装一个Modbus Poll主站模拟工具和一个Modbus Slave从站模拟工具做两件事第一用Modbus Poll连接你的真实从站设备确认协议参数地址、波特率、寄存器地址、数据格式完全正确后再动手。这样你写代码时心里有底定位问题也快。第二用Modbus Slave模拟一个从站设备把你写的代码对上测试。这样你可以在无硬件的情况下做开发而且能自由配置异常响应、超时、CRC错误等各种情况测试你代码的健壮性。我曾经在出差途中完全没有硬件的情况下靠Modbus Slave把整套采集程序写好到了现场直接跑通省了大量时间。这个习惯一直保留到现在。Modbus RTU不复杂但细节确实多。串口配置、RS485方向切换、CRC校验、超时处理、数据解析任何一个环节出问题都会让你抓狂。把这些基础打牢了后面再扩展Modbus TCP、移植到RTOS平台、或者对接各类PLC都是水到渠成的事。