STM32F407读取智能电表：Modbus/CRC/RS485完整实战

简介：针对STM32 F407ZGT6平台的Modbus协议实现与智能电表读取示例代码，面向嵌入式开发者、工业控制初学者以及需要串口通信调试的工程师，旨在解决智能电表数据采集、Modbus RTU通信以及CRC传输校验等实际工程问题。资源压缩包约33.57MB，以Keil MDK-ARM或IAR工程文件为主，包含源码目录、头文件目录、STM32 HAL库驱动、工程配置文件（.ioc/.mxproject）以及Modbus协议中文版手册，可对照学习协议规范、通信流程与程序结构。截至目前已有1046人学习下载；资料围绕Modbus RTU通信展开，覆盖UART串口参数配置、报文编码解码、CRC-16校验计算和异常处理等关键知识点，代码结构清晰，便于直接移植。借助该资源，读者能快速搭建STM32与智能电表的串口通信实验环境，理解HAL库收发函数与CRC模块用法，掌握工业现场常用的错误检测方法，为后续项目调试、功能扩展和毕设开发提供直接参考。

1. STM32F407ZGT6 读智能电表：Modbus、CRC 与 RS485 是一条完整链路

很多现场项目里，几十台智能电表的数据到不了上位机，原因往往不是表坏了，而是主站和电表之间差了从协议到硬件的一整条链路。STM32_F407ZGT6 上实现 Modbus 协议，就是用一片 Cortex-M4 做主站，通过 RS485 总线按 Modbus RTU 帧格式发读请求，用 CRC16 校验码保证每一帧的完整性，再把电表返回的电压、电流、功率、电度数据解析出来。这个方案成本低、协议透明，适合工业数据采集、能耗监测、物联网边缘网关这些场景。适合的人是懂单片机和串口，但对 Modbus 只听过没跑通过的人。这篇文章会按硬件、帧结构、CRC、排查四条线把它讲完。

2. 硬件链路怎么搭：收发器选型、方向引脚与最小接线

2.1 为什么非加一个 RS485 收发器

F407ZGT6 的 USART 出来的信号是 3.3V 的 TTL 电平，而 RS485 是差分信号，靠 A、B 两线之间的电压差来表示逻辑 0 和 1。两种电平标准完全不同，直接拿单片机的 TX、RX 去接电表，第一是电平不匹配，第二是没有差分驱动能力，距离稍远就无法通信。常见做法是加一片 RS485 收发器，比如 SP3485 或 MAX3485，注意这两款是 3.3V 供电版本，和 F407 的 IO 电平直接匹配。市面上有些模块用的是 MAX485，那是 5V 器件，接 3.3V 单片机时虽然也能跑，但长期稳定性差，推荐直接买 3.3V 版本。

收发器一侧接 USART 的 TX、RX 和方向控制脚，另一侧接 A、B 差分线。半双工通信意味着同一时刻只能发或只能收，方向切换由 DE/RE 引脚控制，通常把 DE 和 RE 短接后接到一个 GPIO，发送前置高，发送完成拉低，回到接收状态。

2.2 方向控制引脚：发送完成后不能急着拉低

半双工最容易被坑的细节在于方向切换的时机。HAL_UART_Transmit 这个函数返回时，数据只是从单片机送到了 USART 发送缓冲区，移位寄存器可能还在一个字节一个字节往外移。如果此时立刻把 DE 拉低，整帧的最后几个字节会被裁掉，电表收到的帧长度错误，直接不回帧。

我一般会先等 USART 的 TC 标志置位，确认移位寄存器彻底发送完成，再拉低方向引脚。代码写法如下：

#define RS485_DIR_ON() HAL_GPIO_WritePin(RS485_DIR_GPIO_Port, RS485_DIR_Pin, GPIO_PIN_SET) #define RS485_DIR_OFF() HAL_GPIO_WritePin(RS485_DIR_GPIO_Port, RS485_DIR_Pin, GPIO_PIN_RESET) // 发送读请求后切换回接收 RS485_DIR_ON(); HAL_UART_Transmit(&huart1, req, 8, 50); while (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_TC) == RESET); RS485_DIR_OFF();

这段代码里最关键的是那个 while 等待 TC 标志。TC 代表发送移位寄存器已经空，此时总线上的最后一个字节确实发完了，再拉低 DE 就不会斩帧。波特率 9600 时一个字符大约 1.04ms，8 字节帧加上前后保护时间大约 9ms，这个时序配合常见的 500ms 超时完全够用。

2.3 最小接线清单与供电注意

按最小系统来，F407ZGT6 到收发器只需要三根线：TX、RX、方向 GPIO。收发器到电表需要 A、B 两根差分线，另外建议把双方 GND 连起来。很多人在实验室用通信正常，一到现场就乱码，多半是 GND 没接或者 A、B 接反。长距离现场还建议用带隔离的 RS485 模块，防止电表侧地电位不一致把单片机打坏。

总线末端要不要加 120 欧终端电阻取决于距离和节点数。几十厘米的台架上完全不用加；超过 100 米或者挂多块表时，在总线两端各并一个 120 欧电阻会更稳。接线顺序用手拉手串联，不要接成星形拓扑，反射会把波形搅乱。还有一个值得养成的习惯：先把电表单独接一个 USB 转 485 小板，用 PC 串口工具把地址、波特率、寄存器地址全部验证一遍，再往单片机接。这一步能筛掉一大半的协议理解问题。

3. Modbus RTU 帧结构与电表寄存器表

3.1 RTU 帧和 03/04 功能码的选型

Modbus 协议分 ASCII 和 RTU 两种模式，工业电表几乎全部走 RTU。原因是 RTU 用二进制传输，同样一条报文比 ASCII 短近一倍，效率高。RTU 帧由四段组成：从站地址 1 字节、功能码 1 字节、数据段 N 字节、CRC16 校验 2 字节。数据段长度按功能码不同而变，CRC 永远是低字节在前发送。

帧与帧之间要求有至少 3.5 个字符的空闲时间，作为接收方判断「一帧结束」的依据。在 9600 波特率 8N1 下，3.5 个字符约 3.75ms，接收侧不需要依赖帧尾标志，而是靠这个空闲间隔来切帧。下面这张表是 RTU 请求帧的固定结构：

功能码 03 和 04 是读电表数据最常用的两个。03 读保持寄存器，04 读输入寄存器。很多电表厂家的电压、电流放在输入寄存器里，电度累计值又放在保持寄存器里，哪个数据配哪个功能码必须查说明书，不能靠猜。用错功能码时电表会回异常帧，功能码回 0x83 或 0x84，附带异常码 02 表示非法数据地址。

3.2 从电表说明书里找到寄存器表

读取电表前最重要的准备工作是拿到寄存器映射表。不同厂家、不同型号的 Modbus 电表，寄存器地址和宽度差异非常大。以我调试过的某厂三相电能表为例，它的映射表大致长这样：

注意两点：第一，同一张表里 16 位和 32 位混着排，32 位数据是两个连续寄存器拼接出来的，拼接顺序要看说明书是「低字在前」还是「高字在前」，调反了功率和电度数值会放大 65536 倍；第二，0.1V/LSB 这种缩放系数必须按手册折算成真实工程量。读回来的裸寄存器值先不急着换算，先把原始 hex 值和电表液晶屏的显示值对一遍，对上了再写换算逻辑。

电表通信参数一般印在表壳铭牌上或者藏在菜单里，常见默认组合是地址 1、9600 8N1。也有部分表默认 2400 甚至 4800，用错波特率的表现是收得到帧但 CRC 永不过，因为字节流已经错位。

3.3 构建一条读请求并把它发出去

有了映射表，读某个数据就是构造一条 8 字节请求帧，发出去等响应。发送逻辑固定，可以封装成函数：

void modbus_send_read_request(uint8_t dev_addr, uint16_t start_reg, uint16_t reg_cnt) { uint8_t req[8]; uint16_t crc; req[0] = dev_addr; // 电表从站地址 req[1] = 0x03; // 03：读保持寄存器 req[2] = (start_reg >> 8) & 0xFF; // 起始地址高字节 req[3] = start_reg & 0xFF; // 起始地址低字节 req[4] = (reg_cnt >> 8) & 0xFF; // 寄存器数量高字节 req[5] = reg_cnt & 0xFF; // 寄存器数量低字节 crc = modbus_crc16(req, 6); // CRC 只算前 6 个字节 req[6] = crc & 0xFF; // 低字节在前 req[7] = (crc >> 8) & 0xFF; RS485_DIR_ON(); HAL_UART_Transmit(&huart1, req, 8, 50); while (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_TC) == RESET); RS485_DIR_OFF(); modbus_rx_start(); // 开启接收 }

参数说明：dev_addr 是电表地址，start_reg 是寄存器起始地址，reg_cnt 是连续读的寄存器个数。一次读多个连续寄存器比逐条读单条高效得多，比如有功功率和电度如果地址连续，一条 03 报文全读回来，再在本地拆字节。modbus_crc16 是下一章的函数，这里先调用。

接收侧我习惯用字节中断加定时器判帧尾：每收到一个字节，把计数加一，同时复位一个软件定时器；定时器超时（约 4ms，大于 3.5 字符时间）没等来下一个字节，就认为一帧结束，交给解析函数处理。用 DMA 加空闲中断也可以，但 DMA 版本依赖具体 HAL 版本，字节中断加空闲定时器在任何库上都通用。

4. CRC16 校验：Modbus 的底线与两套实现

4.1 为什么是 0xFFFF 和 0xA001

Modbus RTU 的 CRC16 属于 CRC-16/IBM 的一种变体，协议里写死三个参数：初值 0xFFFF、多项式 0xA001、结果低字节先发。0xA001 是 0x8005 反过来的写法，因为在软件实现里要右移逐位计算，所以把多项式反转后参与异或。初值 0xFFFF 是为了保证全零数据也能算出非零校验值，避免把「一帧全是 0」和「没有数据」混淆。

校验范围是从站地址的第一个字节开始，到数据段的最后一个字节结束，算完后再把结果拼到帧尾，CRC 自己不算进校验范围。校验范围、初值、多项式三项组合起来，这个 CRC 才能和电表侧算出来的值一致。如果接收端校验也拿同一套算法重算整个帧，那 CRC 已经拼在末尾的数据必须先把最后两个字节去掉再算，这是新手上手最常见的翻车点。

4.2 逐位法：适合刚调通的第一版

逐位法是最好理解、也最容易调试的实现。思路是每个字节都从最低位开始，逐位右移，遇 1 就异或多项式：

uint16_t modbus_crc16(const 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 逐位右移 8 次。每次移位前看最低位是不是 1，是 1 就右移一位后异或 0xA001，等于模拟了一次多项式除法。F407 主频 168MHz，算一条 256 字节的帧也只需要微秒级时间，逐位法在读取电表这种低频轮询场景里不会成为瓶颈。

验证方法是拿一条已知帧对拍：请求帧 01 03 00 00 00 02，前 6 字节算出来 CRC 应为 0x0BC4，帧尾按低字节在前拼成 C4 0B。如果算出来是 0xBC04 或者 0x0BC4 但高低字节反了，问题多半出在拼帧那一段而不是算法本身。

4.3 查表法：把 CPU 花销降下来

当系统里同时要轮询多块表、每块表请求响应几百字节时，逐位法也能扛住，但查表法更省。查表法把 0~255 每个字节的 CRC 结果预计算出来，运行时每个字节只需一次查表和一次异或：

static uint16_t crc_tab[256]; void crc_tab_init(void) { for (uint16_t i = 0; i < 256; i++) { uint16_t c = i; for (uint8_t j = 0; j < 8; j++) { if (c & 0x0001) c = (c >> 1) ^ 0xA001; else c >>= 1; } crc_tab[i] = c; } } uint16_t modbus_crc16_table(const uint8_t *data, uint16_t len) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < len; i++) crc = (crc >> 8) ^ crc_tab[(crc ^ data[i]) & 0xFF]; return crc; }

逻辑说明：查表法的核心公式不用背，理解成「把当前 crc 的高 8 位异或新字节后，用这个值去查一份预生成的表，再和 crc 右移 8 位的结果异或」。crc_tab_init 在系统初始化时调用一次，之后求 CRC 每字节只做一次查表和两次异或运算。如果项目里其他地方也用同样的多项式，这套表可以复用。两种算法算同一帧结果是完全一致的，换实现方案时不需要改协议逻辑。

接收端校验响应的写法要特别留意：

// rx_buf: 收到的完整帧, rx_len: 帧长度(含末尾2字节CRC) uint16_t recv_crc = (rx_buf[rx_len-2]) | (rx_buf[rx_len-1] << 8); uint16_t calc_crc = modbus_crc16_table(rx_buf, rx_len - 2); // 排除CRC自己 if (recv_crc != calc_crc) { // 丢弃或重发请求 }

这里先把帧尾的两个字节按低字节在前拼出来，再用去掉 CRC 后的数据重算一遍，两者相等才认为这一帧传输干净了。现场总线上的干扰、波特率不匹配、A/B 接反，最终都会表现为 CRC 失败，所以这一关必须卡得严。

5. 读电表踩过的 5 个坑：现象、原因与解法

5.1 请求发出去了，电表一直不回答

现象是逻辑分析仪或者示波器能看到 TX 波形正常，电表却始终不回帧，等待超时后主站报错。排查顺序先是物理层：A、B 反接是最常见的物理层错误，互换两根线后立刻恢复的情况我遇到过不止一次。其次是 GND，485 是差分传输，理论上不共地也能通信，但实际现场不共地常常导致接收端电压超出共模范围，偶尔能通、偶尔乱码。再次是从站侧参数不对，地址、波特率、校验位和电表设置不一致时，电表收到帧但认为不是发给自己的，或者无法识别字节流，根本不会应答。最后确认电表是不是真的支持 Modbus，有些国网表出厂只走 DL/T 645 协议，那得在表前挂协议转换模块，跟单片机没关系。解法是把这些检查项拎一遍，先用 USB 转 485 加串口助手单独测表，确认表会回帧再往 MCU 上接。

5.2 帧收到了，CRC 校验却总不过

现象是响应帧长度正确，字节也能对上，但主站计算 CRC 和响应帧尾不一致。这个坑基本出现在三个位置。一是把响应帧末尾的 CRC 也纳入了重算范围，算法把最后两个字节算进去之后自然对不上；二是自己拼请求帧时 CRC 高低字节顺序写反，电表收到后也算不对，直接不回帧；三是波特率轻微偏差或主站收到了电表上电时的自检乱码，字节流整体错位，CRC 必然失败。解法是在调试阶段把主站收到的原始 hex 打印出来，和串口助手抓到的同一帧逐字节比对，排除收发链路问题后，剩下的基本是字节序问题，把帧尾两个字节调换位置再测。

5.3 数据能读回，数值却明显不对

现象是 CRC 校验通过，寄存器也能读出值，但换算出来的电压是 6553.5V 或者功率值忽大忽小。这个坑的根源基本在寄存器表的理解上。常见情况有三种：把保持寄存器和输入寄存器搞混，用 03 去读本该用 04 的数据项，读到的是另一个地址空间的数据；32 位数据的高低 16 位拼接顺序反了，导致电度值差 65536 倍；表计说明书标注的缩放系数没乘上，比如 0.1V/LSB 的电压读回 2311，直接当 2311 显示，而实际电压是 231.1V。解法是先拿寄存器原始值对照电表液晶屏当前显示值，锁定读的是哪一项，再按手册的系数折算。可以把每个数据项单独打印原始 hex，跟屏显值对上了再做批量换算，一次全做完就很难排查了。

5.4 轮询几圈之后总线直接卡死

现象是单帧测试都正常，循环轮询几轮后从某一帧开始电表不回，之后整个总线像死了一样，必须复位才能恢复。原因有两个方向。一是发送帧间隔填得太短，主站发完请求后立刻发下一轮，电表上一次响应的尾部字节还没有离开总线，两帧在线上撞在一起，电表直接丢弃；二是接收超时设置太短，电表响应本身需要几十毫秒，主站超时后在同一方向引脚打开的状态下重发，自己发的请求又进了自己的接收缓冲区，导致后续解析错乱。解法是强制在每轮请求之间留足间隔：从上一帧最后一个字节算起，至少等 3.5 个字符的空闲时间，再发下一帧。我在 9600 波特率下的习惯是轮询周期不小于 200ms，超时设 500ms，重试最多 2 次，重试前先拉低方向脚并清空接收缓冲。

5.5 同一个地址的寄存器，不同厂家的电表定义完全不同

现象是同一份报文换了另一块电表，数据全部变成乱值，CRC 却全对。原因很简单：Modbus 协议只规定了帧格式和功能码，寄存器地址空间完全是厂家自定义的。A 厂的电压在 0x2000，B 厂的电压可能就在 0x0000，连 16 位还是 32 位都可能不同。解法是每接一款新电表，把寄存器表录入一个结构体数组，表头带上表型号、地址、功能码、位数、缩放系数，程序里按表索引读取。我调试时会在项目里维护一张「设备参数卡」，每款表对应一份配置，换表不换代码，只换配置结构体。把寄存器表从代码里彻底拆出来，后面上量维护会轻松很多。

6. 单表跑通之后，我习惯先做三件事

第一件事是抓帧存档。我把电表响应帧的原始 hex 和解析后的物理量同时打印出来，连续跑两个小时，确认没有乱码、没有偶发丢帧。这个存档既是我后面跟电表厂家沟通的依据，也是回归测试的基准数据。第二件事是验证重试逻辑：手动把总线拔掉，确认超时、重试、报错流程按预期走，而不是死等一帧。第三件事是把 32 位数据的字节序用两种常用组合各测一遍，确认功率和电度解析结果合理，再固化到驱动里。这三件事做完，我才认为这套读取逻辑可以交出去。现在我的习惯是上传新表前先单独加电，用串口助手看它上电瞬间发不发自检帧、寄存器地址能不能读通，确认过了再挂总线。这个习惯帮我挡掉了很多「代码没问题，但表本身不按套路」的现场问题。Modbus 读电表这条路不难，难的是每一步都对协议本身保持敬畏，地址照着说明书抄、CRC 用已知帧验证、字节序逐项实测，整体跑通只是时间问题，希望帮到你。

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