STM32F0/F1/F2 Modbus RTU从站最小闭环与避坑

简介：这份压缩包面向正在学习单片机与嵌入式通信的开发者，聚焦STM32-F0/F1/F2系列上的Modbus通信测试，可作为从协议理解到工程落地的参考项目。包内共70个文件，约727KB，以C源文件和头文件为核心，配合Keil工程配置、编译中间文件、映射表与HEX烧录文件，覆盖USER、HARDWARE、MODBUS、DMA、TIMER、LED等模块，便于读者梳理工程组织与通信代码的对应关系。已有165人学习下载。项目内容围绕串口参数配置、主站请求与从站应答、寄存器读写、中断服务及超时校验等环节展开，读者可据此熟悉Modbus RTU/ASCII帧格式、地址与数据类型处理，并借助调试器与串口终端观察通信过程、定位常见错误。对于希望提升STM32外设编程能力、积累工业通信协议实践经验的初中级开发者，这份材料具有较好的参考与复用价值。

1. 从一包 modbusTest 说起：STM32F0/F1/F2 上的 Modbus RTU 从站最小闭环

在单片机/嵌入式 STM32-F0/F1/F2 专区里翻到“电子-modbusTest.zip”，很多人第一反应是“Modbus 协议不难，接上 485 就能通”。真到现场，最费时间的往往不是功能码，而是 3.5 字符断帧、收发方向切换和寄存器地址偏移。这包工程的价值在于把从站接收、CRC 校验、功能码分发和寄存器映射收在一个可编译的闭环里，适合刚接触 485 总线、需要给 F0/F1/F2 小板子加从站接口的开发者。它不是协议百科，而是一份能烧进芯片、能对着上位机一帧一帧对的测试底稿。

2. 工程结构与硬件抽象：串口、定时器、RS485 方向脚怎么摆

Modbus RTU 从站是被动响应型设备，代码结构不能写成“收到一个字节就回一个字节”。比较稳妥的分层是：协议层只关心完整帧、从站地址、功能码和数据区；BSP 层负责串口收发、字节超时定时和 RS485 方向脚；工程目录只放启动文件、链接脚本和 IDE 配置。这样后面把测试工程改成产品从站时，寄存器表可以换、硬件引脚可以换，协议状态机不用大改。

2.1 目录分层与文件职责

这包测试工程常见的目录组织如下，不同 IDE 的工程文件名字可能不一样，但职责划分基本一致：

协议层和 BSP 层之间最好只留一组窄接口，不要在上层直接操作串口寄存器。我一般会把接口收成下面这样：

/* modbus_port.h：协议层只依赖这几个动作 */ typedef struct { void (*send_bytes)(const uint8_t *buf, uint16_t len); void (*set_rs485_tx)(uint8_t enable); /* 1=发送，0=接收 */ uint32_t (*get_tick_ms)(void); } modbus_port_t; void modbus_port_bind(const modbus_port_t *port);

这段接口的作用是把“发一帧字节”“切换 485 方向”“拿毫秒 tick”从协议实现里拆出去。send_bytes的buf指向已经组好的回复帧，len不包含 CRC 以外的额外字节；set_rs485_tx的enable为 1 时拉高 DE，为 0 时回到接收；get_tick_ms只用于调试超时和日志，不参与 3.5 字符断帧的硬实时判断。这样在 F0 这种资源少的片子上，协议层不会绑死某个串口外设。

2.2 串口、定时器与 485 方向控制的硬件抽象

串口参数先按最常见的一版走：9600 或 19200 波特率、8 数据位、无校验、1 停止位、无硬件流控，从站地址默认 1。接收用“每来一个字节进一次中断”的方式最直观，也方便在中断里重置 3.5 字符定时器。发送不能只调用一个“写数据寄存器”就完事，RS485 收发器的方向脚必须在最后一个字节真正移出移位寄存器之后再切回接收，否则最后一两个字节会被截断，上位机看到的就是 CRC 错或超时。

/* bsp_rs485.c：发送一帧并控制方向脚 */ void bsp_rs485_send(const uint8_t *buf, uint16_t len) { bsp_rs485_set_tx(); /* 先拉高 DE，进入发送 */ uart_write_bytes(buf, len); /* 启动串口发送，最好用中断或 DMA */ /* 不要在这里立刻拉低 DE，等 UART TC 中断再切回接收 */ } /* 串口发送完成中断里调用 */ void uart_tc_irq_handler(void) { bsp_rs485_set_rx(); /* 最后一位移出后再释放总线 */ }

这段逻辑的关键点是“发送完成”不是“数据写入完成”。uart_write_bytes只负责把字节塞进发送路径，真正发完要等 TC 标志。bsp_rs485_set_tx和bsp_rs485_set_rx里面要根据收发器有效电平决定写 1 还是写 0，有的板子 DE 高有效，有的 RE 低有效，不能照抄。定时器这边用单次触发模式，每收到一个字节就重置计数，计数值按当前波特率算 3.5 个字符时间；波特率高于 19200 时，常见做法是固定按 1.75ms 处理，避免算出来的时间太短被中断抖动吃掉。

F0、F1、F2 三个系列在资源上有差别：F0 主频低、中断优先级位数少，串口中断里不要做长循环；F1 外设够用，但要注意 USART 和定时器时钟使能顺序；F2 资源多，反而容易把 DMA、多个定时器都打开，最后中断优先级打架。我一般会先只开一个串口接收中断和一个断帧定时器，等 03/06 功能码稳定通了，再加 DMA 或日志。

2.3 从站数据区与寄存器映射表

测试工程里最容易被忽略的是地址映射。Modbus 协议帧里的寄存器地址是从 0 开始的，而上位机界面经常显示 40001、40002 这种“从 1 开始”的编号。如果协议层和界面层都按自己的习惯减一次，现场就会变成“读 40001 返回非法数据地址”。比较稳的做法是：协议层只认 0 基地址，映射表里写清楚每个功能码对应的数组和长度，界面显示偏移放到上位机脚本里处理。

/* modbus_regs.c：四类数据区分开，地址从 0 开始 */ #define HOLDING_REG_NUM 64 #define INPUT_REG_NUM 32 #define COIL_NUM 64 #define DISCRETE_NUM 32 static uint16_t holding_regs[HOLDING_REG_NUM]; static uint16_t input_regs[INPUT_REG_NUM]; static uint8_t coils[COIL_NUM]; static uint8_t discretes[DISCRETE_NUM]; /* 功能码 0x03/0x06/0x10 走 holding_regs，0x04 走 input_regs */ uint16_t *modbus_get_holding(uint16_t addr, uint16_t *max_num) { *max_num = HOLDING_REG_NUM; if (addr >= HOLDING_REG_NUM) { return 0; /* 返回空指针，上层回异常码 0x02 */ } return &holding_regs[addr]; }

这段代码把保持寄存器和输入寄存器分成两个数组，modbus_get_holding的addr是协议帧里的 0 基地址，max_num带回当前数据区总长度，方便上层判断“起始地址 + 数量”有没有越界。线圈和离散输入用uint8_t数组按位打包也行，但读写时要统一“先取字节再取位”的顺序，不然 0x01 和 0x05 功能码会一个对一个错。常见做法是给每个数据区配一张只读的描述表，表里写起始地址、数量、读写权限和回调函数，后面加自定义寄存器时不用改 switch。

3. 协议栈核心拆解：一帧请求从进入串口到寄存器更新的完整链路

从站收到一帧请求后，处理顺序是固定的：先判断帧长度够不够、从站地址是不是自己、CRC 对不对；再按功能码取起始地址和数量；然后做地址越界和数量越界检查；最后组回复帧或异常帧。真正容易翻车的是“帧边界”和“异常码回得不对”，不是 CRC 算法本身。下面按接收、分发、读写三段拆。

3.1 接收状态机与 3.5 字符断帧

接收状态机不需要很复杂，三个状态够用：空闲、接收中、帧就绪。每进一个字节，先看当前状态，如果是空闲就开始新帧并重置定时器；如果接收中且缓冲区没满就继续存；定时器超时后把状态切到帧就绪，主循环再处理。不要在串口中断里直接解析功能码，否则一帧还没收完就可能被下一帧打断。

/* modbus_slave.c：字节接收与断帧 */ typedef enum { MB_RX_IDLE = 0, MB_RX_BUSY, MB_RX_FRAME_READY } mb_rx_state_t; static uint8_t rx_buf[256]; static uint16_t rx_len; static volatile mb_rx_state_t rx_state = MB_RX_IDLE; void modbus_rx_byte_isr(uint8_t byte) { if (rx_state == MB_RX_IDLE) { rx_len = 0; rx_state = MB_RX_BUSY; } if (rx_len < sizeof(rx_buf)) { rx_buf[rx_len++] = byte; } else { rx_len = 0; rx_state = MB_RX_IDLE; /* 超长帧直接丢弃 */ } bsp_timer35_restart(); /* 每收一个字节重置 3.5 字符定时 */ } void bsp_timer35_elapsed_cb(void) { if (rx_state == MB_RX_BUSY) { rx_state = MB_RX_FRAME_READY; } }

modbus_rx_byte_isr里只做搬运和重置定时器，rx_buf大小按最大帧留余量，常见 256 字节足够。bsp_timer35_restart是单次定时器重启，不要在回调里做软件循环延时。bsp_timer35_elapsed_cb把状态置为MB_RX_FRAME_READY，主循环看到这个状态后再调用解析函数，解析完把状态清回MB_RX_IDLE。如果现场出现“两帧粘在一起”，先看定时器是不是被高优先级中断拖晚了，再看主循环处理一帧的时间是不是超过了下一帧的到达间隔。

3.2 功能码分发与异常码返回

功能码分发要先把公共检查做完，再进 switch。公共检查包括：长度至少 4 字节、从站地址匹配或广播、CRC 正确、功能码支持。任何一项不过，能回异常就回异常，不能回就静默丢弃。广播地址 0 只处理写操作，不回复，这一点在 0x06 和 0x10 里要单独判断。

/* modbus_slave.c：主处理入口 */ void modbus_handle_frame(void) { uint16_t crc_calc, crc_recv; uint8_t slave_addr, func; uint8_t resp[256]; uint16_t resp_len = 0; if (rx_len < 4) goto drop; slave_addr = rx_buf[0]; func = rx_buf[1]; crc_recv = (uint16_t)rx_buf[rx_len - 2] | ((uint16_t)rx_buf[rx_len - 1] << 8); crc_calc = modbus_crc16(rx_buf, rx_len - 2); if (crc_calc != crc_recv) goto drop; if (slave_addr != MODBUS_SLAVE_ADDR && slave_addr != 0) goto drop; switch (func) { case 0x03: resp_len = modbus_read_holding(resp, rx_buf, rx_len); break; case 0x06: resp_len = modbus_write_single(resp, rx_buf, rx_len); break; case 0x10: resp_len = modbus_write_multi(resp, rx_buf, rx_len); break; default: resp_len = modbus_build_exception(resp, slave_addr, func, 0x01); break; } if (resp_len > 0 && slave_addr != 0) { modbus_port_send(resp, resp_len); /* 内部会处理 485 方向 */ } drop: rx_len = 0; rx_state = MB_RX_IDLE; }

这段代码里crc_recv按“低字节在前”组装，因为 Modbus RTU 的 CRC 就是低字节先发。modbus_read_holding、modbus_write_single、modbus_write_multi返回实际回复长度，返回 0 表示不需要回复或已经组了异常帧。异常码 0x01 表示非法功能，0x02 表示非法数据地址，0x03 表示非法数据值，0x04 表示从站故障。广播地址 0 时只执行写操作、不发送回复，这个判断放在发送前，避免总线上多个从站同时应答。

3.3 CRC16 与寄存器读写实现

CRC16 用查表或者逐位算都行，测试工程里逐位算更容易对照。多项式 0xA001 是反射后的写法，初值 0xFFFF，结果不再异或。写寄存器时先判断数量，再判断地址范围，最后按大端写入。读寄存器回复的第一字节是从站地址，第二字节是功能码，第三字节是字节数，后面才是数据。

/* modbus_crc.c：标准 Modbus RTU CRC16 */ uint16_t modbus_crc16(const uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; uint16_t i, j; for (i = 0; i < len; i++) { crc ^= buf[i]; for (j = 0; j < 8; j++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; } else { crc >>= 1; } } } return crc; } /* 0x06 写单个保持寄存器，成功时原样回显请求帧 */ uint16_t modbus_write_single(uint8_t *resp, const uint8_t *req, uint16_t len) { uint16_t addr = ((uint16_t)req[2] << 8) | req[3]; uint16_t value = ((uint16_t)req[4] << 8) | req[5]; if (addr >= HOLDING_REG_NUM) { return modbus_build_exception(resp, req[0], req[1], 0x02); } holding_regs[addr] = value; memcpy(resp, req, 6); /* 地址、功能码、寄存器地址、值 */ { uint16_t crc = modbus_crc16(resp, 6); resp[6] = crc & 0xFF; resp[7] = (crc >> 8) & 0xFF; } return 8; }

modbus_crc16的buf不包含末尾两个 CRC 字节，len是实际参与计算的长度；modbus_write_single里addr是 0 基地址，value按大端从请求帧拼出来，回复时直接回显前 6 字节再补 CRC。注意memcpy的长度是 6，不是 8，CRC 要单独算。读多个寄存器时还要检查“起始地址 + 数量”是否超过数据区长度，超过就回 0x02，不要截断返回，否则上位机会以为读到了有效数据。

4. 跑通与联调：编译烧录后用 Python 脚本做 03/06 功能码回环

测试工程能不能跑通，不看代码写得多漂亮，看三件事：串口能不能收到完整帧、CRC 能不能对上、回复帧能不能在总线上被上位机读到。建议按“先点对点、再挂总线、最后加从站”的顺序联调。第一次不要直接上 485 总线，先用 USB 转 485 模块和板子一对一，确认 03 读保持寄存器、06 写单个寄存器都能回，再把从站地址改成 2、3 挂到总线上。

4.1 工程配置与时钟/串口参数核对

编译前先核对芯片型号、启动文件、系统时钟和串口引脚。F0/F1/F2 的时钟树不一样，串口波特率误差超过 2% 就容易在长总线上出错。常见参数先按下面这组走：

如果用 Makefile 包装，编译命令可以收成一条：

# 以 F1 系列为例，具体工具链前缀按本机安装改 make clean make MCU_SERIES=F1 BUILD=debug

MCU_SERIES用来切启动文件和宏定义，BUILD=debug打开调试符号、暂时不优化。编译完先看 map 文件里rx_buf、holding_regs有没有被放到不合适的段，再看串口初始化有没有把 TX 脚复用成普通 GPIO。烧录后不要急着发帧，先用串口助手发一串 0x00，看板子有没有把总线拉低，确认方向脚默认在接收态。

4.2 主循环与中断优先级配置

主循环只做三件事：看帧就绪标志、处理 Modbus 帧、喂看门狗。串口接收中断和断帧定时器中断的优先级要高于主循环里的慢任务，但不要高到把 SysTick 挤掉。F0 的优先级位数少，串口中断里不要调用带延时的打印函数；F1/F2 可以给串口接收一个较高优先级，给定时器次高，给 SysTick 最低。

/* main.c：主循环不解析协议，只调度 */ int main(void) { bsp_clock_init(); bsp_uart_init(9600); bsp_timer35_init(); bsp_rs485_init(); modbus_regs_init(); modbus_port_bind(&g_modbus_port); while (1) { if (rx_state == MB_RX_FRAME_READY) { modbus_handle_frame(); } app_feed_watchdog(); app_led_heartbeat(); } }

rx_state是volatile的，主循环和中断都会访问；modbus_handle_frame里不要关全局中断太久，CRC 计算 256 字节在 F0 上也是微秒级，但串口中断里不能做同样的事。看门狗喂狗放在主循环，如果协议处理卡死，看门狗会复位，这比总线静默更容易排查。中断优先级配置在bsp_uart_init和bsp_timer35_init里完成，不要在 main 里临时改。

4.3 联调步骤：从 03/06 功能码开始

上位机脚本用 Python 写最省事，构造请求帧、算 CRC、读回复、打印十六进制。先读 0x0000 起始的 2 个保持寄存器，再写 0x0001 为 0x1234，最后回读确认。脚本里把从站地址和串口名做成参数，换板子不用改代码。

# Tools/modbus_poll.py：03 读、06 写的最小回环 import serial import struct def crc16(data: bytes) -> int: crc = 0xFFFF for b in data: crc ^= b for _ in range(8): crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1 return crc def build_frame(addr: int, func: int, payload: bytes) -> bytes: body = bytes([addr, func]) + payload crc = crc16(body) return body + bytes([crc & 0xFF, (crc >> 8) & 0xFF]) ser = serial.Serial("COM3", 9600, timeout=0.3) req = build_frame(1, 0x03, struct.pack(">HH", 0x0000, 2)) ser.write(req) print("TX:", req.hex(" ")) print("RX:", ser.read(64).hex(" "))

build_frame的payload对 03 功能码是“起始地址 + 寄存器数量”，各两字节大端；对 06 功能码是“寄存器地址 + 写入值”。ser.read(64)不要等固定长度，按超时读一包再打印。期望的 03 回复是01 03 04 xx xx xx xx crc_lo crc_hi，其中04是字节数。如果回复01 83 02 ...，说明地址越界，去查映射表；如果完全没回复，先查 485 方向脚和从站地址。

4.4 抓包与日志：用串口助手看原始帧

串口助手要把“HEX 显示”和“HEX 发送”都打开，时间戳打开。一次正常回环的日志大概是这样：TX: 01 03 00 00 00 02 C4 0B，RX: 01 03 04 00 00 00 00 FA 33。如果 TX 后面跟着一串00，可能是方向脚切得太晚，把总线拉低了；如果 RX 比预期少一两个字节，优先看 TC 中断里切接收的时机。逻辑分析仪夹在 A/B 线上看差分波形更直接，但先看串口日志能排掉一半问题。

5. 避坑与排查：Modbus RTU 在 F0/F1/F2 上最容易翻车的 5 个现场

Modbus 的坑大多不在协议文档里，而在“最后一字节有没有发完”“定时器有没有被拖晚”“地址到底从 0 还是从 1 算”。下面几条按现场出现频率排，每条按现象、原因、解决写，方便对着板子查。

5.1 通信层：收不到、回不出、粘帧

现象一：上位机发 03 请求，从站完全没回复，串口助手的 RX 为空。
原因通常是 RS485 方向脚默认电平不对，收发器一直处在发送态，或者 DE/RE 接反，总线被从站自己拉住。解决：断电用万用表量方向脚，确认接收态时总线是空闲；初始化时先把方向脚置为接收，再开串口中断。如果板子上有收发器使能脚，确认高有效还是低有效，不要照抄别的板子。

现象二：从站回了，但上位机说 CRC 错，抓包看回复末尾少一字节。
原因是发送函数在数据写入后就拉低了 DE，最后一个字节还在移位寄存器里就被切断。解决：把方向切换放到 UART TC 中断里，或者发送完成中断里；不要在uart_write_bytes后面加一个固定delay_us了事，主频一变延时就不准。F0 上尤其要注意，中断响应慢的时候固定延时更容易翻车。

现象三：偶发两帧粘在一起，解析时把第二帧的地址当成第一帧的数据。
原因是 3.5 字符定时器被高优先级中断拖晚，或者主循环处理一帧的时间太长，下一帧已经来了还没清状态。解决：断帧定时器用硬件单次触发，回调里只置标志；主循环处理完一帧立刻清rx_len和状态；高波特率下按固定 1.75ms 处理，不要把定时值算得太极限。

5.2 协议层与数据层：CRC、地址、类型

现象四：所有帧都报 CRC 错，但用在线工具算出来是对的。
常见原因是 CRC 结果字节序反了，或者计算范围把末尾 CRC 也算进去了。Modbus RTU 的 CRC 低字节先发，计算时len不包含 CRC 两个字节。解决：抓一帧已知正确的请求，单独打印crc_calc和crc_recv对比；确认多项式是 0xA001、初值 0xFFFF、结果不异或。如果用的是查表法，检查表是不是反射表。

现象五：读 40001 返回异常码 0x02，但映射表里明明有 64 个寄存器。
原因是上位机显示地址从 1 开始，协议帧地址从 0 开始，中间多做了一次或漏了一次偏移。解决：协议层只认 0 基地址，holding_regs[0]对应 40001；上位机脚本里如果要显示 40001，只在打印时加偏移，不要改请求帧。线圈和离散输入同理，0x0000 对应第一路。

5.3 现场排查顺序：从电源到帧尾

我一般按这个顺序排：先量 485 收发器供电和 A/B 静态电平，确认没有短路；再用串口助手一对一发帧，排除总线多从站冲突；然后看从站 TX 脚有没有波形，确认 MCU 真的在发；接着看方向脚切换时刻，确认最后字节完整；最后才查 CRC、地址和功能码。不要一上来就改协议代码，很多“协议问题”其实是方向脚和定时器造成的。把每一帧的 TX/RX 十六进制日志留下来，后面改寄存器表时才有对照。

6. 二次开发：把测试从站改成自己的寄存器表与命令分发

把测试工程改成产品从站，第一步不是加功能码，而是把寄存器表固定下来。我一般会先做一张表，写清楚每个地址对应什么量、读写权限、数据类型和缩放系数，再让modbus_regs.c只做“地址到变量”的映射。比如温度放holding_regs[0]、报警阈值放holding_regs[1]、设备状态放input_regs[0]，地址不要东一个西一个。功能码先只留 03、06、10，等上位机稳定了再加 01、05、0F，裁剪比堆功能更安全。

/* 二次开发时把映射表做成静态描述，加寄存器不用改 switch */ typedef struct { uint16_t addr; uint16_t *var; uint8_t rw; /* 1=只读，3=读写 */ } mb_holding_item_t; static mb_holding_item_t holding_map[] = { {0, &g_temperature, 1}, {1, &g_alarm_threshold, 3}, {2, &g_device_status, 1}, };

这张表的好处是地址越界判断和读写权限都能收在一处，后面加一个“设备运行时间”只需要加一行。移植到 F0 时注意中断优先级位数少，串口中断里不要做浮点运算；移植到 F2 时资源多，但也别把 DMA 和多个定时器一起开，先保证 3.5 字符断帧稳定。验证方法很土但有效：用脚本连续发 1000 次 03 请求，统计超时和 CRC 错次数；再发 1000 次 06 写不同地址，回读比对。从那以后我每次把测试从站改成产品从站，都先固定一版抓包记录再动寄存器表。希望帮到你。

本文还有配套的精品资源，点击获取