简介基于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做到128KBSRAM有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.04ms3.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.0592MHzSTC32G12K128支持外部晶振和内部IRC时钟。如果只是跑跑流水灯、点个OLED内部IRC完全没问题。但一旦涉及串口通信波特率精度就直接和时钟源挂钩了选错晶振会导致通信误码率暴涨。标准波特率9600、19200、115200这些值都是从11.0592MHz这个频率推出来的。为什么偏偏是11.0592因为115200 11059200 / 969600 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装0xE0T2H装0xFE。如果要跑19200就是65536 - 144 0xFF70。115200就更简单了65536 - 24 0xFFE8。void uart1_init(void) { // 11.0592MHz晶振9600波特率1T模式 T2L 0xE0; // 低字节初值 T2H 0xFE; // 高字节初值 AUXR | 0x11; // T2R1使能定时器2T2x121选择1T模式 SCON 0x50; // 串口1模式18位UARTREN1允许接收 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 典型故障排查速查表这个例程从开始写到最后稳定运行我前后调试了两天。大部分时间不是花在代码逻辑上而是花在排查各种通信异常上。我把遇到的几类问题和解决办法整理成了表格方便你对照排查。现象可能原因排查方法完全无响应示波器看不到发送波形串口未初始化或波特率配置错误先用串口助手测试MCU自发自收确认串口通路正常有发送波形但从机不回复A/B线接反或485方向控制引脚时序不对检查RS485收发器的DE/RE引脚控制逻辑发送时使能发送发送完后切回接收收到数据但CRC校验一直失败波特率误差偏大或从机字节序不标准用逻辑分析仪抓帧逐个字节核对确认从机返回的数据格式偶发通信失败长时间运行后概率升高485总线缺终端电阻或共地不良总线两端并联120欧终端电阻确认所有设备地线共地一台从机掉线导致其他从机全部卡住主机没有做超时跳过处理确认代码中等待应答时有看门狗超时逻辑超时后必须放弃等待继续轮询5.2 调试工具使用与心得调试Modbus-RTU主机强烈建议准备一个USB转RS485的转换器把电脑当成一个从机去响应单片机的请求。这样可以在电脑上用串口调试工具看主机发出来的原始帧确认帧格式对不对。反过来也可以让电脑做主机单片机做从机验证从机功能是否正常。这套方法在项目调试阶段帮了我大忙。在调试过程中有一个比较隐蔽的坑有些从机设备对主机发送请求的间隔是有限制的。工业仪表内部一般也有自己的处理周期如果主机以极快的速度连续轮询同一台从机从机可能因为来不及处理而返回异常或者直接不响应。所以轮询间隔不要设得太短我实测下来一般建议不低于200ms。如果现场设备数量多可以适当把间隔放大到500ms甚至1s稳定优先。关于STC32G12K128的串口还有一个细节串口中断服务函数里尽量少做事。我的做法是中断里只负责收字节、存缓冲区、重置看门狗计数器所有的解析和判断都放到主循环里做。这样中断占用时间极短不容易丢字节系统的整体实时性也更好。还有一点和硬件相关。RS485的收发切换引脚比如RE/DE在发送完成后一定要及时拉回接收状态。我在第一版代码里发送结束后没有做这个切换结果就是数据发出去了但从机的响应全部丢失后来在示波器上看了半天才定位到是方向引脚一直保持发送状态导致接收通路被关闭。这个切换动作要在最后一个字节发送完成的标志位TI置1之后立刻执行。代码写完下载到板子上跑起来那会儿看到8台仪表的温度数据整整齐齐打印在调试串口上那种感觉还是很舒服的。Modbus-RTU这套协议本身不难难的是把它做得稳定可靠经得起长时间无人值守地运行。希望这个例程和这些调试经验能帮你少走几步弯路有类似需求的时候可以直接参考。本文还有配套的精品资源点击获取 
长河君 · 2026/9/3 18:43:42 · 阅读 1.2k 基于STC32G12K128的Modbus-RTU主机实现与调试经验
简介基于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做到128KBSRAM有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.04ms3.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.0592MHzSTC32G12K128支持外部晶振和内部IRC时钟。如果只是跑跑流水灯、点个OLED内部IRC完全没问题。但一旦涉及串口通信波特率精度就直接和时钟源挂钩了选错晶振会导致通信误码率暴涨。标准波特率9600、19200、115200这些值都是从11.0592MHz这个频率推出来的。为什么偏偏是11.0592因为115200 11059200 / 969600 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装0xE0T2H装0xFE。如果要跑19200就是65536 - 144 0xFF70。115200就更简单了65536 - 24 0xFFE8。void uart1_init(void) { // 11.0592MHz晶振9600波特率1T模式 T2L 0xE0; // 低字节初值 T2H 0xFE; // 高字节初值 AUXR | 0x11; // T2R1使能定时器2T2x121选择1T模式 SCON 0x50; // 串口1模式18位UARTREN1允许接收 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 典型故障排查速查表这个例程从开始写到最后稳定运行我前后调试了两天。大部分时间不是花在代码逻辑上而是花在排查各种通信异常上。我把遇到的几类问题和解决办法整理成了表格方便你对照排查。现象可能原因排查方法完全无响应示波器看不到发送波形串口未初始化或波特率配置错误先用串口助手测试MCU自发自收确认串口通路正常有发送波形但从机不回复A/B线接反或485方向控制引脚时序不对检查RS485收发器的DE/RE引脚控制逻辑发送时使能发送发送完后切回接收收到数据但CRC校验一直失败波特率误差偏大或从机字节序不标准用逻辑分析仪抓帧逐个字节核对确认从机返回的数据格式偶发通信失败长时间运行后概率升高485总线缺终端电阻或共地不良总线两端并联120欧终端电阻确认所有设备地线共地一台从机掉线导致其他从机全部卡住主机没有做超时跳过处理确认代码中等待应答时有看门狗超时逻辑超时后必须放弃等待继续轮询5.2 调试工具使用与心得调试Modbus-RTU主机强烈建议准备一个USB转RS485的转换器把电脑当成一个从机去响应单片机的请求。这样可以在电脑上用串口调试工具看主机发出来的原始帧确认帧格式对不对。反过来也可以让电脑做主机单片机做从机验证从机功能是否正常。这套方法在项目调试阶段帮了我大忙。在调试过程中有一个比较隐蔽的坑有些从机设备对主机发送请求的间隔是有限制的。工业仪表内部一般也有自己的处理周期如果主机以极快的速度连续轮询同一台从机从机可能因为来不及处理而返回异常或者直接不响应。所以轮询间隔不要设得太短我实测下来一般建议不低于200ms。如果现场设备数量多可以适当把间隔放大到500ms甚至1s稳定优先。关于STC32G12K128的串口还有一个细节串口中断服务函数里尽量少做事。我的做法是中断里只负责收字节、存缓冲区、重置看门狗计数器所有的解析和判断都放到主循环里做。这样中断占用时间极短不容易丢字节系统的整体实时性也更好。还有一点和硬件相关。RS485的收发切换引脚比如RE/DE在发送完成后一定要及时拉回接收状态。我在第一版代码里发送结束后没有做这个切换结果就是数据发出去了但从机的响应全部丢失后来在示波器上看了半天才定位到是方向引脚一直保持发送状态导致接收通路被关闭。这个切换动作要在最后一个字节发送完成的标志位TI置1之后立刻执行。代码写完下载到板子上跑起来那会儿看到8台仪表的温度数据整整齐齐打印在调试串口上那种感觉还是很舒服的。Modbus-RTU这套协议本身不难难的是把它做得稳定可靠经得起长时间无人值守地运行。希望这个例程和这些调试经验能帮你少走几步弯路有类似需求的时候可以直接参考。本文还有配套的精品资源点击获取