STC32G实现Modbus RTU从机：兼容多组态软件的完整指南

做嵌入式这些年，Modbus RTU大概是我接到次数最多的通信需求。前阵子客户那边提了一个升级要求：把原来用标准51单片机做的一台采集从机整体换成STC32G，上位机还是原来的组态软件，而且要求换芯之后直接通讯、不改画面、不重做工程。客户原话是"最新的版本，多个组态软件都得兼容"。这话听着简单，真做起来牵扯到的东西不少——从机源码的架构、寄存器规划、CRC校验、帧间隔处理、各家组态软件的地址习惯差异，任何一环不处理好，现场就是"连不上""偶尔超时""读出来全是乱码"之类的毛病。这篇文章就把这个项目从需求到源码、再到多种组态软件联调的过程完整拆开讲一遍，适合正在做单片机从站、或者正准备把老51项目迁到STC32G上的开发者参考。

1. 这个项目到底在解决什么问题

1.1 需求拆分：从老51换到STC32G的真实理由

先交代一下原始设备的背景。老设备用的是8位经典51内核单片机，功能很简单：采集8路模拟量信号，做成千里迢迢走Modbus RTU从站，上位机通过一只USB转RS485模块轮询读取。设备用了好几年，问题出在几个地方：一是主频低，处理浮点运算和滤波算法时稍微有点吃力；二是单片机的Flash空间不够，客户想在从机里加一段自诊断逻辑和参数掉电保存，程序快塞满了；三是老型号供货越来越不好拿，客户项目有交付周期压力，不想再为老芯片的库存发愁。

所以需求就变成了：用STC32G12K128这颗增强型8051核心的单片机，重新实现一个Modbus RTU从机，寄存器布局尽量和老设备保持一致，上位机组态工程里的变量、画面、报警全部不动。也就是说，从机代码可以重写，但从Modbus协议的视角来看，必须"看起来跟老设备一模一样"。

这里有个容易被忽略的点：客户说"最新的版本"，指的不仅仅是单片机换新款，还包括从机源码本身要整理成可维护、可扩展的版本。老项目里那种一个main函数写到底、中断里做所有事的写法，这次我建议彻底重构。因为后续客户可能会加功能码、加寄存器、加第二路串口，代码结构不清，后面改一次崩一次。

1.2 Modbus RTU为什么在组态通信里还是主力

很多人觉得Modbus太老，但现实是组态软件、触摸屏、PLC、仪表、采集模块，Modbus RTU的覆盖率依然是最高的。原因也很朴实：它简单到几乎没有门槛。一条RS485总线，主站轮询，从站应答，请求就是一个地址加功能码加寄存器范围，响应就是把数据塞回同样格式的帧里，再加上两个字节的CRC校验。

Modbus RTU的帧格式没有任何"帧头帧尾"这种东西，它靠时间间隔来分帧。协议规定：

• 帧内字符间隔小于1.5个字符时间
• 帧间间隔大于3.5个字符时间
• 波特率不同，这些毫秒数就不同

比如9600波特率、8位数据位、1位停止位，一个字符大约1.13ms，3.5字符时间大约3.96ms。从机必须在收完一帧后等待至少这么长时间，才能确定一帧已经结束，然后开始解析。

组态软件所以能轻轻松松连上各路设备，就是因为它只需要发标准Modbus报文就行。从机只要老老实实按协议回复，不管上位机是哪家组态软件，都能对上话。但"按协议回复"这句话背后，还藏着寄存器地址偏移、字节序、超时时间、功能码支持范围这些细节，后面我会专门展开。

2. STC32G做从机的关键资源盘点

2.1 主频与波特率：先把计时算清楚

STC32G系列主频可以跑到30MHz以上，我这套源码默认按24MHz系统时钟调校的。为什么选24MHz？因为在这个频率下，定时器做波特率发生器时可以做到很低的误差，而且整个芯片的功耗、电磁干扰也相对可控。

以串口1的波特率9600为例，STC32G的定时器1作为波特率发生器时，重载值计算公式是：

// 系统主频 FOSC = 24000000 Hz // 波特率 Baud = 9600 // 定时器1重载值（1T模式） BRT1 = 65536 - FOSC / (4 * Baud); // 即 65536 - 24000000 / 38400 = 65536 - 625 = 64911 = 0xFDAF

这个计算结果几乎零误差。实际配置时还要注意定时器1需要设置成1T模式还是12T模式，两者算出来的重载值差别很大。用STC32G的时候，如果照搬老51的12T计算公式，波特率直接偏到姥姥家。

不同主频对应不同波特率的误差我整理了一张表，方便参考：

串口初始化时还必须确认波特率发生器的时钟源选择。STC32G提供了T1/T2/T3/T4等多组定时器，串口1常用的是定时器1或者定时器2作为波特率发生器。实测下来优先选定时器2更省心，因为这样定时器1可以腾出来做别的计时任务，不会互相打架。

2.2 硬件CRC模块到底用不用

STC32G12K128内部带了硬件CRC模块，理论上可以算CRC16。但这颗芯片的硬件CRC更多是为"CRC8/CRC16/CRC32多种多项式"设计的，并不专门针对Modbus那条CRC16多项式0x8005的反向算法0xA001。硬件模块需要配置多项式、初值、输入输出反转，用起来初始化代码不少。

我自己实测的结论是：Modbus RTU从机完全不需要用硬件CRC。原因很简单——从机回包的数据量撑死几十字节，用软件查表法算CRC16，在24MHz主频下耗时只有几十微秒，对整机响应时间的影响可以忽略。而硬件CRC需要额外适配不同芯片的寄存器细节，移植性变差。

软件CRC用查表法还是逐位法？查表法按字节处理，每秒能处理几十万字节，挪到从机里完全杀鸡用牛刀。但查表法要占512字节的Flash放两张表，对STC32G的128KB Flash来说毫无压力。逐位法则省空间但CPU开销大，不推荐在项目里用。

我最后打包进源码的是经典Modbus CRC16查表实现：

unsigned int ModbusCRC16(unsigned char *pData, unsigned int len) { unsigned int crc = 0xFFFF; unsigned char i; while (len--) { crc ^= *pData++; for (i = 0; i < 8; i++) { if (crc & 0x0001) { crc >>= 1; crc ^= 0xA001; } else { crc >>= 1; } } } return crc; }

这里有个非常容易踩的坑：这个函数返回的CRC是高字节在前、低字节在后，但Modbus RTU协议规定报文里是先低字节后高字节。很多人第一次写从机，直接把函数返回值往发送缓冲区里塞，结果上位机永远报CRC错误。正确做法是把高低字节反过来：

txbuf[txlen++] = (unsigned char)(crc & 0xFF); // CRC低字节先发 txbuf[txlen++] = (unsigned char)((crc >> 8) & 0xFF); // CRC高字节后发

2.3 RS485方向控制的边界时序

如果只是点对点RS232收发，这篇源码可以省掉一半功夫。但组态软件那套基本都走RS485总线，而RS485是半双工，从机必须正确控制DE/RE引脚的收发方向。

这里最关键的时序是：发送完最后一字节之后，不能立刻把DE拉低，必须让移位寄存器把最后一个停止位完整送出去。否则最后一个字符会被切断，上位机收到的帧少了CRC或者末尾字节，直接判超时。

STC32G的串口发送完成中断（TI）会在发送停止位时触发，但此时停止位还没完全送出。稳妥的做法是，在TI中断里启动一个微延时，至少延时半个字符时间后再拉低DE。或者更简单粗暴一点，在TI中断里直接等一两个NOP循环，实测9600波特率下一个字符约1.13ms，半个字符延时约0.6ms，用定时器或循环都能凑出来。

我习惯在发送完成后开一个定时器0做短暂延时，延时到了再拉低DE。这样接收方向切回来非常干净，不会吞掉自己的尾巴。

3. 从机源码的核心骨架

3.1 帧接收状态机的正确打开方式

Modbus RTU从机最核心的部分就是"如何把串口收到的一堆字节还原成一帧"。前面说过，协议靠时间间隔切帧。实现上有两种常见方案：

• 方案一：接收完每个字节都重置一个帧间隔定时器，定时器溢出才认为帧结束。
• 方案二：直接使用串口的空闲中断。

STC32G的串口没有专门的空闲中断，所以方案一是最通用的。我的做法是：串口1接收中断只负责把SBUF里的数据搬进接收缓冲区，同时清零一次帧间隔定时器。帧间隔定时器用定时器3，配置成每1ms中断一次，中断里对超时计数器做累加，累加值超过设定阈值就置标志位，主循环查标志位后解析帧。

关键代码骨架：

// 定时器3中断，每1ms触发一次 void Timer3_Isr(void) interrupt 14 { static unsigned int cnt = 0; cnt++; if (cnt >= MB_FRAME_GAP_MS) // 一般为5~20ms { cnt = 0; mb_frame_ready = 1; // 表示距离上一字节接收已超过帧间隔 } } // 串口1接收中断 void UART1_Isr(void) interrupt 4 { if (RI) { RI = 0; rxbuf[rxlen] = SBUF; if (rxlen < MB_RX_BUF_SIZE - 1) { rxlen++; } mb_gap_timer_reset = 1; // 告诉定时器线程重置超时计数 } }

帧间隔阈值怎么选？协议说3.5字符时间，但实际工程建议留余量，通常取5~20ms之间。9600波特率下10ms是比较稳的值。数据流速高到115200时，可以把阈值缩到5ms，避免响应太迟钝。这个参数我单独拎出来做成宏定义，方便不同波特率下调整。

这里还要注意一个坑：主循环里解析一帧时，必须立刻清空接收缓冲区和长度，否则下一帧数据到了会拼到上一帧尾巴上。通常在帧就绪标志被置位后，先缓存当前rxlen作为帧长度，然后马上把rxlen清零，再做解析。

3.2 寄存器映射表与功能码分发

Modbus从机的灵魂其实是寄存器表。上位机不管你的内部变量叫U8_AI1还是g_fTemperature，它只知道地址。所以代码里要维护一张"从机地址到内部数据"的映射关系。

我在这套源码里用了最简单也最不容易出错的方案：一块连续的16位寄存器数组。保持寄存器设计成最多100个寄存器，地址从0x0000到0x0063，每个寄存器都是16位宽度，高字节在前。

#define MB_REG_HOLDING_START 0x0000 #define MB_REG_HOLDING_COUNT 100 unsigned int holding_regs[MB_REG_HOLDING_COUNT];

实际数据怎么进这个数组？我建议做一张映射表，把寄存器地址和内部变量对应起来。比如某个温度变量是浮点型，占了两个连续16位寄存器，那就在采集更新时把两个半字拆开填进去。这样Modbus协议层完全不用关心数据类型，只负责按地址搬运16位数据就够了。

寄存器区规划建议：

功能码方面，对组态软件来说最常用的就是三个：03读保持寄存器、06写单个寄存器、16（0x10）写多个寄存器。这套源码把这三个全部实现，再加了一个支持广播地址0的功能。注意：广播地址只允许写操作，从机不回帧。

分发逻辑非常直白：

switch (frame[1]) { case 0x03: HandleReadHoldingRegisters(frame, len); break; case 0x06: HandleWriteSingleRegister(frame, len); break; case 0x10: HandleWriteMultipleRegisters(frame, len); break; default: SendExceptionResponse(frame[0], 0x01); // 非法功能码 break; }

寄存器越界检查一定要做完整。比如某次请求读起始地址0x0060、数量20个寄存器，实际总数只有100个，那从机应该返回异常码0x02非法数据地址，而不是把越界后的数据硬填出来。很多人写的从机在这一点上很随意，结果就是上位机读数偶尔会跳出一堆0或随机值。

3.3 响应超时与异常码的讲究

从机响应太快有时候反而不是好事。组态软件在发出请求后，会等一个固定的响应超时时间，通常默认是几百毫秒。从机哪怕只用1毫秒就回包，也不会有问题。但反过来，如果从机回包太慢，超过上位机超时时间，上位机就会判定通信超时，然后重发请求，严重时整个网络会卡成狗。

STC32G从机实际响应耗时主要花在：CRC计算（几十微秒）+ 组包（几十微秒）+ 串口发送。整帧回包在9600波特率下发送几十字节也就几十毫秒，这个速度完全来得及。

异常码返回也要规范。常见的异常码含义：

组态软件收到异常码之后，虽然也会在界面上显示"通信错误"，但至少协议是通的，排查问题比"完全没反应"要快得多。我建议从机代码里把异常响应做成一个公用函数，任何非法请求都走同一出口。

4. 多种组态软件适配实战经验

4.1 先说结论：协议是通的，习惯是乱的

我在联调阶段同时测了三款组态软件，为了叙述方便下文分别叫它们A软件、B软件、C软件。A软件是老牌国产组态，B软件是上位机加数据采集类软件，C软件是某款HMI触摸屏自带的组态工具。三款软件底层都是标准Modbus RTU主站，但工程配置界面、寄存器地址编号方式、默认超时参数差别非常大。

实测得到的第一条结论是：从机代码不需要为某款软件写特殊分支，只需要在寄存器地址编号上统一一个规则，然后针对每款软件把"起始地址怎么填"写成说明文档交给现场。真正要动的，永远是上位机那边的配置项和地址换算，从机端保持标准Modbus语义即可。

下面是三款组态软件在配置同一个从机时的关键差异对照：

"寄存器起始编号"这一行就是最经典的坑：A软件里你想读从机保持寄存器地址0x0000，画面变量里地址填"0"，它自动映射到Modbus地址40001；B软件要求你填"1"，它内部减1之后才得到真正的Modbus地址0x0000；C软件又是另外一套映射。如果你从机端手册只写"保持寄存器地址从0开始"，现场工程师按B软件的1去填，读到的就是0x0001，完全错位。

所以我在最终交付的文档里做了一张换算表：Modbus协议地址、A软件填法、B软件填法、C软件填法一一对应，现场照着抄就错不了。

4.2 浮点数的字节序不能想当然

Modbus协议本身只定义寄存器是16位的，怎么存浮点数协议管不着。组态软件读32位浮点数时，默认从4个连续寄存器的前两个字节开始解析。问题就来了：同样一个float数据，按大端模式和小端模式存，在寄存器里表现出来的顺序完全不同。

最常见的三种32位浮点存储顺序：

老设备原来用的是标准大端ABCD，如果从机源码里直接照搬老代码，A软件这边读出来完全正常，B软件那边数字就变成了天文数字。实测B软件读一个1.5的浮点，画面上显示的是1.82121e-41这种让人抓狂的值，其实就是字节序反了。

我的做法是：从机浮点存储统一采用标准IEEE754大端（ABCD），然后在上位机变址配置里把每款组态软件的浮点顺序改成大端。A软件默认就是大端，不用动；B软件在变量类型里选"浮点-高字在前"；C软件需要把寄存器顺序改成"高字低字"。

如果实在不想动组态画面，还有一个土办法：从机内部把浮点数按组态软件的默认顺序存，也就是在写入寄存器数组之前做一次字节交换。这个方案能保画面完全不改，但代码可读性变差，以后换组态软件又得改回来，我建议除非客户百般要求，否则还是统一大端更干净。

4.3 轮询速度与通信超时的平衡

组态软件默认轮询周期各不相同，A软件默认1000ms扫一遍全部变量，C软件能做到200ms甚至100ms。同一个从机，面对不同轮询速度，表现差异会非常明显。

我在测试时故意把C软件的采集周期压到100ms，它一个周期内会同时读模拟量、设备信息、报警值等多段寄存器，请求频率非常高。此时从机如果响应稍慢，或者帧间隔判定过于保守，就会出现上位机超时然后反复重发，总线上一片混乱。

解决办法有两头。一头是上位机端：把采集周期放宽到200ms以上，把"最大寄存器读取数"调大，让一个请求尽量读取整段连续寄存器，减少请求次数。另一头是从机端：确保帧接收缓冲足够大、解析逻辑足够快、响应立即组包立即发送。STC32G主频24MHz完全没有性能问题，真正拖后腿的往往反而是我前面提到的DE切换延时——如果你发送之后磨磨蹭蹭过2ms才允许下一次接收，高速轮询肯定扛不住。

5. 实测中遇到的四个典型问题与排查链路

5.1 现象：A软件正常，B软件偶发超时

这个现象很典型，A软件默认1000ms轮询，B软件默认300ms轮询。从机端帧间隔阈值我当时设成20ms，按说足够区分帧间间隔了。但B软件重试几次之后就报"通信超时"，A软件从头到尾都是绿的。

排查时先用串口抓包，一路抓下来发现B软件发出请求之后，从机确实回了包，但B软件认为超时。仔细看时间戳，从机响应花了大约35ms——听着不多，但B软件的响应超时初始值只有200ms，按理说35ms也够。真正的问题出在B软件重发机制上：它收到一个非法帧（比如CRC错误），会立刻重发请求，而旧请求的响应还在总线上回着，两帧叠加导致总线碰撞。

根因其实很简单：从机发送完毕之后DE拉低得太慢。我前文说的"发送停止位后延时再拉低DE"，延时时间用的是0.5个字符时间，但实际它约等于0.6ms。问题出在B软件那边轮询速度快，从机DE还没完全释放接收方向，下一帧请求已经到了，结果请求的第一个字节被自己发送电路和接收电路打架吃掉了。

修正方法：DE拉低的延时缩短到只保证停止位发完即可，用定时器精确延时0.2个字符时间；同时把从机回复前的处理时间尽可能压缩。修完之后，300ms轮询下连续跑了两个小时，零超时。

5.2 现象：读浮点数全是天文数字

这个就是4.2节说的字节序问题。第一天联调时A软件读设备版本号这种16位整数完全正常，一读模拟量浮点就乱。一开始我还怀疑是寄存器偏移的问题，后来把从机内部寄存器数组通过串口调试打印出来，发现内部数据是对的，问题只出在上位机解析顺序。

排查链路给各位参考：

1. 先用串口助手手动发03功能码，读两个连续寄存器，记录原始值
2. 把原始值按IEEE754拆解，确认从机发的就是标准大端
3. 到A软件变量定义里把浮点存储顺序改成"ABCD"，立刻正常
4. 到B软件里改成"高字在前"，也正常

整个排查不超过十分钟，但如果不做第2步，光在软件界面里翻来覆去改设置，很容易越改越乱。任何时候都要以"从机发出的实际字节"为准绳，而不是以上位机界面的各种选项为准。

5.3 现象：能读不能写

打开组态软件，读数据都是正常的，画面上的输入框里改数值，按回车，设置值半天不生效；再看通信日志，发现上位机发的是06功能码写单个寄存器。翻从机代码，发现我只实现了03和16两个功能码，06根本没写。这就相当于上位机用左手递东西，从机只用右手接，能接住才怪。

06功能码是单寄存器写操作，帧很短，实现起来十分钟的事。但这次教训是：立项时定了"支持03、06、16"，源码里却只做了03和16，功能码覆盖清单必须逐个打钩验收。另外一个容易漏的是，某些组态软件写单寄存器用06，写多个寄存器用16，如果碰上寄存器比较多，现场可能只触发16而把漏掉的06掩盖掉。

5.4 现象：距离一长就乱码

现场调试时，从机和上位机距离大约60米，用的普通非屏蔽双绞线，连上之后能通，但偶尔冒出来一个CRC错误。近距离测试一切正常，远距离就出问题。这类问题排查思路很固定：

• 先看波形：示波器挂到RS485的A、B两端，看数据帧边沿是否陡峭
• 再看终端电阻：总线两端是否接了120欧姆匹配电阻
• 最后看从机的DE方向切换：发送完最后一个字节到拉低DE之间，有没有把停止位完整发完

这个项目最后发现是终端电阻问题。总线两端都需要120欧姆电阻，现场只在主站侧接了一个，从机侧没接。加上线材不是屏蔽双绞线，信号反射叠加，个别字节被冲掉，CRC就报错了。接上电阻之后，乱码彻底消失。

这里也提醒一句，STC32G的IO驱动能力很强，RS485芯片的驱动也够，但长距离总线必须把硬件底线做好：屏蔽双绞线、双端120欧姆电阻、合理接地。软件只能兜底，不能解决物理层劣化的根本问题。

6. 把这套源码复用到下一个项目的几个建议

6.1 寄存器规划一开始就要留出余量

这次给客户做的寄存器表是紧急拼的，虽然功能没问题，但地址分配不够规整。比如设备信息占了0x0000-0x000F，模拟量占了0x0010-0x0017，报警值占了0x0020-0x0027，中间0x0018-0x001F这些地址就被浪费了。如果客户后来要加一路模拟量，就得往后面顶，跟报警区挤在一起，整个地址表变得很难看。

下次做类似项目，我会在一开始就把寄存器分区写成下面这样：

预留区千万别直接不响应，而是要规规矩矩返回数据或者异常码。很多组态软件初始化时会读一大片连续寄存器来刷新画面，如果中途某个地址不响应，整段读取失败，画面全黑。

6.2 新项目联调顺序按三步走

第一步，从机端自测：用串口调试工具或者一张USB转485的调试板，手动发03、06、16功能码，确认寄存器读写都正常。这一步把从机问题全部消灭。

第二步，接组态软件：随便选一款组态软件，新建工程，配好串口参数和从机地址，只添加几个测试变量，确认通信正常后再把全套变量导进去。

第三步，接真实总线：把从机挂到现场的485总线上，跟其他设备一起跑，观察是否有地址冲突、波形劣化、轮询超时。

这个顺序看似废话，但实际项目里大部分人都是倒着来的——直接从第三步开始，结果现场所有设备都在通信，根本分不清是谁的问题。

6.3 源码管理的版本注释要比客户要求更细

这次客户说"最新版"，说明之前很可能已经给过别人几个版本。所以我这次在源码文件头写清楚了三件事：适用单片机型号、系统主频、支持的组态软件列表及地址映射约定。同时在main函数入口处打印一条初始化的调试信息，把固件版本、寄存器表版本、CRC表版本都打出来。以后客户说"我用的是你原来的旧版本"，拿调试信息一对就知道具体是哪个版本，省掉大量扯皮时间。

最后再说一点个人体会：Modbus RTU从机这东西，协议层并不难，真正的工程难点全在细节里。寄存器地址偏移、字节序、帧间隔阈值、DE切换时序、终端电阻，这些问题任何一个处理不慎，都会以"通信不稳定"的面目出现在现场。把这套源码和排查经验当成一个可复用的框架，比每次接到需求都从头写一遍要靠谱得多。