企业官网建设流程全解析

1. 串口配置：嵌入式Linux下搞定物理链路

做嵌入式Linux上的Modbus RTU开发，第一关就是串口。RTU跑在RS485或者RS232物理层上，Linux应用层就是操作一个终端设备文件，比如/dev/ttyS0、/dev/ttymxc1、/dev/ttyUSB0这类节点。开头必须先讲清楚一个容易被新手忽略的坑：Modbus RTU是8位数据位、1位停止位（也可配置2位）、无校验或者偶校验，波特率常见9600、19200、115200，这组参数必须在打开串口后立刻配置好，否则后续读传感器数据全是乱码或者压根没响应。

Linux下配置串口有两种路子。一种是命令行直接拿stty工具调，适合快速验证硬件链路；另一种是写C代码用termios结构体配置，这是应用开发的正道。我建议先做第一步的物理链路连通性测试，再进入协议开发阶段，不然协议写完了才发现RS485的收发方向没控制住，排查起来头大。

先看stty的快速验证法子。假设传感器接在/dev/ttyS1上，波特率9600，8N1，执行：

stty -F /dev/ttyS1 9600 cs8 -cstopb -parenb

这里cs8是8位数据位，-cstopb表示1位停止位（如果+cstopb就是2位停止位），-parenb表示无校验。如果是偶校验，用parenb -parodd；奇校验用parenb parodd。验证配置是否生效，执行stty -F /dev/ttyS1 -a，会打印出当前所有终端参数，重点看speed、cs8、parenb这些字段。

但实话说，stty只是临时工具，真正的产品代码必须用termios写。下面是一段我常用的串口初始化函数，直接复制改改就能用：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <termios.h> #include <errno.h> int uart_init(const char *dev, int baudrate) { int fd = open(dev, O_RDWR | O_NOCTTY | O_NDELAY); if (fd < 0) { perror("open serial port failed"); return -1; } struct termios options; memset(&options, 0, sizeof(options)); tcgetattr(fd, &options); /* 设置波特率 */ speed_t speed; switch (baudrate) { case 9600: speed = B9600; break; case 19200: speed = B19200; break; case 38400: speed = B38400; break; case 115200: speed = B115200; break; default: fprintf(stderr, "unsupported baudrate: %d\n", baudrate); close(fd); return -1; } cfsetispeed(&options, speed); cfsetospeed(&options, speed); /* 8N1: 8数据位、无校验、1停止位 */ options.c_cflag |= (CLOCAL | CREAD); /* 忽略调制解调器控制线，使能接收 */ options.c_cflag &= ~CSIZE; options.c_cflag |= CS8; options.c_cflag &= ~PARENB; /* 无校验 */ options.c_cflag &= ~CSTOPB; /* 1位停止位 */ /* 关闭流控，关键！Modbus RTU一般不用硬件或软件流控 */ options.c_cflag &= ~CRTSCTS; options.c_iflag &= ~(IXON | IXOFF | IXANY); /* 原始模式输入输出，不做任何转换 */ options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); options.c_oflag &= ~OPOST; /* 读取超时设置，后面细讲 */ options.c_cc[VTIME] = 10; /* 1秒超时 */ options.c_cc[VMIN] = 0; /* 非阻塞模式 */ tcsetattr(fd, TCSANOW, &options); /* 清空串口缓冲 */ tcflush(fd, TCIOFLUSH); return fd; }

这个函数里有几个细节值得展开说说。

CLOCAL和CREAD必须置位。CLOCAL表示不关心调制解调器的载波检测信号，对RS232设备来说，如果这个位没置位，串口会一直等待DCD信号，很多USB转串口模块直接就不工作。CREAD是使能接收，不设置的话你读串口永远是空的。

关闭流控CRTSCTS这行，对RS485通信尤其重要。很多工控板卡的RS485收发器是自动方向切换的，但如果你打开了硬件流控，RTS/CTS引脚状态会被驱动层接管，大概率造成收发混乱。Modbus RTU是主从问答制，物理时序本来就紧张，千万别在这里给自己挖坑。

VTIME和VMIN这两个参数直接决定read()的行为。这是新手最容易懵的地方。VMIN是read返回前需要读到的字节数最小值，VTIME是等待时间（单位0.1秒）。我上面配的是VMIN=0、VTIME=10，意思是read()最多阻塞1秒，如果这段时间内没有数据就返回0。这种超时模式对Modbus主站特别合适，因为你发完请求帧后要知道从站有没有响应、响应是否超时。如果用默认的VMIN=1，read会一直阻塞到收到至少1个字节，这样你根本没法实现超时机制，程序一旦卡死就是永久阻塞。

我自己的习惯是VMIN=0、VTIME=5到20（即0.5秒到2秒），具体看从站的响应时间要求。Modbus RTU标准规定从站收到请求后必须在8个字符时间内开始响应，但那是理想情况，实际工业传感器有的就是慢性子，尤其是那些内部带协议转换的模块，可能拖到几十毫秒甚至上百毫秒。我的建议是先按从站手册给的响应时间上限加一倍余量去设置。比如手册说典型响应时间50ms，那就设置500ms超时，既不会因为网络抖动误判，也不会因为等待太久拖慢轮询周期。

还有个细节是读串口前要tcflush。这个操作清空内核缓冲区里可能残留的脏数据。特别是你刚打开串口、或者上一帧处理出错时，缓冲区里可能还躺着半截旧数据，不清洗的话会被当成新帧读到，造成帧错位。我一般是在打开串口后做一次tcflush，在每次发请求前也做一次。

2. Modbus RTU协议核心：从报文格式到CRC校验

串口通了，接下来就是协议本身。Modbus RTU是工业现场用得最多的串行通信协议，本质就是主从问答。一个总线上只能有一个主站（通常是PLC、触摸屏或者我们的嵌入式Linux主板），最多挂247个从站（地址1到247，0是广播地址）。从站之间不直接通信，所有数据交换都靠主站发起。

一个完整的RTU请求帧长这样：

响应帧结构类似，只是数据段内容不同，但如果你读到的响应帧功能码最高位是1（比如读保持寄存器0x03返回0x83），说明从站报错了，后面跟的那个字节是异常码。03是非法数据值，02是非法数据地址，01是非法功能码，04是从站设备故障，这几种最常碰到。

功能码用得最多的是0x03读保持寄存器、0x04读输入寄存器、0x06写单个保持寄存器、0x10写多个保持寄存器。读传感器数据主要是0x03和0x04，区别在于0x03读的是可写的保持寄存器，0x04读的是只读的输入寄存器。很多温湿度传感器、压力传感器用的是0x04，但也有的设备用0x03封装所有参数，具体以你手上设备的寄存器表为准。这个最基础，也最不能想当然。

CRC校验是RTU和ASCII（另一种Modbus变体，基本淘汰了）最大的区别之一。RTU用CRC16，多项式是0xA001，计算时初始值为0xFFFF。我不会拿CRC表去水文章，直接给一个最常用的查表法实现，你直接嵌入到代码里，比逐位计算的性能高好几个量级：

static const unsigned char crc_hi_table[] = { 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, ... }; static unsigned short crc16(unsigned char *buf, unsigned int len) { unsigned char crc_hi = 0xFF; unsigned char crc_lo = 0xFF; unsigned int i; while (len--) { unsigned char index = crc_hi ^ *buf++; crc_hi = crc_lo ^ crc_hi_table[index]; crc_lo = crc_lo_table[index]; } return (unsigned short)((crc_hi << 8) | crc_lo); }

上面的crc_hi_table我故意截断了，你别直接抄。完整的表太长不贴，网上搜“MODBUS CRC16查表法 C语言”，到处都有完整实现。重点是发送时，先发CRC低字节，再发高字节，这是很多新手第一次调RTU就失败的坑：明明把请求帧发过去了，从站就是不回，最后发现是CRC字节序搞反了。记住一句话：RTU的CRC是低字节在前。接收端校验的时候，把你收到的完整帧（含CRC）用同一个crc16函数算一遍，结果应该等于0，这是Modbus RTU校验最优雅的特性，不需要把收到的CRC抠出来再和自己算的结果比对。

为了保险，我再给一个逐位计算的版本，适合嵌入式平台对存储空间有极限要求、不想放两张256字节表的情形：

unsigned short crc16_bitwise(unsigned char *buf, unsigned int len) { unsigned short crc = 0xFFFF; unsigned int i, j; for (i = 0; i < len; i++) { crc ^= buf[i]; for (j = 0; j < 8; j++) { if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; } else { crc >>= 1; } } } return crc; }

这个版本理解起来容易，也方便你对照协议文档去验证自己的CRC实现是否正确。实际项目中，如果CPU主频在300MHz以上，两种算法性能差异几乎感觉不出来；但在主频几十兆的MCU上，查表法优势明显。你在嵌入式Linux上开发，CPU资源一般不是瓶颈，用哪个都行。

3. 应用层代码实现：读传感器数据与写寄存器

协议抄明白了，就开始写应用层逻辑。这里给一个完整的读取保持寄存器（功能码0x03）的C语言实现，包含请求帧组包、发送、接收、CRC校验、解析，一套走完。

先定义帧结构体，方便后续扩展：

typedef struct { unsigned char addr; unsigned char func; unsigned char data[254]; unsigned char crc_lo; unsigned char crc_hi; } modbus_frame_t; typedef struct { int fd; unsigned char slave_addr; unsigned int timeout_ms; /* RTU inter-frame delay: 3.5字符时间 */ } modbus_rtu_t; int modbus_read_holding_registers(modbus_rtu_t *ctx, unsigned short start_addr, unsigned short quantity, unsigned short *regs) { unsigned char req[8]; unsigned char rsp[256]; int len; unsigned char *buf; unsigned short crc; if (quantity < 1 || quantity > 125) { fprintf(stderr, "quantity must be 1~125\n"); return -1; } req[0] = ctx->slave_addr; req[1] = 0x03; req[2] = (start_addr >> 8) & 0xFF; req[3] = start_addr & 0xFF; req[4] = (quantity >> 8) & 0xFF; req[5] = quantity & 0xFF; crc = crc16(req, 6); req[6] = crc & 0xFF; /* 低字节在前 */ req[7] = (crc >> 8) & 0xFF; tcflush(ctx->fd, TCIOFLUSH); if (write(ctx->fd, req, 8) != 8) { perror("write failed"); return -1; } len = read(ctx->fd, rsp, sizeof(rsp)); if (len <= 0) { fprintf(stderr, "read timeout or no data\n"); return -1; } /* 收到异常响应 */ if ((rsp[1] & 0x80) != 0) { fprintf(stderr, "slave exception code: 0x%02X\n", rsp[2]); return -1; } /* 校验从站地址和功能码 */ if (rsp[0] != ctx->slave_addr || rsp[1] != 0x03) { fprintf(stderr, "invalid slave address or function code\n"); return -1; } /* CRC校验整个响应帧 */ if (crc16(rsp, len) != 0x0000) { fprintf(stderr, "response CRC check failed\n"); return -1; } /* 解析寄存器数据 */ int reg_count = rsp[2] / 2; for (int i = 0; i < reg_count; i++) { regs[i] = (rsp[3 + i * 2] << 8) | rsp[4 + i * 2]; } return reg_count; }

重点讲几处。第一，请求帧长度是固定的8字节，闭着眼都能写出来。第二，连续读寄存器数量上限是125个（0x7D），这是协议限定的，因为响应帧最多253字节，除去从站地址、功能码、字节数计数字段和CRC，数据区最多250字节，也就是125个寄存器。第三，响应帧的合法性检查至少做三层：从站地址是不是我请求的、功能码对不对、CRC校验过不过。少了任何一层，你都可能在总线上有其他设备干扰时拿到一帧脏数据却浑然不觉。

读取输入寄存器（功能码0x04）的代码几乎一模一样，只需要把01改成03，再把req[1]和rsp[1]的判断改成0x04。我经常看到有人把03和04搞混，导致读了半天全是0。这里有个经验性判断方法：大多数国产温湿度传感器、光照传感器、土壤传感器，用的都是04功能码读输入寄存器，因为数据是传感器采集结果，本身不可写；而很多支持参数配置的设备（比如变频器、PID控制器）用03读保持寄存器。但也有例外，比如一些厂商把校准参数放在04输入寄存器里，读出来是能修改的。拿到新设备第一步永远是翻手册看寄存器表，别猜。

再说写单个寄存器（功能码0x06）的实现。这个在传感器应用中不如读频繁，但很多标定设备会用到。比如某些气体传感器，你需要写寄存器来触发零点校准。请求帧是8字节，和读请求长度一样：

int modbus_write_single_register(modbus_rtu_t *ctx, unsigned short reg_addr, unsigned short reg_value) { unsigned char req[8]; unsigned char rsp[8]; int len; unsigned short crc; req[0] = ctx->slave_addr; req[1] = 0x06; req[2] = (reg_addr >> 8) & 0xFF; req[3] = reg_addr & 0xFF; req[4] = (reg_value >> 8) & 0xFF; req[5] = reg_value & 0xFF; crc = crc16(req, 6); req[6] = crc & 0xFF; req[7] = (crc >> 8) & 0xFF; if (write(ctx->fd, req, 8) != 8) { return -1; } len = read(ctx->fd, rsp, sizeof(rsp)); if (len <= 0) { return -1; } return crc16(rsp, len) == 0; }

写寄存器后从站会原样回显请求帧，所以响应长度也是8字节。如果你收到的响应帧内容和请求一模一样，基本就是写成功了。有些设备写寄存器后还需要读一遍确认值回读，这时你可以再发一个0x03请求看看目标寄存器当前值是否等于刚才写的值。实测下来，有些国产设备写操作时序比较慢，接收到写请求后要几十毫秒才能完成内部EEPROM擦写，如果紧接着马上读，读到旧值是正常的。这种设备建议写完成后延时100到200ms再读。

还有一个非常实用的技巧：Modbus RTU没有广播式的“读取”操作，但地址0是广播地址，可以发写操作让所有从站同时执行（比如统一启动）。广播帧从站不会回复，所以你的主站软件要绕过等待响应的逻辑，否则会白白等一个超时周期。

4. 帧间隔与时序：RTU最容易翻车的地方

Modbus RTU对时间有严格定义：两个字节之间的间隔不能超过1.5个字符时间，超过则从站认为是两帧数据；一帧结束的标志是静默时间达到3.5个字符时间以上。字符时间T = 1比特时间 × 11比特（1个起始位 + 8个数据位 + 1个校验位（如果有） + 1个停止位，总共11比特）。以9600波特率为例，1比特时间是104.2μs，3.5个字符时间大约是4ms，1.5个字符时间大约是1.7ms。

这个时序要求在实际项目中意味着什么？意味着你不能一上来就裸写串口然后把收发的时序搞得乱七八糟。举个例子，很多从站的实现是在接收到完整帧后，内部处理一小段时间再回响应，但也有一些从站特别严格，如果主站发数据的时候中途停顿超过了1.5个字符时间，从站直接丢弃这帧数据，不回任何响应。这在调试串口传感器时常见的现象就是：用printf打印调试信息到同一个串口，或者USB转串口驱动不稳定导致数据流有间隙，从站莫名不响应了。而且这种问题极其恶心，可能跑100次才出现一次，因为间隙偶尔才会超过1.5个字符时间。

解决方案有几个。第一，不要在发送请求帧的代码路径里加任何调试打印，尤其是那种会锁串口的调试方式，一旦锁了就影响发送连续性。第二，如果发送和接收在不同线程，发送期间接收线程要暂停读取，避免内核缓冲区被响应数据填满导致后续读取异常。第三，在驱动层面把串口设置为无延迟发送，这个在Linux下是默认行为，但如果你用了某些串口工具库（比如libserialport），要注意默认配置是否做了制约。

另一个时序关键点就是我在前面串口配置里提到的VTIME/VMIN。主站发送完请求后，读取响应应该有一个明确的超时窗口。你不可能无限等下去，否则轮询中断。常见的超时公式是：响应超时 = 从站最大响应时间 + 3.5字符时间 × 2。我习惯直接给300ms到500ms的固定值，但如果你要轮询几十个传感器，每个节点浪费500ms，一轮下来就是几十秒，根本不现实，所以轮询间隔要和超时时间匹配着调。

再分享一个调参技巧。当你发现读某个从站偶尔超时时，不要急着加大超时时间，先用逻辑分析仪或示波器抓一下串口波形，看从站到底有没有回数据、回的数据是否在请求结束后的固定间隔内。如果从站回了，但你的程序没读到，大概率是VTIME设置过短，内核缓冲还没把数据攒完整就返回了。如果从站没回，反而可能是你发出去的请求帧格式不对，从站压根没识别出来。抓波形一次就能定位，比盲改参数快十倍。没有示波器也可以先用USB转TTL板连接RX线，用另一个串口工具（比如minicom、cutecom）观察原始数据流。

5. 多从站轮询与临界资源保护

实际项目中不会只接一个传感器。一条RS485总线上挂多个从站设备是常态，这时你的主站程序就得按地址轮询。我见过很多初学者的代码，读第一个从站数据没问题，加了第二个从站就各种乱套，核心原因是没做好状态隔离。

轮询的基本结构是：定时器驱动，每个周期内按顺序访问所有从站。伪代码大致是这样：

while (1) { for (int i = 0; i < slave_count; i++) { int ret = modbus_read_holding_registers(&ctx[i], start_addr, quantity, regs); if (ret > 0) { save_to_database(ctx[i].slave_addr, regs, ret); } else { record_error(ctx[i].slave_addr); } usleep(10000); /* 帧间隔保护 */ } sleep(poll_period); }

这个简单结构里有几个隐藏问题。第一，如果某个从站没有响应，read会等待超时，这个超时时间内CPU空转，后面的从站全部排队延迟。解决思路是给每个从站设置可配置的优先级和超时统计，连续多次失败的从站可以临时跳过，等下一周期再重试。第二，总线上所有从站的请求必须是串行的，绝不可能两个线程同时往总线上发数据。所以在多线程架构里，一定要用一个互斥锁把“发送请求帧 + 接收响应帧 + CRC校验”这个整块逻辑包起来，确保同一个时刻只有一帧在总线上。哪怕你用的是多个串口连多个485总线，只要共用同一个应用层代码，也要注意上下文隔离。

第三，数据保存的时机也很讲究。我建议读到一帧数据后立刻拷贝到应用层缓存，不要带着锁去做数据库操作或日志打印，否则会把总线的锁占用时间拉长，影响其他从站的轮询节奏。很多人在这一步做错，导致轮询周期越来越长，最后系统假死。

这里分享一个踩过的坑：某次项目里我在读取传感器数据的回调里直接打印到云端，结果每当网络抖动严重时，传感器的轮询就大批量超时，后来抓日志才发现，打印机房的网络请求最长会阻塞几百毫秒，而这期间485总线锁被占用了，所有传感器全部错过了轮询窗口。后来把所有网络操作全部异步化，轮询响应才恢复正常。做嵌入式Linux一定要谨记：串口时序是硬实时要求，绝不能在临界区内做任何可能长时间阻塞的操作。

6. 常见问题与排查技巧实录

把这个项目浓缩成一份问题速查表，你在调试时对着查，至少能解决九成的故障。

有几点展开说说。

RS485的收发方向控制是硬件设计中特别要注意的。很多RS485芯片支持自动方向切换，比如MAX13487、SP3485这类带自动换向功能的芯片，软件不用管DE/RE引脚。但如果你用的是MAX485这种经典芯片，DE和RE需要手动控制。嵌入式Linux应用里通常会有一个GPIO来控制收发方向。我遇到过的坑：发送完请求后忘了及时把GPIO拉低切回接收模式，导致响应帧前半段被自己吃掉，后半段才收到，CRC必然不过。如果你不想手动控制方向，硬件设计时直接选自动换向芯片，省去软件的麻烦，稳定性还更高。

终端电阻是另一个经典坑。485总线两端需要各并联一个120Ω终端电阻。如果只是短距离（几米）点对点调试，不加终端电阻一般也能跑；但一旦总线长度超过几十米，或者挂载节点多，没有终端电阻就会出现信号反射，表现为数据偶发错误、时好时坏。排查方式是读取的时候不断打印CRC错误次数，如果CRC错误随距离增加而增多，检查终端电阻大概率不会错。

大小端问题也要特别注意。Modbus RTU协议本身规定寄存器数据是16位大端传输，也就是高字节先发送。但传感器内部的数据格式不一定就是高字节在前。我遇到过一款湿度传感器，数据手册写着寄存器地址0x0001保存湿度值，但没明确写字节序，实际读回来发现高低字节是反的。这种问题没有捷径，只能对照手册+实际校准值去确认。更复杂的情况是32位float数据，很多传感器会把浮点数拆成两个16位寄存器存储，这时不仅要处理字节序，还要处理寄存器顺序。比如有的设备低地址存高16位，高地址存低16位；有的恰恰相反。我的做法是写一个通用的32位float解析函数，支持寄存器大小端切换，参数化配置，实测省了很多事。

还有一个排查技巧值得单独说：在串口上接一个USB转TTL板子，用PC端的串口调试助手同时监听总线上主站发出的请求和从站返回的响应。这相当于给Modbus总线装了监控探头，能瞬间看出是哪一方出了问题。PC端可以用MThings、Modbus Poll这类工具，或者最简单的方式是拿一个USB转485的板子接在总线上，用sscom之类的工具打开，观察原始数据。这是我排查Modbus问题的第一反应，比在代码里加一百句printf都高效。

调试期间的日志打印也有一些心得。不要直接把read的原始字节全部printf出去，那样日志又长又难读。我习惯封装一个hex dump函数，只在DEBUG宏开启时输出帧数据、方向和错误原因。格式大致是：

#ifdef DEBUG_MODBUS printf("[MODBUS] TX(8): %02X %02X %02X %02X %02X %02X %02X %02X\n", req[0], req[1], req[2], req[3], req[4], req[5], req[6], req[7]); #endif

这种日志在调试完成后的Release版本里会通过条件编译完全去掉，不影响线上性能。另外，如果在同一个调试会话里既要打印日志又要发Modbus帧，注意调试串口不要和Modbus总线串口搞混，否则日志本身就会污染总线，触发我在第4节说的帧间隔问题。

7. 嵌入式Linux平台上的工程化落地

说到工程化，还有几层事情需要补齐，很多项目死在不该忽视的细节上。

首先是设备树和驱动层面。在嵌入式Linux上，串口对应的设备节点如果不存在，或者名称和你程序里硬编码的不一致，程序直接打不开设备。常见板卡上ttymxc0到ttymxc4对应不同的UART外设，z-turn和树莓派可能是ttyS0、ttyAMA0或者ttyUSB0。我建议把串口设备路径做成配置文件或者命令行参数，不要写死在代码里。同时要确认目标串口有没有被其他服务占用，比如systemd的getty进程默认会占用console串口，你的Modbus程序肯定打不开它。用systemctl getty相关命令检查一下，把不需要的getty服务禁用掉。

其次是打开串口时的权限问题。普通用户访问/dev/ttyS0或/dev/ttyUSB0可能会碰到permission denied，有两个解决办法：一是把当前用户加入dialout组（sudo usermod -aG dialout $USER），二是用udev规则给串口设备设置666权限。产品化阶段推荐用udev规则，按设备路径或厂家ID创建稳定的符号链接，比如/dev/sensor_bus，这样即使串口设备号变了，程序里还是能稳定访问同一个物理串口。这个细节在批量部署时特别有用，因为USB转串口设备在重启后设备节点可能从ttyUSB0变成ttyUSB1，程序配置全部得改，用符号链接就一劳永逸。

还有就是把Modbus通信封装成库。上面的代码都是面向过程的函数，但实际工程里我会把这套东西封装成一个modbus_client结构体，包含串口fd、从站地址、超时配置、错误统计字段，对外暴露read_register、write_register、read_multiple_registers这几个接口。上层业务代码根本不需要知道Modbus协议细节，只要调用接口传参就行。这样做的最大好处是隔离变化：如果后期把某个传感器从Modbus RTU换成了Modbus TCP，上层业务代码几乎不用改，只需要换一个底层通信回调函数。

这种分层思路在真实项目里的价值是：你不会在改协议时不小心碰坏了业务逻辑。我曾经在一个项目里吃过亏，为了临时支持一个走私有协议的传感器，在业务代码里塞了一堆if-else判断设备类型，半年后代码已经没人愿意改了。后来花了两个晚上把所有通信逻辑统一收敛到modbus_client层，用不同的协议实现注册同一套接口，整个系统清爽了不少。

再提醒一个不算技术问题的坑：RS485总线的GND。很多人在调试时只接A、B两根线，设备少时可能正常，但设备一多、距离一远，共模电压漂移就会导致通信不稳定甚至芯片烧毁。正确做法是确保所有485节点的GND电气连接在一起。如果距离特别远，考虑使用带隔离的RS485模块。这个坑属于“调试时一切正常，现场部署就出事”的典型，前期节约的一根GND线，后期可能花一整天都排查不出来。

如果你想快速跑通一个Demo，不必先把代码写到产品级。直接用Python的pymodbus库配上pyserial，几分钟就能读一次传感器数据。pymodbus里面的ModbusSerialClient类封装了RTU协议栈，你只需要设置串口、波特率、超时、从站地址和寄存器地址。这特别适合做原型验证，确认传感器能读到数据之后，再决定用C语言还是继续用Python做正式产品。如果产品对实时性和稳定性要求高，我用C；如果是小批量工具类应用，Python完全够用。

最后补充一点字节对齐时间。在嵌入式Linux里写Modbus主站，性能瓶颈几乎不会出现在CPU计算CRC上，而是IO等待上。你轮询几十个传感器的周期，主要消耗在串口超时等待上。所以如果你感觉系统轮询太慢，不要急着优化CRC算法，先看看有没有从站总是超时、有没有串口缓冲区设置太小导致频繁唤醒。我见过最夸张的情况，一个从站固件有bug，每次响应都要延迟1秒多才回，直接把整个轮询周期拖垮。定位到是它的问题之后，直接在代码里把它标记为慢速设备，给它单独的轮询周期，整个系统的响应立刻恢复正常。

这套从串口到协议到工程化落地的思路，基本覆盖了嵌入式Linux上Modbus RTU开发的完整链路。我个人的体会是，Modbus协议本身不复杂，真正的复杂度都在物理层和时序细节上：串口参数配错了表现是什么，RS485方向没切换好表现是什么，帧间隔超了表现是什么。把这些底层的东西吃透了，上层写什么功能码、读什么寄存器都是按图索骥的事。你踩的这些坑，绝大多数在动手之前看一遍类似的经验记录就能避开，这也是我写这篇内容最想达到的目的。