简介：面向STM32嵌入式开发者与工业通信初学者，这份压缩包提供一套围绕Modbus通信测试的工程资料，重点覆盖STM32-F0/F1/F2系列（工程文件对应F10x高密度型号）的串口配置、主从站收发、寄存器读写与异常处理等实践环节，适合用来理解协议栈如何落到单片机代码中。包内共70个文件，约727KB，以9个C源文件和9个头文件为核心，配合Keil的uvproj/uvopt工程、启动汇编、hex与axf固件，以及map、lst等构建输出；另有.o、.crf、.d等编译中间文件，并可见USART、MODBUS、DMA、TIMER、LED、LCD等模块目录，便于按功能梳理工程结构。已有165人学习，可借助现成工程对照串口参数、帧格式和调试流程，积累嵌入式通信项目的排错思路。

1. 一个压缩包里的 Modbus 从机骨架：先看清它能替你省哪几步

不少人第一次调试 Modbus 从机时，都会先怀疑“协议是不是写错了”；实际翻车的，却往往是 T3.5 字符间隔的判定和 485 方向脚的翻转发。协议本身只有二十来页，真正耗时间的是“帧收不全”“CRC 偶尔报错”“回完最后一字节被自己截断”这类边角问题。电子-modbusTest.zip这类工程的价值就在这里：它把从机侧的帧解析、CRC 校验、功能码分发和寄存器映射先搭成一个能跑的骨架，你拿到手改的是寄存器表和硬件引脚，而不是从零推导状态机。它适合正在用 STM32 F0/F1/F2 做小型采集板、要把数据接到触摸屏、PLC 或上位机组态软件的嵌入式开发者，也适合课程设计阶段需要一份能演示、能抓包、能复现的 Modbus RTU 从机例程的人。

2. 拆开工程看分层：协议栈、寄存器映射和串口驱动怎么咬合

拿到包之后别急着编译。先花十分钟把目录看一遍，搞清楚哪部分该动、哪部分不该动，后面移植时能少掉很多“改着改着连原始例程都跑不起来”的麻烦。这个工程的组织方式大概率不会太复杂，常见做法是按职责切成应用层、协议层和板级驱动三块；即便你手上的版本把协议和应用揉在同一个main.c里，下面的阅读顺序也一样成立。

2.1 三层职责与“改哪里”的边界

从实际工程的拆分习惯看，一份 Modbus 从机代码大致对应这么几张表：

分层的意义在于排错时可以快速定位。主机报超时，先看驱动层有没有进接收中断；收到了但回异常码，问题在协议层的地址校验；回的数据不对，才轮到应用层的寄存器映射。很多人把这三点混在一起查，改一处编译一次，最后连“原来那一版是好的”都说不清。我的习惯是先在原始工程上原样跑通一次，用主机工具读几个寄存器，确认基线可用，再动手改应用层。这样后面任何异常都能二分定位到“是我改出来的”还是“本来就有”。

2.2 一帧数据从进中断到回帧的完整路径

从机侧的核心是一个极简状态机：空闲 → 接收中 → 帧结束 → 校验 → 执行 → 回应 → 空闲。真正决定成败的是“帧结束”这一步怎么判。Modbus RTU 用字符间隔划帧，总线空闲超过 3.5 个字符时间就认为一帧结束，所以接收不能靠“收满 N 个字节”来触发，必须依赖串口空闲中断或者一个独立的定时器。工程里通常会定义一个帧结构体承载解析结果，把原始字节和解析后的字段分开存：

/* 从机侧一帧的解析结果，字段与 PDU 一一对应 */ typedef struct { uint8_t addr; /* 从机地址，1~247，0 为广播 */ uint8_t func; /* 功能码，0x03/0x06/0x10 等 */ uint16_t reg; /* 起始寄存器地址，PDU 内为 0 基 */ uint16_t num; /* 寄存器数量，或 0x06 的写入值 */ uint8_t data[256]; /* 原始帧，0x10 写多寄存器时取数据段 */ uint16_t len; /* 实际收到的字节数，含 CRC */ } mb_frame_t;

reg字段要特别注意：PDU 里的地址是 0 基的，主机软件界面上显示的 40001 是 1 基的，两者差 1。这个字段到底存 0 基还是 1 基，全工程必须统一，否则后面每个功能码都要多一次加减，早晚出错。我的做法是解析完立刻转成 0 基存进结构体，应用层只认 0 基。len存实际字节数而不是固定长度，是因为不同功能码的帧长差别很大，0x03 请求固定 8 字节，0x10 请求则是 9 加数据长度，用固定长度判断会在写多寄存器时误判。

解析函数的骨架大致是这样，先做长度下限判断，再做 CRC，最后才看地址：

static mb_result_t mb_parse(const uint8_t *buf, uint16_t len, mb_frame_t *f) { if (len < 4) { /* 最短合法帧：addr + func + crc16 */ return MB_ERR_SHORT; } uint16_t crc_calc = mb_crc16(buf, len - 2); uint16_t crc_recv = (uint16_t)buf[len - 2] | ((uint16_t)buf[len - 1] << 8); if (crc_calc != crc_recv) { /* CRC 低字节在前，别拼反 */ return MB_ERR_CRC; } f->addr = buf[0]; f->func = buf[1]; if (f->addr != mb_slave_addr && f->addr != 0) { return MB_ERR_NOT_MINE; /* 不是本机地址，静默丢弃 */ } f->len = len; memcpy(f->data, buf, len); /* 地址与数量字段交给各功能码自己解析，长度校验更精确 */ return MB_OK; }

顺序很关键。先判长度能挡住 DMA 缓冲区里的残留脏数据；再判 CRC 能挡住总线干扰和半包；最后判地址。如果把地址判断放最前面，帧头恰好撞上本机地址的噪声就会被当成有效帧往下走，回出去的响应会把总线搅乱。MB_ERR_NOT_MINE这种情况必须静默丢弃，不能回异常码，否则多机总线上会出现两台从机同时应答的场面。

2.3 寄存器映射表：把 4x 区做成一张可维护的表

功能码只是搬运工，真正决定设备行为的是寄存器表怎么设计。常见做法是给保持寄存器区建一张静态表，每项记录地址、数据指针、读写权限和上下限，功能码处理时只查表，不写死switch：

typedef struct { uint16_t addr; /* 0 基地址 */ uint16_t *pval; /* 指向实际变量，省掉拷贝 */ uint8_t perm; /* 0 = 只读，1 = 读写 */ uint16_t min; /* 写入下限，仅读写寄存器有效 */ uint16_t max; /* 写入上限 */ } reg_item_t; static uint16_t reg_temp_x10; /* 温度，放大 10 倍 */ static uint16_t reg_humi_x10; /* 湿度，放大 10 倍 */ static uint16_t reg_mode; /* 运行模式，0~3 */ static uint16_t reg_baud_code; /* 波特率档位，掉电保存 */ static const reg_item_t reg_table[] = { { 0x0000, &reg_temp_x10, 0, 0, 0 }, { 0x0001, &reg_humi_x10, 0, 0, 0 }, { 0x0002, &reg_mode, 1, 0, 3 }, { 0x0003, &reg_baud_code, 1, 1, 6 }, }; #define REG_COUNT (sizeof(reg_table) / sizeof(reg_table[0]))

表项用指针而不是值，好处是采集任务可以直接改变量，不需要额外同步；坏处是读写要防止“读两个字节的中间被中断改了”，对 16 位变量在 32 位机上单次读写本身就是原子的，问题不大，但对 32 位数据拆成两个寄存器时就必须加临界区。perm字段让只读寄存器在收到 0x06 时直接回非法数据地址，而不是默默写入再被主机读出来发现没生效。上下限放在表里，比在每个功能码分支里写if更好维护，加一个寄存器只改一处。

寄存器地址的分配也要留出余量。我一般按功能分区：0x0000 起放实时测量值，0x0010 起放配置参数，0x0020 起放设备信息（版本号、序列号），中间各留 16 个空位。这样后期加量不用整体挪地址，组态软件里已经做好的画面也不用重画。这张表就是整个从机对外的“合同”，定下来之后尽量只增不改。

3. 移植到 F0/F1/F2：时钟、USART 与 485 方向脚的改法

同一个协议栈放到 F0 和放到 F1 上，代码几乎不用改，出问题的永远是三样东西：串口时钟源算错导致波特率偏、接收路径选错导致丢字节、方向脚翻转时机不对导致末字节被截。这一章按移植时最容易卡住的顺序展开。

3.1 时钟与波特率误差：先算再烧

F0 常见主频 48MHz，F1 是 72MHz，F2 能到 120MHz，USART 挂在 APB1 还是 APB2 直接决定分频系数。过采样 16 时，BRR 的整数部分约等于fCK / BaudRate，误差要求控制在 2% 以内，实际工程最好压到 1% 以下，否则长线缆或多机并联时累积误差会让采样点漂出位宽。

这张表能解释一个常见现象：同一份代码在 F1 板上跑 115200 毫无问题，换到 F0 板就偶发 CRC 错。不是协议栈的问题，是 BRR 取整后误差虽然只有 0.08%，但主机侧如果也有偏差，两边一叠加就逼近采样容限。稳妥的做法是初始化后把huart.Init.BaudRate回过头读出来，用fCK / BRR反算实际值打印一次，心里有数。

/* 以 USART2 为例，F1 上挂在 APB1，72MHz */ huart2.Instance = USART2; huart2.Init.BaudRate = 9600; /* 先跟主机对齐，调通再提速 */ huart2.Init.WordLength = UART_WORDLENGTH_8B; huart2.Init.StopBits = UART_STOPBITS_1; huart2.Init.Parity = UART_PARITY_NONE; /* Modbus RTU 必须无校验 */ huart2.Init.Mode = UART_MODE_TX_RX; huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart2.Init.OverSampling = UART_OVERSAMPLING_16; if (HAL_UART_Init(&huart2) != HAL_OK) { Error_Handler(); }

Parity这一项是硬性要求。有些工程师觉得加个偶校验更稳，结果主机按 8N1 发、从机按 8E1 收，每帧都错位，怎么查 CRC 都不对。Modbus RTU 标准帧就是 1 起始位、8 数据位、无校验、1 停止位，要校验靠 CRC 就够了。OverSampling保持 16 倍，除非波特率特别高需要切 8 倍采样，切了之后 BRR 的计算方式也变，容易漏改。

3.2 接收路径：空闲中断加 DMA，比逐字节中断省心

F0/F1/F2 的 USART 都支持空闲中断。逐字节接收中断在 9600 下没问题，到 115200 时每个字节间隔只有八十多微秒，中断频繁进出会挤占主循环，一帧十几个字节就容易丢。常见做法是开 DMA 循环接收加空闲中断，空闲中断来了读一下 DMA 剩余计数，就知道这帧收了多少字节。

#define MB_RX_MAX 256 static uint8_t mb_rx_dma[MB_RX_MAX]; volatile uint16_t mb_rx_len = 0; volatile uint8_t mb_frame_flag = 0; void mb_rx_start(UART_HandleTypeDef *h) { __HAL_UART_CLEAR_IDLEFLAG(h); __HAL_UART_ENABLE_IT(h, UART_IT_IDLE); /* 打开空闲中断 */ HAL_UART_Receive_DMA(h, mb_rx_dma, MB_RX_MAX); /* DMA 循环装载 */ } /* 在 USART2_IRQHandler 中调用，注意先清标志再停 DMA */ void mb_rx_irq(UART_HandleTypeDef *h) { if (__HAL_UART_GET_FLAG(h, UART_FLAG_IDLE) != RESET) { __HAL_UART_CLEAR_IDLEFLAG(h); HAL_UART_DMAStop(h); mb_rx_len = MB_RX_MAX - __HAL_DMA_GET_COUNTER(h->hdmarx); mb_frame_flag = 1; /* 交给主循环，别在中断里解析 */ HAL_UART_Receive_DMA(h, mb_rx_dma, MB_RX_MAX); /* 立刻重启，防止下一帧丢失 */ } }

这里有两个细节。第一，mb_frame_flag置位后主循环处理，不要在中断里做 CRC 和回包，发送是阻塞操作，放在中断里会把后续接收拖垮。第二，重启 DMA 要放在中断末尾，但重启之前收到的数据属于下一帧，所以解析时必须用mb_rx_len做边界，不能直接把整个 256 字节缓冲区丢给解析函数。缓冲区开 256 字节是因为 0x10 写 123 个寄存器时请求帧长达 255 字节，按最大帧留余量比事后溢出强。

3.3 方向脚：等 TC 而不是等 TXE

485 收发切换是新手最容易踩的地方。DE/RE 拉高进发送态，发完拉低回接收态，逻辑没错，错在“发完”怎么判。TXE 只表示数据寄存器空了，移位寄存器里还有最后一个字节没出去；这时候拉低方向脚，总线上最后一个字节会被截断，主机侧表现为“CRC 错”或者“帧长度不足”。正确的判据是 TC 置位，也就是整个字节真正移出完毕。

static inline void rs485_tx_on(void) { HAL_GPIO_WritePin(DE_GPIO_Port, DE_Pin, GPIO_PIN_SET); } static inline void rs485_rx_on(void) { HAL_GPIO_WritePin(DE_GPIO_Port, DE_Pin, GPIO_PIN_RESET); } /* 阻塞式发送，工程里够用，注意配合超时 */ void mb_send(const uint8_t *buf, uint16_t len) { rs485_tx_on(); HAL_UART_Transmit(&huart2, (uint8_t *)buf, len, 100); /* HAL 阻塞发送内部已等 TC，这里再显式确认一次，换库也不出错 */ while (__HAL_UART_GET_FLAG(&huart2, UART_FLAG_TC) == RESET) { } rs485_rx_on(); }

如果用中断或 DMA 发送，就不能这么写，必须在HAL_UART_TxCpltCallback里拉低方向脚，而且回调触发的前提也是 TC 而非 TXE。方向脚拉低之后还要留一点余量再允许接收，因为收发器从发送态切到接收态需要纳秒到微秒级的时间，具体看器件手册。我一般的做法是拉低后插一个几十微秒的短延时，或者干脆靠主机轮询间隔自然隔开。发送函数里HAL_UART_Transmit的超时给了 100ms，是按 9600 波特率下 256 字节约 267ms 算的还不够，实际要按最大帧长和最低波特率反算，这个值给小了会在长帧时提前返回，属于隐性 bug。

移植完成后先别接主机，用串口助手手动发一帧读寄存器请求，看从机回什么。回对了再上组态软件，能省掉一半“到底是哪边的问题”的扯皮。

4. 功能码实现：0x03/0x06/0x10 与 CRC 的手写验证

从机不需要实现全部功能码，把 0x03 读保持寄存器、0x06 写单个寄存器、0x10 写多个寄存器这三条做扎实，绝大多数采集场景就够用了。这一章把 CRC 和三个功能码的实现摊开说，重点是字节序和边界判断。

4.1 CRC16：两种写法与字节序

Modbus 用的 CRC16 是初值 0xFFFF、多项式 0xA001（0x8005 的反向）、低位先出的变体。逐位算法代码短、便于核对，查表法快、适合高频轮询，工程里可以先上逐位版跑通，压测时再换表。

uint16_t mb_crc16(const uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; /* 初值固定，别改成 0 */ for (uint16_t i = 0; i < len; i++) { crc ^= buf[i]; /* 异或到低字节 */ for (uint8_t b = 0; b < 8; b++) { if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; /* 反向多项式 */ } else { crc >>= 1; } } } return crc; }

发送时 CRC 低字节在前，接收时也要按低字节在前拼回来。上位机侧可以用同一套逻辑交叉验证，避免“两边都错得一样”这种假通过：

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 frame = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x0A]) c = crc16(frame) print((frame + bytes([c & 0xFF, c >> 8])).hex(" "))

拿一个已知帧校对：01 03 00 00 00 0A的 CRC 是C5 CD，帧尾低字节在前写成C5 CD。如果打印出来是CD C5，说明字节序拼反了，问题不在算法在发送环节。这类小验证脚本我每次移植都会留一份，比盯着示波器猜快得多。

4.2 三个功能码的处理骨架

0x03 读保持寄存器要校验数量范围 1 到 125，响应里带字节数，数据按高字节在前排列：

static uint8_t mb_read_holding(const mb_frame_t *f, uint8_t *resp, uint16_t *rlen) { if (f->num == 0 || f->num > 125) { return 0x03; /* 非法数据值 */ } uint16_t bytes = f->num * 2; resp[0] = mb_slave_addr; resp[1] = f->func; resp[2] = (uint8_t)bytes; for (uint16_t i = 0; i < f->num; i++) { uint16_t v; if (!reg_read(f->reg + i, &v)) { return 0x02; /* 非法数据地址 */ } resp[3 + i * 2] = (uint8_t)(v >> 8); /* 寄存器值大端 */ resp[4 + i * 2] = (uint8_t)(v & 0xFF); } *rlen = 3 + bytes; return 0x00; }

reg_read要按地址查表，查不到返回失败。注意这里的失败是“地址越界”，对应异常码 0x02，不要跟 0x03 混用。另外resp[2]是字节数不是寄存器数，写错了主机会多读或少读，表现为数据整体错位。

0x06 写单个寄存器最简单，响应就是原样回显请求帧。0x10 写多个寄存器要额外校验字节数字段，请求里的字节数必须等于寄存器数量乘二：

static uint8_t mb_write_multi(const mb_frame_t *f, uint8_t *resp, uint16_t *rlen) { /* 请求格式：addr func startHi startLo numHi numLo byteCnt data... */ uint8_t byte_cnt = f->data[6]; if (f->num == 0 || f->num > 123 || byte_cnt != f->num * 2) { return 0x03; } for (uint16_t i = 0; i < f->num; i++) { uint16_t v = ((uint16_t)f->data[7 + i * 2] << 8) | f->data[8 + i * 2]; if (!reg_write(f->reg + i, v)) { return 0x02; } } /* 响应回显起始地址与数量，共 6 字节加 CRC */ memcpy(resp, f->data, 6); *rlen = 6; return 0x00; }

写多个寄存器时如果中途某个地址非法，标准做法是整帧拒绝，不要写一半留一半。所以稳妥的实现是先整段校验地址合法性，全部通过再落值，否则主机会看到“部分写入”的诡异状态。数量上限 123 也是标准规定的，超过就是非法数据值。

4.3 异常响应的三个码

异常响应的格式是功能码最高位置 1，再跟一个异常码。常用的三个：0x01 非法功能（主机发了没实现的功能码）、0x02 非法数据地址（寄存器不在表内）、0x03 非法数据值（数量越界、字节数不匹配）。很多人图省事一律回 0x02，联调时主机侧提示含糊，反而拖慢排查。按语义分开回，组态软件和抓包工具都能直接告诉你是地址错了还是值错了。

回异常帧之前记得把正常响应的长度清零，否则会把上一次的残留数据一起发出去，CRC 对不上，主机只会报通信错误，看不到异常码。

5. 避坑：联调里最容易翻车的五件事

下面这五条是这类工程在实际联调中反复出现的，每条按现象、原因、解决写，能对号入座就别从头查。

5.1 通信层：收不到、收半包、CRC 报错

现象一：主机一直超时，从机像没上电。先量 485 的 A/B 差分电压，再看方向脚。常见原因是 A/B 接反，或者方向脚默认电平被外部上拉成发送态，从机上电就把总线拉住，主机什么都收不到。解决：断开从机，用主机单独发帧，示波器看差分信号有没有；确认方向脚初始化后立刻拉低进接收态；总线两端各加一个 120Ω 终端电阻，中间节点不要加。

现象二：短帧正常，长帧偶发 CRC 错。大概率是帧结束判定太早。有人用固定 3.5ms 定时器判帧尾，在 115200 下这个时间足够收完一整帧，但配合 DMA 半传输中断时会在帧中间触发解析。解决：帧结束只认空闲中断，定时器只做兜底；解析前用 DMA 剩余计数算实际长度；把接收缓冲区从 64 字节加到 256 字节，避免 0x10 长帧被截断。

现象三：通信一段时间后必丢一帧。看发送函数的方向脚拉低时机。用 TXE 判断“发完”会截掉最后一个字节，主机侧表现为该帧 CRC 错，下一帧又正常。解决：等 TC 置位再拉低方向脚，中断发送放在TxCpltCallback里做；拉低后留几十微秒再开接收。

5.2 应用层：地址差一、字节序、写后读不回

现象四：主机读 40001，从机回的是第二个寄存器的值。这是 0 基和 1 基混用。组态软件里填 40001，实际 PDU 里是 0x0000；如果解析时没减 1，就会整体偏移一个寄存器。解决：全工程统一在解析入口转成 0 基，应用层只认 0 基；文档里明确写“本设备寄存器表为 PDU 地址”，别用 4xxxx 描述，减少歧义。

现象五：写进去读出来不对，或者写完主机超时。两种原因。一是字节序，寄存器值是大端，浮点占两个寄存器时还有高低字顺序问题，主站和从站约定不一致就会读出乱码。二是写参数后立刻存 Flash，Flash 擦写几十毫秒，超过了主机的响应超时。解决：先回响应帧再启动保存，保存放到主循环低优先级任务里；浮点统一约定高字在前还是低字在前，并在寄存器表注释里写死。

避开这五条，从机基本就能稳定跑起来。真遇到查不动的，抓包工具挂上去看原始字节，比在代码里加十个打印都快。

6. 用主机脚本压一轮：从单帧点调到万帧稳定

单帧能通只说明协议对，长时间跑才暴露时序问题。我一般会写个短脚本做两件事：连续读同一个寄存器一万次，统计超时率、CRC 错率和往返时延；再穿插写操作，验证写后读的一致性。脚本不用复杂，能跑出统计数字就行。

import serial, struct, time 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(addr, func, reg, num): body = struct.pack(">BBHH", addr, func, reg, num) # 大端打包 c = crc16(body) return body + bytes([c & 0xFF, c >> 8]) # CRC 低字节在前 ser = serial.Serial("COM3", 9600, timeout=0.05) ok = timeout = bad = 0 t0 = time.time() for _ in range(10000): ser.reset_input_buffer() ser.write(build(0x01, 0x03, 0x0000, 0x0002)) rsp = ser.read(9) # addr+func+bc+4+crc2 if len(rsp) < 9: timeout += 1 elif crc16(rsp[:-2]) != (rsp[-2] | (rsp[-1] << 8)): bad += 1 else: ok += 1 print(f"ok={ok} timeout={timeout} crc_err={bad} elapsed={time.time()-t0:.1f}s")

脚本里timeout=0.05是按 9600 波特率下一帧往返约 20ms 留的余量，提速后可以缩到 0.01。reset_input_buffer每次发之前清一次，防止上一帧的残留被当成本帧响应，这个细节不做的话统计出来的 CRC 错会虚高。跑完看三个数：超时为 0、CRC 错为 0 才算过；偶尔一两个错还能接受，如果错误率随运行时间上升，多半是缓冲区覆盖或者方向脚时序的问题，回到第 5 章第 3 条查。

进阶一点可以加个随机间隔，模拟多机轮询的真实负载，间隔取 10 到 50ms 随机，看从机在主站不等响应就发下一帧时会不会丢包——真实组态软件的轮询节奏往往比手测激进。从那以后我每次交付带 485 的设备，都会先让这个脚本跑满一万帧再发走，毕竟现场返修一趟的成本，比在工位上多等十分钟高太多。希望帮到你。

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