企业官网建设流程全解析

简介：基于STC32G12单片机的Modbus-RTU主机例程，面向嵌入式开发者与自动化项目设计人员，帮助解决在8051内核单片机上实现工业级主从通信的问题。压缩包内含完整工程源码与辅助文件，共140个文件，其中72个C源文件、62个头文件，另有Keil工程配置、Hex固件、启动汇编及清理脚本等，整体大小仅224KB，便于直接编译与二次移植。内容覆盖UART波特率与校验配置、Modbus帧构造解析、CRC计算、定时超时与错误重试机制，以及应用层数据交互逻辑。目前已有502人学习过该资源，适合具备一定单片机编程基础、需要快速搭建Modbus-RTU主站通信功能的工程师参考学习。通过阅读代码注释和主从机示例，可显著降低协议调试成本，提升项目落地效率。 做了这么多年单片机开发，Modbus-RTU这套东西我一直觉得是被很多人低估的协议。它简单到几个功能码就能跑起来，但真要在工业现场稳定跑，里面的坑一点都不少。最近刚好用STC32G12K128做了一块采集板，要把现场8台温控仪表的寄存器数据轮询回来，再转给上位机，核心就是让这颗单片机作为Modbus-RTU主机。这个例程做完之后踩了不少坑，也沉淀了一些经验，写出来给准备做类似项目的朋友参考。

STC32G12K128这颗芯片，熟悉STC的朋友应该不陌生。它指令集兼容8051，但内部是32位架构，Flash做到128KB，SRAM有12KB，主频能跑到40MHz以上。拿来跑Modbus-RTU主机，资源上绰绰有余。真正要花心思的，其实是协议的状态机设计、超时管理、以及和从机之间的时序配合。下面我把整个例程的设计思路和实现细节拆开来讲。

1. 为什么选STC32G12K128做Modbus-RTU主机

1.1 项目需求与选型思路

先说说这个项目本身。现场有8台温控仪表，每台表里有温度设定值、当前温度、PID参数等一堆数据，需要通过RS485总线汇集到一块控制板上，控制板再根据数据决定是否报警或者联动继电器。这类需求在工控现场非常典型，本质上就是一个小型的数据采集网关。

当时选型的时候也考虑过STM32F103，后来还是选了STC32G12K128。原因很直接：这个项目不需要跑操作系统，不需要复杂的外设资源，Modbus-RTU轮询本质就是一个串口收发加定时器的活，STC32G12K128完全够用。而且STC的片子外围电路简单，3.3V供电，一颗芯片加一片MAX485就能把串口转成RS485总线，硬件成本能压得很低。

选STC32G还有一个实际考虑，它的串口数量足够。这个项目我一共用了两路串口：串口1接RS485总线做Modbus-RTU主机轮询从机，串口2做调试输出，把解析好的数据直接打印出来看。这样开发和调试分开走，不用频繁插拔总线，效率高很多。如果芯片只有一个串口，调试的时候就得反复切换，很痛苦。

1.2 主机模式比从机模式难在哪

很多人觉得Modbus主机简单，不就是发一帧数据出去、等一帧数据回来吗？真上手做一遍就知道了，主机模式的难点在于怎么处理好各种异常情况。从机收到的永远是被动响应，时序是别人给的；主机要做的是主动控制节奏，任何一台从机掉线、回复超时、CRC错误，都不能影响整个轮询循环继续走下去。

在实际项目里会遇到的一个典型场景：8台从机中有一台断电了，如果主机代码写得不健壮，发完请求后就死等这台从机的回复，那么其他7台的数据也全部卡住。整套系统的实时性瞬间崩溃。所以主机程序的核心不是"怎么收发数据"，而是"怎么管理收发过程中的各种状态"。这也是我这个例程里最需要重点设计的部分。

2. Modbus-RTU协议核心细节梳理

2.1 帧结构与3.5字符间隔的判定

Modbus-RTU的帧结构非常简单：从地址1字节、功能码1字节、数据区N字节、CRC16校验2字节。比如读取保持寄存器的请求帧，完整长度就是8字节：地址、功能码0x03、起始地址高字节、起始地址低字节、寄存器数量高字节、寄存器数量低字节、CRC低字节、CRC高字节。

协议里有个关键概念叫帧间隔。RTU模式下，一帧数据的结束不是靠长度判断，而是靠时间间隔判断：接收方在连续收到两个字节之间的时间间隔如果超过了3.5个字符时间，就认为一帧结束了。这个机制在实际代码里非常容易踩坑。

3.5个字符时间怎么算？一个字符包含1位起始位、8位数据位、1位停止位，共10位。以9600波特率为例，1个字符时间是10/9600秒，约1.04ms，3.5个字符就是约3.65ms。我在工程里一般取5ms作为接收超时阈值，留了一点余量，防止干扰信号把字节间隔拉长导致帧被误拆。

这里有个关键设计点：STC32G12K128的串口中断里收到一个字节就立刻把数据放进缓冲区，同时启动一个软件看门狗定时器。每次新字节到来，看门狗重置。当看门狗计时超过5ms还没有新字节进来，说明一帧已经完整收完，主循环就可以去解析了。这个思路比"猜帧长度"可靠得多，因为不同功能码的响应帧长度差异很大，固定长度判断太脆弱。

2.2 常用功能码与CRC16计算实现

Modbus协议里功能码很多，但做主机真正高频用到的就那三四个。我这个例程里重点实现三个功能码：0x03读保持寄存器、0x06写单个寄存器、0x10写多个寄存器。0x04读输入寄存器在另一个测温项目里也用到过，代码结构完全一样，只是功能码和从机寄存器表不一样而已。

CRC16是Modbus-RTU最容易写错的地方。标准Modbus使用的CRC16多项式是0xA001（反向多项式），初始值为0xFFFF。计算过程是：每个字节先和CRC低字节异或，然后右移8次，每次判断最低位，如果为1就和0xA001异或。查表法更快，但单片机资源足够，直接按位算也没问题，一帧数据撑死了也就几十字节，耗时可以忽略。

unsigned short modbus_crc16(unsigned char *buf, unsigned short len) { unsigned short crc = 0xFFFF; unsigned char 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; }

需要注意发送时CRC的字节序。Modbus-RTU规定CRC16低字节在前、高字节在后。很多新手第一次做这个协议，CRC算出来直接高位在前发出去，对端必然报错。我一开始也在这个问题上栽过跟头，后来凡是遇到CRC不对的情况，第一反应就是先检查字节序和初始值。

3. 串口初始化与波特率参数计算

3.1 时钟系统选型：为什么推荐11.0592MHz

STC32G12K128支持外部晶振和内部IRC时钟。如果只是跑跑流水灯、点个OLED，内部IRC完全没问题。但一旦涉及串口通信，波特率精度就直接和时钟源挂钩了，选错晶振会导致通信误码率暴涨。

标准波特率9600、19200、115200这些值，都是从11.0592MHz这个频率推出来的。为什么偏偏是11.0592？因为115200 = 11059200 / 96，9600 = 11059200 / 1152，都能整除。这样定时器分频之后没有误差。如果用了12MHz晶振算9600波特率，算出来的初值必然是小数，只能四舍五入，通信距离一长、线上干扰一多，误码就出来了。

所以我的例程里直接默认外部晶振11.0592MHz。如果你手头板子用的是24MHz内部IRC，也可以跑，但要在初始化函数里把波特率初值重新算一遍，并且实测一下长时间大数据量通信的误码率。

3.2 定时器2波特率发生器配置详解

STC32G12K128的串口1可以选择定时器1或者定时器2作为波特率发生器。我习惯用定时器2，因为它占用的资源和中断逻辑更清晰。关键配置是让定时器工作在1T模式（也就是计数频率等于系统时钟），然后计算出对应的重装初值。

波特率公式是：波特率 = 系统时钟 / 4 / (65536 - RCAP值)。反推RCAP值 = 65536 - 系统时钟 / (4 × 波特率)。代入11.0592MHz和9600波特率：

RCAP = 65536 - 11059200 / (4 × 9600) = 65536 - 288 = 65248 = 0xFEE0

所以T2L装0xE0，T2H装0xFE。如果要跑19200，就是65536 - 144 = 0xFF70。115200就更简单了，65536 - 24 = 0xFFE8。

void uart1_init(void) { // 11.0592MHz晶振，9600波特率，1T模式 T2L = 0xE0; // 低字节初值 T2H = 0xFE; // 高字节初值 AUXR |= 0x11; // T2R=1使能定时器2，T2x12=1选择1T模式 SCON = 0x50; // 串口1模式1（8位UART），REN=1允许接收 ES = 1; // 使能串口1中断 EA = 1; // 开总中断 }

补充一个细节：定时器2用作波特率发生器时，不需要开定时器中断，更不要在中断里做任何事。它纯粹是给串口提供一个时钟节拍。开了中断反而会引入不必要的系统开销，严重时还会干扰串口收发的实时性。

4. 主机轮询状态机与完整例程

4.1 从站轮询表设计与调度逻辑

Modbus-RTU主机的工作模式本质上就是一个循环调度器。它不能同时给所有从机发请求，必须一个一个来：先问从机1，等它回复，处理完，再问从机2，以此类推。这里最关键的是轮询表的组织方式。

我把每台从机的读取需求定义成一个结构体，放在一个全局数组里。这样以后增加从机数量或者改寄存器地址，只需要改表，主循环的逻辑一行都不用动。

typedef struct { unsigned char addr; // 从机地址 unsigned char func; // 功能码 unsigned short start_addr; // 起始寄存器地址 unsigned short reg_count; // 寄存器数量 unsigned int poll_interval; // 轮询间隔，单位ms } PollItem; PollItem poll_table[] = { {0x01, 0x03, 0x0000, 0x000A, 500}, {0x02, 0x03, 0x0000, 0x000A, 500}, {0x03, 0x03, 0x0000, 0x0005, 1000}, {0x04, 0x03, 0x0010, 0x0008, 1000}, };

调度逻辑用状态机实现。系统上电后处于空闲状态，到轮询时间了切换成发送状态，发送完成后进入等待响应状态，收到完整帧后进入解析状态，解析完回到空闲状态等待下一个周期。整个状态机的核心价值，就是把"发送、等待、解析"这三个动作的时序关系理清楚，保证任何情况下程序都不会卡死在某个环节。

4.2 请求帧构建与应答帧解析

构建请求帧这个函数要注意一个设计细节：发送之前必须把接收缓冲区的索引清零。否则上一帧残留的数据会影响下一帧的判断。我先写了一个通用的帧发送函数，所有功能码共用。

void modbus_send_request(unsigned char addr, unsigned char func, unsigned short start, unsigned short count) { unsigned char frame[8]; unsigned short crc; frame[0] = addr; frame[1] = func; frame[2] = start >> 8; frame[3] = start & 0xFF; frame[4] = count >> 8; frame[5] = count & 0xFF; crc = modbus_crc16(frame, 6); frame[6] = crc & 0xFF; frame[7] = crc >> 8; rx_len = 0; // 清空接收缓冲，准备收应答 for (unsigned char i = 0; i < 8; i++) { SBUF = frame[i]; while (!TI); // 等待发送完成 TI = 0; } }

应答帧的解析就稍微讲究了。首先要检查返回的地址和功能码是否和请求一致，防止收到其他从机的数据。如果功能码最高位是1，说明从机返回的是异常码，常见的有0x01非法功能、0x02非法地址、0x03非法数据值。然后要验证CRC，最后才是提取寄存器数据。数据提取时要注意字节序，Modbus默认高字节在前，所以读取16位数据要拼成 (buf[3] << 8) | buf[4] 这样的形式。

4.3 例程代码主体

整个主循环我写得比较简洁，核心逻辑就是状态机+定时查询。应答帧的接收完全靠串口中断后台完成，主循环只做状态判断和超时处理。这样写的好处是实时性好，主循环不会被阻塞。

// 串口1中断接收，后台完成 void uart1_isr(void) interrupt 4 { unsigned char dat; if (RI) { RI = 0; dat = SBUF; if (rx_len < sizeof(rx_buf)) { rx_buf[rx_len++] = dat; } frame_wd = 0; // 重置帧看门狗 } } // 定时器0中断，1ms时基，用于帧超时和轮询计时 void timer0_isr(void) interrupt 1 { ms_tick++; if (frame_wd < 0xFFFF) frame_wd++; } // 主循环 void main(void) { unsigned char i; sys_init(); // 系统时钟初始化 uart1_init(); // 串口1初始化 timer0_init(); // 定时器0初始化 while (1) { // 轮询调度，检查各个从机是否到了轮询时间 for (i = 0; i < sizeof(poll_table) / sizeof(poll_table[0]); i++) { if ((ms_tick - last_poll_time[i]) >= poll_table[i].poll_interval) { last_poll_time[i] = ms_tick; current_item = i; modbus_send_request(poll_table[i].addr, poll_table[i].func, poll_table[i].start_addr, poll_table[i].reg_count); wait_response = 1; break; // 一次只处理一个从机 } } // 等待应答，带超时判断 if (wait_response) { if (frame_wd >= 5) { // 超过5ms没新字节，认为帧收完 if (rx_len > 0) { parse_response(); // 校验并解析应答帧 } else { // 超时无响应，记录错误，跳过该从机 error_count[current_item]++; } wait_response = 0; } } } }

这里有个经验值得说一下：轮询的时候一次只处理一台从机，处理完才进入下一轮循环。不要在一个循环里把8台从机的请求全部发出去再统一收应答。Modbus-RTU是半双工协议，同一时刻总线上只能有一个设备说话，主机连着发多发请求会造成总线冲突。

5. 调试实录与常见问题排查

5.1 典型故障排查速查表

这个例程从开始写到最后稳定运行，我前后调试了两天。大部分时间不是花在代码逻辑上，而是花在排查各种通信异常上。我把遇到的几类问题和解决办法整理成了表格，方便你对照排查。

5.2 调试工具使用与心得

调试Modbus-RTU主机，强烈建议准备一个USB转RS485的转换器，把电脑当成一个从机去响应单片机的请求。这样可以在电脑上用串口调试工具看主机发出来的原始帧，确认帧格式对不对。反过来，也可以让电脑做主机，单片机做从机，验证从机功能是否正常。这套方法在项目调试阶段帮了我大忙。

在调试过程中有一个比较隐蔽的坑：有些从机设备对主机发送请求的间隔是有限制的。工业仪表内部一般也有自己的处理周期，如果主机以极快的速度连续轮询同一台从机，从机可能因为来不及处理而返回异常或者直接不响应。所以轮询间隔不要设得太短，我实测下来一般建议不低于200ms。如果现场设备数量多，可以适当把间隔放大到500ms甚至1s，稳定优先。

关于STC32G12K128的串口还有一个细节：串口中断服务函数里尽量少做事。我的做法是中断里只负责收字节、存缓冲区、重置看门狗计数器，所有的解析和判断都放到主循环里做。这样中断占用时间极短，不容易丢字节，系统的整体实时性也更好。

还有一点和硬件相关。RS485的收发切换引脚（比如RE/DE）在发送完成后一定要及时拉回接收状态。我在第一版代码里发送结束后没有做这个切换，结果就是数据发出去了，但从机的响应全部丢失，后来在示波器上看了半天才定位到是方向引脚一直保持发送状态，导致接收通路被关闭。这个切换动作要在最后一个字节发送完成的标志位TI置1之后立刻执行。

代码写完下载到板子上跑起来那会儿，看到8台仪表的温度数据整整齐齐打印在调试串口上，那种感觉还是很舒服的。Modbus-RTU这套协议本身不难，难的是把它做得稳定可靠，经得起长时间无人值守地运行。希望这个例程和这些调试经验能帮你少走几步弯路，有类似需求的时候可以直接参考。

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