简介：本资源是一套基于STM32实现Modbus-RTU主机通信的完整工程代码包，面向嵌入式开发工程师、工业自动化初学者及高校课程设计实践者，解决STM32作为主站通过RS485总线读取温湿度传感器数据的核心通信问题。压缩包共86个文件，含35个头文件（.h）、34个源码文件（.c）构成协议栈与外设驱动主体，8个启动与系统配置汇编文件（.s），以及Keil工程配置（.uvprojx/.uvoptx）、调试配置（.dbgconf）、批处理脚本（.bat）等，总大小356KB，结构清晰、模块划分明确，便于移植到STM32F1系列平台。已有170人学习下载，资源附带详细验证过程与移植指南，涵盖USART+RS485硬件适配、Modbus CRC校验实现、主站查询帧构造、从机响应解析及OLED数据显示等关键环节，代码可直接编译运行，显著降低Modbus工业通信协议落地门槛。 我前阵子手里有个项目，需要把现场好几台温湿度传感器和电表的数据统一采集上来，同时还能远程控制几路继电器。现场设备清一色支持Modbus-RTU协议，主控用的就是STM32F103C8T6。折腾完这套“基于STM32实现Modbus-RTU主机通信”的工程之后，我最大的感受是：Modbus协议本身不难，难的是把串口收发、RS485方向切换、超时重试、帧间隔这些细节糅合到一起，还得保证设备在复杂现场环境下稳定跑。这篇文章就把整个从零到联调的过程掰开揉碎讲一遍，包括代码框架、状态机设计、参数计算和线上踩坑记录，希望对做工业数据采集、物联网网关、设备联调的朋友能有点实际帮助。
1. 项目整体设计与思路拆解
1.1 为什么是Modbus-RTU，而不是Modbus-TCP或者其他协议
Modbus在工业现场的地位，基本等同于串口界的“标准普通话”。从PLC、变频器、温控表，到各种传感器、电表、IO模块，几乎所有主流工业设备都会预留Modbus-RTU接口。这套协议最大的优势是简单：一条报文就地址、功能码、数据、校验四个部分，二进制格式，在RS485总线上传输，抗干扰能力也比普通TTL串口强很多。对于需要跑几十米、上百米线缆的现场场景，Modbus-RTU + RS485属于性价比极高的组合。
Modbus-TCP当然也可以做，但前提是设备得支持以太网接口，而且现场要布网线或交换机。很多温湿度传感器、小型电表根本没有网口，只有两线制的RS485，这时候Modbus-RTU就是绕不开的选择。还有一点，Modbus-RTU对单片机的要求很低，不需要跑操作系统，一个UART + 一个定时器 + 一个GPIO就能实现，成本极低。这也是我最终选这条路的原因。
1.2 主机从机模型，到底谁说了算
Modbus-RTU的通信模型分主机和从机，主机也叫Master，从机叫Slave。一台主机可以挂最多247个从机（地址1到247），地址0是广播地址，只能发指令，从机不会回包。通信永远是主机发起请求，从机收到后响应；从机之间不能直接通信，从机也不能主动上报数据，哪怕数据发生变化，也只能等主机来问。
刚开始接触Modbus的人容易犯一个错误，就是让所有从机都往总线上发数据，结果就是总线冲突，所有通信全部乱套。正确的做法一定是“轮询”：主机把所有从机排个队，挨个发请求、等响应、收数据，然后再问下一台。整个通信节奏由主机单方面控制，这样总线上的帧才不会有交集。我这套程序里也是采用轮询模式，主循环里不断调用状态机，一个周期查完所有从机，然后再从头开始。
1.3 软件架构上的三层划分
在实际工程里，我不会把Modbus相关代码全部堆在一个文件里，而是分了三层：
- 串口驱动层：负责最底层的UART收发、RS485方向引脚控制、波特率配置，对外提供发送一帧数据、注册接收回调这类接口。
- Modbus协议层：负责组帧、拆帧、CRC校验、状态机管理、超时计数，对外提供读取保持寄存器、写单寄存器、写多寄存器这样的API。
- 应用层：负责把Modbus返回的裸数据解析成温度、湿度、开关状态等业务值，或者把用户指令翻译成Modbus写操作。
这个分层帮了大忙。项目后来换了另一款传感器，从机的寄存器地址和功能码都不一样，我只需要改应用层的映射表，协议层和驱动层完全不用动。如果你的代码还是一坨写到底，建议趁早改造成这种结构，后面维护起来会省很多力气。
2. Modbus-RTU协议核心：报文结构、功能码与CRC校验
2.1 一条报文到底长什么样
Modbus-RTU的报文格式十分紧凑，主机发请求和从机回响应都是同样的结构：地址码（1字节）+ 功能码（1字节）+ 数据区（N字节）+ CRC校验（2字节）。CRC是低字节在前，这一点特别容易搞错，后面我会专门讲。
最常用的功能码就三个：
| 功能码 | 含义 | 典型用途 |
|---|---|---|
| 0x03 | 读保持寄存器 | 读取温度、湿度、电量等参数 |
| 0x06 | 写单个寄存器 | 给从机设置一个值，比如写速度 |
| 0x10 | 写多个寄存器 | 批量设置参数，或者启动/停止等组合操作 |
举个例子，要读取地址为1的从机、起始寄存器地址0x0000、连续2个保持寄存器，主机发出去的请求帧是：
01 03 00 00 00 02 C4 0B- 01：从机地址
- 03：功能码，读保持寄存器
- 00 00：起始寄存器地址，高字节在前
- 00 02：寄存器数量
- C4 0B：CRC16校验值
如果从机正常响应，会回一帧这样的数据：
01 03 04 00 63 00 64 3A 9F- 01：从机地址
- 03：功能码
- 04：后面数据区字节数，这里是4字节
- 00 63：第一个寄存器的值，十进制99
- 00 64：第二个寄存器的值，十进制100
- 3A 9F：CRC
也就是说温度是99，湿度100，单位看从机手册是怎么定义的。如果从机收到指令但发现寄存器地址不对、功能码不支持，会回异常帧，功能码最高位置1，比如0x83，后面跟一个异常码，常见的有01（非法功能）、02（非法地址）、03（非法数据）。主机收到这种帧要能识别并处理，不能一直傻等。
2.2 CRC16-Modbus的计算原理和C语言实现
CRC校验是Modbus-RTU报文完整的最后一道防线。Modbus的CRC算法是基于多项式0xA001的，初始值固定为0xFFFF。计算时，把报文里除了CRC本身之外的所有字节依次代入，每一位都要做异或和右移操作，8位数据全部处理完，最后得到的16位值就是CRC。需要注意的是，发送时CRC低字节在前，高字节在后。
标准C语言实现是这样：
uint16_t Modbus_CRC16(uint8_t *data, uint16_t len) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < len; i++) { crc ^= data[i]; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x0001) crc = (crc >> 1) ^ 0xA001; else crc >>= 1; } } return crc; }实际组帧的时候，先把地址、功能码、数据填好，然后对整个不含CRC的帧计算CRC，再按低前高后的顺序填到帧末尾：
uint16_t crc = Modbus_CRC16(frame, 6); frame[6] = (uint8_t)(crc & 0xFF); frame[7] = (uint8_t)(crc >> 8);我之前在项目里犯过一个经典错误：用别的串口工具抓到从机回的包，一看CRC好像不对，排查半天发现是自己代码里高低字节顺序搞反了。判断CRC是否正确，最简单的办法是用现成的Modbus调试工具生成一帧数据来做对比，不要手工算，太容易出错。
2.3 帧和帧之间的间隔怎么判断
Modbus-RTU协议有一个硬性规定：一帧内部字节与字节之间的间隔不能超过1.5个字符时间，帧与帧之间间隔不能小于3.5个字符时间。也就是说，从机收到主机请求后，如果超过3.5个字符时间没有拿到下一个字节，就认为这一帧已经结束了，可以开始解析。
在串口接收数据时，如果用固定延时来判断帧结束，会有两个问题。一是在高波特率下，比如115200，一帧数据可能1毫秒不到就收完了，延时太短容易把一帧拆成两半；延时太长又影响轮询效率。二是如果从机处理慢，响应帧被拆成两段到达，固定延时就会误判成两帧。正确的做法是：每接收到一个字节就刷新一次“最后字节接收时间”，然后在周期任务里检查，如果距离最后一个字节已经超过3.5个字符时间，就认为一帧收完了。
3.5个字符时间怎么算，以9600波特率、8数据位、无校验、1停止位为例，一个字符实际占用1个起始位 + 8个数据位 + 1个停止位 = 10个位时间。一个位时间是1/9600秒，约104微秒，3.5个字符就是3.5乘以10再乘以104微秒，约3.6毫秒。程序中我一般取整到5毫秒，留一点余量。
3. STM32串口底层配置与RS485方向控制
3.1 CubeMX配置串口参数
在STM32上做Modbus-RTU，串口这块我用的是HAL库，ST官方持续维护，代码可读性也好。以STM32F103C8T6为例，CubeMX里选了USART1，配置成异步模式，波特率根据从机设备来定，我这个项目里的传感器最高只支持9600，为了稳定我全链路统一用了9600，8位数据、无校验、1位停止位，也就是常说的8N1。如果设备要求偶校验，就选Even。
需要特别留意的是，Modbus-RTU的波特率、数据位、校验位必须和所有从机完全一致，只要有一端不一致，通信就直接失败。工程里最好在配置头文件里定义成宏：
#define MODBUS_BAUDRATE 9600 #define MODBUS_DATA_BITS UART_WORDLENGTH_8B #define MODBUS_PARITY UART_PARITY_NONE #define MODBUS_STOP_BITS UART_STOPBITS_1这样以后换设备，改一个宏就行，不用到处搜代码。
3.2 RS485收发方向切换，最容易翻车的环节
RS485是半双工总线，同一时刻只能有一个方向在传数据。STM32的UART本身是TTL电平，要想跑RS485，必须外接一个收发器芯片，最常见的是MAX485、SP3485这类。芯片的DE（发送使能）和RE（接收使能）一般直接接在一起，用一个GPIO控制。GPIO输出高电平表示进入发送模式，低电平进入接收模式。
这个方向切换看着简单，实际执行起来坑不少。第一个坑是切换时机，发送完成后不能立刻拉低方向引脚，因为串口数据虽然已经送进移位寄存器，但最后一位可能还没从TX引脚上完全移出。如果立刻切到接收模式，最后一个字节甚至最后几个字节会被截断，从机收到的就是残缺帧。我之前用的是HAL_UART_Transmit，这个函数默认是等发送完成才返回的，但保险起见，我在拉低方向之前再加一个十几微秒的延时，或者在发送后等待UART的TC标志置位再切换。
发送一帧数据的完整流程：
RS485_DE_DIR(1); // 拉高方向引脚，进入发送模式 delay_us(50); // 给收发器一点切换时间 HAL_UART_Transmit(&huart1, frame, len, 100); while (!(huart1.Instance->SR & USART_FLAG_TC)); // 等待真正发送完成 delay_us(50); // 再保险一下 RS485_DE_DIR(0); // 拉低方向引脚，切回接收模式第二个坑是接收方向，如果上电后没有把RS485芯片的RE拉低，芯片会处于高阻状态，总线上的数据根本进不来。所以硬件上电后第一时间就要把方向脚配置成接收模式，而不是等到需要接收时才开始拉。这个习惯说来简单，但市面上不少开源代码就是在初始化时忘了把方向脚置低，导致主机发完请求后收不到任何数据，排查半天才发现是方向引脚没初始化。
3.3 接收不定长数据，两种方案对比
Modbus-RTU的响应帧长度不是固定的。读多个寄存器时，从机返回的数据区长度随寄存器数量变化；异常响应的长度又不一样。所以接收端不能像接收固定结构体那样简单处理，必须支持“不定长数据接收”。
第一种方案是直接用STM32串口空闲中断（IDLE Interrupt）。当总线上一段时间没有新数据时，硬件会触发空闲事件，这时DMA或中断接收到的数据就是一整帧。这个方案效率很高，代码也简洁。不过有些老的型号或部分第三方库不支持空闲中断，或者用户对HAL库不熟，配置起来会有点麻烦。
第二种方案是通用性更强的“串口接收中断 + 软件计时”。每收到一个字节就进一次接收中断，把字节存入缓冲区，同时记录当前时间戳。主循环里周期检查，如果当前时间距离最后字节时间超过了帧间隔阈值（比如前面算的5毫秒），就认为数据收完了，交给协议层去解析。这个方案不依赖特定外设，代码移植性很好，是我在实际项目里采用的主要方式。面对从机掉线、响应慢这些情况，也更容易控制超时逻辑。
4. 主机状态机设计与超时重试机制
4.1 为什么必须上状态机，而不是阻塞等待
刚写Modbus主机时，我第一版代码是这么干的：发完请求帧，直接在一个死循环里等接收，收到数据就解析，没收到就一直卡着。波特率9600时，如果从机正常响应，这段代码是能跑的。但只要有一台从机掉线、地址写错、或者通讯线被老鼠咬断，主机就永远卡在等待循环里，后面的从机全部瘫痪。整个采集系统直接锁死，还得人工复位。
这种情况下必须引入状态机和超时机制。主机每次发完请求后，给一个等待窗口，比如200毫秒。如果超过这个时间还没收到响应，就标记这次通信超时，继续处理下一台从机。这样即使有从机掉线，整个轮询周期也只是增加几百毫秒，不会影响其他设备的数据更新。
4.2 主状态机拆解
我的Modbus主机状态机大概分成五个状态：
- MB_STATE_IDLE：空闲状态，没有待处理的请求，可以接收应用层下发的新任务。
- MB_STATE_SEND_REQ：发送请求状态，把组装好的报文通过串口发出去，同时启动超时定时器。
- MB_STATE_WAIT_RESP：等待响应状态，检查接收缓冲区，看有没有完整帧到达。
- MB_STATE_PARSE：解析状态，收到帧后做CRC校验、地址比对、功能码检查，提取数据。
- MB_STATE_ERROR：错误处理状态，统一处理超时、CRC错误、异常响应等，记录错误码。
主循环里每一次调用都执行一次状态推进：
void Modbus_Master_Task(void) { switch (mb_state) { case MB_STATE_IDLE: // 从请求队列里取一个任务，组帧 if (mb_req_ready) { Modbus_BuildFrame(&mb_tx_frame); mb_state = MB_STATE_SEND_REQ; } break; case MB_STATE_SEND_REQ: RS485_DE(1); HAL_UART_Transmit(&huart1, mb_tx_frame.buf, mb_tx_frame.len, 50); while (!(huart1.Instance->SR & USART_FLAG_TC)); delay_us(50); RS485_DE(0); mb_timeout_start = HAL_GetTick(); mb_rx_len = 0; mb_state = MB_STATE_WAIT_RESP; break; case MB_STATE_WAIT_RESP: if (mb_rx_len > 0 && Modbus_FrameComplete()) { mb_state = MB_STATE_PARSE; } else if (HAL_GetTick() - mb_timeout_start > MB_RESP_TIMEOUT_MS) { mb_error_code = MB_ERR_TIMEOUT; mb_state = MB_STATE_ERROR; } break; case MB_STATE_PARSE: if (Modbus_ParseFrame() == MB_OK) { // 数据提取到应用缓冲区 mb_state = MB_STATE_IDLE; } else { mb_error_code = MB_ERR_CRC; mb_state = MB_STATE_ERROR; } break; case MB_STATE_ERROR: // 记录错误，统计通信质量，然后回到空闲 mb_state = MB_STATE_IDLE; break; } }这段代码看着简单，但有几个细节我特意加了处理。一是发送请求前要把接收缓冲区长度清零，不然上一帧残留数据会干扰本次解析。二是超时时间从“发送完成”那一刻开始算，而不是从发送开始算，否则波特率低、帧长时会误判超时。三是状态机推进要放在主循环里多次调用，不要用阻塞式延时。
4.3 超时时间怎么取才合理
超时时间设置要平衡两个矛盾：设置太短，从机还在处理指令的时候主机就放弃了，造成误判超时；设置太长，一台从机掉线后，整个轮询周期被拖得很长，其他设备的数据刷新率跟着下降。经验做法是，超时时间至少大于从机最长响应时间。工业从机模块的响应时间一般都在100毫秒以内，很多能做到20到50毫秒，PLC稍慢一些，可能到200毫秒。我在这套项目里取的是300毫秒，既不会误伤慢速从机，设备掉线后一轮最多也就多等300毫秒，整个系统60个从机的轮询周期也就增加18秒左右，完全可以接受。
如果项目对实时性要求很高，可以对不同从机配置不同的超时时间，慢速设备给长一点，快速设备给短一点，状态机里超时时间从请求结构体里读取就行。
5. 完整代码实现与联调过程
5.1 协议层接口怎么设计
协议层对外提供的接口我封装成了三个核心API，配套一个请求结构体：
typedef struct { uint8_t slave_addr; // 从机地址 uint8_t func_code; // 功能码 uint16_t reg_addr; // 起始寄存器 uint16_t reg_count; // 数量 uint16_t *write_data; // 写寄存器时的数据指针 } Modbus_Request_t; void Modbus_Init(void); uint8_t Modbus_Master_Poll(Modbus_Request_t *req, uint16_t *resp_data, uint16_t *err_code);应用层调用者的写法非常直观：
Modbus_Request_t req; uint16_t get_temp; uint16_t err; req.slave_addr = 1; req.func_code = 0x03; req.reg_addr = 0x0000; req.reg_count = 2; if (Modbus_Master_Poll(&req, &get_temp, &err) == MB_OK) { // 解析寄存器值，比如放大10倍的温度 } else { // 根据err打印错误原因 }这里把整个“组帧-发送-等待-解析”的流程全部封装在Modbus_Master_Poll里面，应用层不关心底层细节。实际项目中这个API可以直接对接状态机，也可以改为异步接口，看整体架构怎么设计。
5.2 关键实现：组帧和解析完整过程
组帧过程在Modbus_BuildFrame里完成，核心是把请求结构体翻译成字节流：
static void Modbus_BuildFrame(Modbus_Request_t *req, uint8_t *frame, uint16_t *len) { uint16_t idx = 0; uint16_t crc; frame[idx++] = req->slave_addr; frame[idx++] = req->func_code; if (req->func_code == 0x03) { frame[idx++] = (uint8_t)(req->reg_addr >> 8); frame[idx++] = (uint8_t)(req->reg_addr & 0xFF); frame[idx++] = (uint8_t)(req->reg_count >> 8); frame[idx++] = (uint8_t)(req->reg_count & 0xFF); } else if (req->func_code == 0x06) { frame[idx++] = (uint8_t)(req->reg_addr >> 8); frame[idx++] = (uint8_t)(req->reg_addr & 0xFF); frame[idx++] = (uint8_t)((*req->write_data) >> 8); frame[idx++] = (uint8_t)((*req->write_data) & 0xFF); } crc = Modbus_CRC16(frame, idx); frame[idx++] = (uint8_t)(crc & 0xFF); frame[idx++] = (uint8_t)(crc >> 8); *len = idx; }解析响应时，除了CRC校验，还要核对响应中的从机地址是否和请求一致、功能码是否和请求一致。如果不一致，哪怕CRC通过，这帧数据也不能采信。这个错误在实际调试中偶尔会出现，通常是总线上有其他设备干扰或者从机地址配置冲突。
5.3 用PC模拟从机做联调，事半功倍
我特别推荐刚开始做Modbus主机调试时，先用电脑上的从机模拟软件代替真实设备。这里用的是Modbus Slave这个工具，PC端虚拟出一台从机，然后把STM32开发板的串口通过USB转TTL接到电脑上。注意这里不需要接MAX485，因为电脑串口工具出来的是TTL电平，而STM32的USART也直接就是TTL电平，两者可以直接对接。等调通了，再把RS485收发器接上，最后才接真实的现场设备。
联调的第一步，先在Modbus Slave里设置好从站地址、功能码、寄存器初始值，然后让STM32主机发请求，看PC端能不能收到正确的读请求帧。第二步反过来，让STM32解析PC端返回的响应帧，看看解析出来的寄存器值对不对。这个阶段建议把PC端的串口监视工具和STM32的调试串口同时打开，打印每次发送和接收的完整字节流，逐字节比对。
我联调时的一个习惯是，在解析函数里打印CRC计算结果和收到的CRC值，一旦不匹配，马上就能看出来是高低字节反了还是计算过程有误。这种问题在纸上推演很难发现，跑起来一对比立刻就清楚了。
5.4 接入真实从机时，电气上的几个检查点
从PC虚拟从机切换到真实RS485总线时，有几个电气细节非常关键。首先，RS485总线的A和B线不要接反，A对应同相端，B对应反相端。市面上不少接线端子标注不清或者颜色不规范，接反之后通信是完全不行的。其次，总线两端最好加上120欧姆终端电阻，尤其是线缆较长、节点较多时，不加终端电阻会出现信号反射，导致偶发性的CRC错误。第三，如果总线上的设备离得远或者电磁干扰强，建议用屏蔽双绞线，屏蔽层单端接地。
这些电气问题在实验室里不一定暴露得出来，因为短线、低干扰环境下信号质量好，代码再烂也能跑。一到现场，线长超过50米，旁边再有变频器、电机启动，波形畸变会非常明显。所以代码层面对CRC校验、超时重试的容错一定要做好，电气上也要尽量规范，两边同时努力，系统才能稳。
6. 常见问题与排查技巧实录
6.1 从机完全不响应，先排查硬件还是先排查软件
从机不响应的时候，很多人第一反应是怀疑代码。我的排查顺序是：先用示波器或逻辑分析仪看主机TX有没有波形输出，没有波形就查UART配置和GPIO；有波形再看方向控制脚有没有正常拉高拉低，由于RS485是半双工，如果方向脚一直是接收模式，数据根本送不到总线上；方向也没问题，再看从机到底有没有在总线上回数据。用示波器抓一下从机端的AB差分信号，如果能看到回波但主机就是解析不出来，那问题大概率在接收方向，比如STM32没有进接收中断、或者接收缓冲区没清干净。
电气上没问题再回头看软件，先从最简单的入手，确认从机地址和寄存器地址是不是和设备手册完全一致。我遇到过不止一次，从机地址写成了0，而地址0是广播地址，从机收到广播指令后按协议规定是不回包的，表现就是“从机完全不响应”。这种问题纯查代码很难想到，一旦知道Modbus地址规则，一秒就能定位。
6.2 隔一段时间就出现一次CRC错误，是什么原因
CRC错误是Modbus调试最烦人的问题，因为它是“偶发性”的，多半不是代码逻辑错误，而是信号质量问题或者帧间隔设置不合理。我遇到过一次，排查了很久发现是RS485总线没有终端电阻，线缆末端信号反射叠加到正常波形上，导致高压时数据位被误判翻转。加上120欧姆电阻后，CRC错误率直接就没了。
还有一种特殊情况，现场有两台设备波特率不一致，比如一台1号从机是9600，另一台2号从机是115200，主机的请求帧对这些设备来说可能被切割成乱码，进而产生CRC错误。我在一个项目里就踩过这个坑，后来把所有从机的拨码开关统一设置成9600才解决。所以做系统联调之前，一定要对每一台从机的波特率、校验位做登记，不要想当然认为所有设备出厂配置都一样。
6.3 最后一个字节总是丢，大概率是方向切换太快
这个在前面已经提到过，但我还是想单独拿出来说，因为这是硬件调“485方向”时最容易踩的坑。现象是，主机能发出请求，但从机反馈的响应帧总是缺最后几个字节，或者收不到完整帧。用逻辑分析仪抓主机的TX引脚会发现，最后一个字节被截成了半个字节。原因就是发送完最后一个数据后，GPIO立刻拉低了DE，导致数据还没完全送出。
解决办法是在HAL_UART_Transmit返回后，额外等待USART_FLAG_TC位置位，这是串口里“数据已完全移出”的标志。然后再加几十微秒的延时，给RS485收发器留出切换时间，再拉低方向引脚。这个处理加上之后，我再也没有遇到丢最后一个字节的问题。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 一帧都不响应 | 从机地址错误、485A/B接反、方向脚未初始化 | 检查地址0~247范围、A/B对调、示波器看方向脚波形 |
| 偶发CRC错误 | 无终端电阻、波特率不一致、干扰 | 加120欧姆电阻、统一波特率、检查屏蔽层接地 |
| 响应帧最后几个字节丢失 | RS485方向切换过早 | 发送完成等待TC标志，拉低前加延时 |
| 接收到乱码 | 波特率不匹配、校验位不一致 | 核对从机参数，统一配置宏 |
| 协议请求正常但解析值不对 | 寄存器地址偏移、高低字节需要交换 | 对照从机手册，打印原始寄存器值确认 |
| 多个从机通信互相干扰 | 从机地址重复、总线未做端接 | 检查地址拨码，别重复，检查终端电阻 |
6.5 关于错误恢复机制的一点体会
Modbus主机不能只是“收到就处理，收不到就超时”这么简单，最好把错误恢复做进机制里。比如同一台从机连续多次超时，可以考虑把它标记为离线，不再每次都等满超时时间，而是降低轮询频率，比如30秒才尝试一次。这样总线上如果有一台设备彻底死掉，整个系统的通信也不会被拖垮。
我在状态机的错误处理分支里，维护了一个简单的错误计数器和离线标记。每次通信成功就清零，连续失败次数达到5次就标记从机离线。应用层拿到这个状态后，可以决定是报警还是继续轮询。这套机制在现场帮了大忙，有一台从机电源开关老化，经常掉线，但系统一直稳定运行，其他设备的数据采集完全不受影响。
最后分享一个实用小技巧
这套Modbus主机程序调试稳定后，我还往里面加了一个“看门狗”功能。用STM32的独立看门狗IWDG，主循环里每次成功轮询完一轮就从机喂狗一次。如果某次通信出现异常，比如循环卡在了某个阻塞函数里，看门狗到点就会自动复位单片机，让系统重新初始化通信。现场设备不用人工干预，过一会儿自己就能恢复正常。这种设计对无人值守的采集站来说尤其重要，省去了不少跑现场复位的麻烦。如果你做的也是类似的工业数据采集项目，建议把这个功能也加上。
本文还有配套的精品资源，点击获取
