简介基于STM32F407的Modbus RTU主机代码完整工程包面向工业通信与嵌入式应用开发者。工程以标准外设库实现主站核心逻辑涵盖USART初始化、定时超时管理、报文构建、RS485方向切换、中断接收与CRC校验、应答解析及异常重试可直接移植至实际项目。压缩包共176个文件约5.2MB包含49个C源码与49个头文件并附Keil工程配置、链接脚本、编译产物hex/axf/map及烧录与调试辅助文件便于边读代码边验证。目前已有3300余人学习下载。通过这套代码可深入理解Modbus RTU主站状态机设计掌握基于STM32F407的串口中断与定时器协同使用方法同时为RS485组网通信和工业设备监控开发提供可靠参考。 干工控或者物联网设备这一行的十有八九都绕不过Modbus这个协议。它简单、稳定、普及率高从电表、温控器到PLC、变频器几乎每台设备出厂都默认带这个口。而STM32F407这颗芯片Cortex-M4内核带FPU主频168MHz拿来跑Modbus RTU主机协议简直是降维打击——不仅性能富余量大而且串口、定时器、DMA这些外设资源非常充裕特别适合做一主多从的采集网关或设备控制器。我这次分享的是基于STM32F407的Modbus RTU主机代码完整工程打包在一个zip里。这个代码不是我随便写的demo而是从实际项目中抽出来的通用性方案支持01/02/03/04/05/06/0F/10等常用功能码带超时重试机制串口采用“中断接收空闲检测”的方式判断帧结束主机轮询逻辑用状态机实现方便你在这套骨架上自由扩展从机数量和数据点。无论你是刚接触Modbus的嵌入式新手还是想在项目里快速移植Modbus主机的老手这套代码都能给你一个近乎“抄作业”的起点。先说清楚一个容易混淆的概念别把Modbus主机和从机搞混。从机是被动等命令的谁发请求它就回谁主机是主动发起通信的它按照自己的逻辑轮询各个从站地址、定时读写寄存器、处理超时和异常码。这台F407要做的事就是“发起者”——它得能够在串口上主动丢出一帧请求然后在规定时间内等待从机响应如果没等到就重试连续失败就标记故障。整个逻辑链条比从机长不少这也是为什么很多人在从机上调通了换到主机上就卡壳的原因。1. 项目整体设计与协议栈拆解1.1 为什么选择状态机而不是阻塞式轮询打开很多网上的教程代码你会发现它们写Modbus主机的方式特别“暴力”uart_send(buf, len); delay_ms(50); if(uart_receive(...)) { ... }——发送完就死等等不到就延长延时一直阻塞到超时再继续下一轮。这种写法在小项目里确实能跑但工程上就是颗定时炸弹串口一忙其他任务全卡住延时时间全靠拍脑袋波特率一变超时就得重新调而且一旦从机响应慢半拍整个主循环就被拖死了。我在这个工程里用的是状态机驱动Modbus主机被拆成四个状态MODBUS_STATE_IDLE空闲、MODBUS_STATE_WAIT_RESP等待响应、MODBUS_STATE_PROCESS处理数据、MODBUS_STATE_TIMEOUT超时处理。主循环里每毫秒调用一次Modbus_Poll()这个函数只做一件事——检查当前状态推进状态迁移绝不在里面阻塞等待。发送用串口DMA或中断方式接收用串口中断挨个收字节配合一个基于定时器的超时计数器。这样设计的好处非常明显单片机在等待从机响应的空隙里还可以去刷LCD、读按键、处理传感器数据整个轮询周期不会被单个从机的延迟拖累。更关键的是超时时间通过计数器精确控制不依赖HAL_Delay这种不可靠的阻塞延时时间基准统一由SysTick或定时器提供移植到其他芯片时只需要改几个宏。1.2 代码目录结构与模块划分这个工程虽然只是个小项目但我还是按照“应用层—协议层—驱动层”三层架构来组织代码。很多入行不久的朋友写代码喜欢全塞进main.c一个文件上千行到最后自己都找不到函数在哪。这个习惯一定要改尤其是做工业通信这种需要长期维护的代码模块划分清晰比“代码跑通”更重要。工程里的核心目录如下Core/放HAL库初始化、系统时钟配置、中断服务函数Modbus/port/这一层是移植层专门放串口发送、接收、定时器相关的底层函数芯片换了只用改这几个文件Modbus/modbus.c和modbus.h协议栈主体帧封装、CRC校验、状态机的核心逻辑App/应用层定义从机地址表、轮询任务链表、数据存储区移植层和协议层分离是我特别强调的。Modbus_Phys_Init()、Modbus_Phys_Send()、Modbus_Phys_SetRts()这几个函数是协议栈和硬件之间的唯一接口。芯片从F407换成F103、F767甚至GD32modbus.c里的逻辑一行都不用动只需要重写port层的六个函数这个架构思路在工业项目里能替你省下大量重复劳动。2. 核心功能码与数据帧格式详解2.1 RTU帧结构与收发缓冲区设计Modbus RTU的帧格式说简单也简单实际写代码时会遇到一个容易栽的坑——CRC的字节序。一帧RTU报文的组成是从站地址1字节 功能码1字节 数据区N字节 CRC162字节。里边的CRC校验值发送时是低字节在前、高字节在后比如CRC算出来是0x8001那么线上先发0x01再发0x80。很多人第一次写的时候按习惯高字节先发结果从机一直没响应排查半天发现是字节序搞反了。接收缓冲区我定义的是RTU标准最大帧长256字节实际项目中一个请求帧很少有超过70字节的但缓冲区宁可给大一点也不要抠门。需要注意1600年代的老工程师有一个经典教训缓冲区大小不要用魔法数字要用宏定义比如#define MODBUS_RX_BUF_SIZE 256这样以后换从站、扩寄存器数量改起来也直观。从发起请求到响应到达中间的时间窗口也要认真对待。RTU协议规定帧内字节间隔不能超过3.5个字符时间超过就认为帧结束。我这里是利用片上的空闲中断IDLE Line Interrupt来检测帧结束接收完成一帧后进入空闲中断在中断里把RxCompleteFlag置1主循环的Modbus状态机发现这个标志后开始解析。还有一种实现方式是用定时器模拟帧超时每收到一个字节就重置计数器计数器溢出就认为帧结束这种方式在串口不带空闲检测的芯片上更适用。2.2 常用功能码的报文构造与解析这套代码里最常用的是03读保持寄存器和06写单个寄存器以及0x10写多个寄存器。功能码的选择完全取决于现场设备的寄存器类型比如读温控器的当前温度用03、读开关状态用01/02、复位累计电量有的设备要求写04寄存器这个要看具体设备手册。以读保持寄存器为例请求帧格式如下字段长度值/说明从站地址1字节0x01~0xF7功能码1字节0x03起始地址2字节如0x0000高字节在前寄存器数量2字节如0x000A表示读10个寄存器CRC162字节低字节在前响应帧就是地址1字节 功能码1字节 字节数1字节值为寄存器数量×2 寄存器数据N×2字节 CRC162字节。写单个寄存器的请求帧则是地址功能码0x06寄存器地址2字节寄存器值2字节CRC。注意读请求和写请求的“数据区”差异很大构造的时候千万别套同一个模板函数硬怼。在代码里Modbus_RTU_Master_ReadRegs()和Modbus_RTU_Master_WriteSingleReg()是暴露给应用层用的两个核心API。它们内部会把传入的寄存器地址、数量等参数打包进发送缓冲区调用CRC计算函数然后通过串口发出去。从机返回的数据经过解析后会存到App层提供的缓存数组里再由上层逻辑决定怎么使用。3. 关键实现细节与踩坑记录3.1 CRC16-Modbus的计算优化CRC16-Modbus的算法在嵌入式领域属于“必须会背”的级别。初值0xFFFF多项式0x8005实际计算时反映射成0xA001每次数据字节与CRC低字节异或后再逐位右移8次最后得到的值就是校验结果。代码里可以有两种实现方式查表法和逐位计算法。我这份代码里用的是逐位计算法因为它的可读性最好而且F407的主频足够高一个帧的CRC计算时间可以忽略不计。查表法的速度会快几十倍但需要额外维护一张512字节的表对F407来说没多大意义。计算CRC的C代码如下所示uint16_t Modbus_CRC16(uint8_t *pData, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ (uint16_t)pData[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; }生成帧的时候先往发送缓冲区里填入地址、功能码、数据最后调用这个函数算出CRC按低字节在前、高字节在后的顺序填入最后两个字节。校验响应的时候是把收到的整帧不含CRC重新算一遍CRC再跟帧尾的两个字节比对。注意不要在同一个缓冲区的末尾直接调用这个函数那样会把原帧数据覆盖掉最好复制到临时数组再计算。3.2 超时重试机制与重试次数的确定Modbus主机和从机的通信有一个现实问题——从机不是每次都及时响应的。可能是总线干扰导致帧丢了也可能是从机正在忙于内部处理所以主机必须有一个可配置的超时重试功能。我在代码里定义了MODBUS_TIMEOUT_BASE_MS和MODBUS_MAX_RETRY两个宏。超时基准时间通常是4个字符时间也就是3.5T加一点余量但这个值跟波特率强相关。举个实际例子波特率9600bps时一个字符约1.1ms4个字符约4.4ms那么超时时间我一般设成50ms波特率115200bps时一个字符约0.1ms超时时间建议设20ms。给太短会误判给太长会拖慢轮询周期需要现场实际调试。重试次数的设计也很有讲究。如果只试一次就报故障可能会有误报如果无限重试一旦某个从机掉线整个轮询序列会被它卡死。我的做法是每个从站独立维护重试计数连续重试3次仍然无响应才标记该站故障同时把该站从轮询队列中暂时摘除继续轮询下一个从站每30秒再自动恢复一次尝试。这样单站故障不会影响总线上其他设备的采集。3.3 定时器与串口中断的配合策略这个Modbus主机代码在中断层面的设计是串口接收中断负责把每个到达的字节搬进环形缓冲区每收到一个字节就重置一次帧超时计数器当串口空闲中断产生时通知协议栈“一帧已经接收完整”。这种做法的最大优势是协议栈不用在接收过程中干等而是在整帧到达后才做解析。实现的时候要小心一个优先级问题串口中断优先级要低于SysTick定时器否则在长时间高波特率通信时会卡死其他任务。F407有NVIC可配置优先级分组我使用的是NVIC_PriorityGroup_4抢占优先级4位无子优先级USART1中断优先级设为3SysTick优先级设为1数值越小优先级越高确保系统心跳稳定而串口中断不会疯狂抢占CPU。从机响应到达后主循环在MODBUS_STATE_PROCESS状态检查RxCompleteFlag如果置1了就解析缓冲区的帧如果没置1并且超时计数器已经溢出就跳到MODBUS_STATE_TIMEOUT做重试处理。这样整个收发逻辑完全在“被动接收”和“主动超时”之间切换CPU的占用率极低。4. 应用层封装与轮询任务管理4.1 从站地址表与轮询周期的实现方法现场一主多从的场景很常见轮询列表是主机逻辑的核心。我在App层设计了一个结构体数组每个元素定义一个轮询任务项typedef struct { uint8_t slave_addr; // 从站地址 uint8_t func_code; // 功能码 uint16_t reg_addr; // 寄存器起始地址 uint16_t reg_count; // 寄存器数量 uint16_t poll_interval_ms;// 轮询间隔 uint8_t retry_cnt; // 当前重试次数 uint8_t fault_flag; // 故障标志 uint8_t enable; // 是否启用该任务 } Modbus_PollItem_t;比如现场有3个从站1号从站是温控器2号是变频器3号是电表那就定义3个这样的结构体把各自的地址、寄存器和轮询间隔填进去。主循环的Modbus轮询函数每执行一次就按顺序检查当前任务的轮询间隔是否到达到达了就发送请求没到达就检查下一个任务。这样空出的时间可以用来处理其他业务。轮询间隔设置有个经验值普通PLC和仪表建议500ms以上高集成度的智能传感器可以跑到100ms但像老式电表这种响应慢的设备至少要留1秒的间隔。别一上来就全设50ms现场总线冲突和从机负载都会受不了。4.2 解析从机响应与异常码处理从机不是只会老老实实回数据它还可能回复异常帧。异常帧的特征是功能码的最高位置1比如主机发0x03读寄存器从机回0x83就表示异常。异常码存放在数据区的第一字节常见的有异常码含义常见原因0x01非法功能从机不支持该功能码0x02非法数据地址寄存器超出范围0x03非法数据值写入的值超范围0x04从站设备故障从机内部错误遇到异常帧协议栈会在串口调试助手上打印异常码同时把该任务标记为故障状态但不会无限重发因为异常帧本身说明从机是“活着”的问题出在请求内容上。这种情况一般要去查从机手册确认寄存器地址和功能码是否正确。4.3 发现一个隐患环形缓冲区的大小设置串口接收缓冲区我用的是环形队列大小256字节。实际项目中出现过一个很隐蔽的bug某个从机的响应帧里有很长的数据块超过了缓冲区剩余空间导致数据被截断。排查了半天才发现缓冲区定义小了。这里给一个建议缓冲区大小不仅要大于最大帧长还要留出至少1.5倍的裕量防止突发数据叠加。工业现场串口上偶尔会有干扰毛刺毛刺也会被串口接收进缓冲区如果缓冲区塞满后新数据就丢失了进而导致之后所有帧都解析失败。缓冲区定义成512字节反正F407的RAM非常充裕这种开销根本不用心疼。5. 常见问题与排查工具推荐5.1 用串口助手和逻辑分析仪定位通信问题调试Modbus主机最大的麻烦是“看不见摸不着”——你不知道线上到底传了什么。我的调试工具组合是USB转RS485模块串口调试助手逻辑分析仪。串口调试助手适合在开发阶段快速验证收发。特别注意调试时电脑要接的是RS485转USB模块波特率、数据位、校验位、停止位必须与F407侧完全一致。Modbus RTU标准是8位数据位、无校验、1位停止位但有些设备默认是8E1这里一定要看从机手册不匹配的话通信直接失败。逻辑分析仪用来抓波形最直观。把两个探头分别接在RS485的A、B线上触发方式设为上报文起始沿。从波形上你可以看到有没有帧在线上传输、帧间距是否正常、波特率有没有偏差。有一次我在项目里排查一个偶发性丢帧问题发现是PCB走线干扰导致RS485电平翻转毛刺逻辑分析仪上一眼就看出来了。5.2 移植到其他STM32型号时需要改什么这个工程虽然以F407为模板但整套代码的移植成本其实很低。移植的第一步是修改Modbus/port/modbus_port.c里的底层函数把串口收发从USART1改成你实际用的串口空间映射不同的引脚和时钟把定时器从TIM2改成TIM3或者其他定时器。协议层本身不需要动。第二步是检查HAL库版本。我写代码用的HAL驱动版本是1.25如果你工程里的HAL版本比较新串口初始化结构体里的参数可能会有差异编译报错时照着新版头文件改一下即可。第三步是波特率配置在CubeMX里直接改就可以了注意改完后主时钟的APB分频系数也要一起核对否则实际波特率会算错。5.3 时序上的几个隐藏杀手Modbus RTU通信对时序相当敏感。我见过的最常见的坑是主机发送完请求帧后没有等从机响应就立刻开始处理其他任务结果下次轮询来的时候把上次的响应帧误当成新响应。解决方案是每个从站任务都必须有严格的“发→等→收”状态流转我的代码里已经实现了但你二次开发的时候千万别自作聪明去删掉这个状态判断。另一个坑是RS485方向切换时序。如果你用的是RS485芯片发送结束后必须把DE/RE引脚拉低让总线恢复接收状态。这个延时至关重要发送完最后一个字节后要等待至少1个字符时间再拉低方向控制脚否则帧尾的CRC会被截断。我在Modbus_Phys_Send()函数里用了一个微秒级的延时就是干这个的。最后提醒一下算帧间隔的时候别忘了加上RS485方向切换的时间。有些廉价USB转RS485模块在高速切换方向时会有几十微秒的延迟如果主机和从机都是快速的RS485芯片而中间桥接模块拖了后腿那也会导致帧超时。6. 写在最后的一点建议这套Modbus RTU主机代码我从最初的“能通就行”版本改到现在这个通用性比较强的版本过程里踩过不少坑但每次踩坑都让代码健壮了一分。如果让我给刚起步的人一个建议拿到代码后不要急着往自己的板子上烧先在串口调试助手里把收发链路完全打通确认F407发出的报文在PC端能看到、PC端模拟的从机响应F407能正确解析再接入真实从机设备。通信协议不比业务逻辑一旦总线上有两台设备因为时序问题互相干等排查起来真的会怀疑人生。这套代码在F407上实测下来稳定跑过7×24小时的连续轮询目前在几个采集终端项目里还在服役。如果你在移植过程中遇到问题欢迎在评论区把现象发出来——带上你的波特率、设备型号和抓包截图咱们一起看看问题出在哪。本文还有配套的精品资源点击获取 STM32F407 Modbus RTU主机完整工程：状态机设计、CRC校验与移植
简介基于STM32F407的Modbus RTU主机代码完整工程包面向工业通信与嵌入式应用开发者。工程以标准外设库实现主站核心逻辑涵盖USART初始化、定时超时管理、报文构建、RS485方向切换、中断接收与CRC校验、应答解析及异常重试可直接移植至实际项目。压缩包共176个文件约5.2MB包含49个C源码与49个头文件并附Keil工程配置、链接脚本、编译产物hex/axf/map及烧录与调试辅助文件便于边读代码边验证。目前已有3300余人学习下载。通过这套代码可深入理解Modbus RTU主站状态机设计掌握基于STM32F407的串口中断与定时器协同使用方法同时为RS485组网通信和工业设备监控开发提供可靠参考。 干工控或者物联网设备这一行的十有八九都绕不过Modbus这个协议。它简单、稳定、普及率高从电表、温控器到PLC、变频器几乎每台设备出厂都默认带这个口。而STM32F407这颗芯片Cortex-M4内核带FPU主频168MHz拿来跑Modbus RTU主机协议简直是降维打击——不仅性能富余量大而且串口、定时器、DMA这些外设资源非常充裕特别适合做一主多从的采集网关或设备控制器。我这次分享的是基于STM32F407的Modbus RTU主机代码完整工程打包在一个zip里。这个代码不是我随便写的demo而是从实际项目中抽出来的通用性方案支持01/02/03/04/05/06/0F/10等常用功能码带超时重试机制串口采用“中断接收空闲检测”的方式判断帧结束主机轮询逻辑用状态机实现方便你在这套骨架上自由扩展从机数量和数据点。无论你是刚接触Modbus的嵌入式新手还是想在项目里快速移植Modbus主机的老手这套代码都能给你一个近乎“抄作业”的起点。先说清楚一个容易混淆的概念别把Modbus主机和从机搞混。从机是被动等命令的谁发请求它就回谁主机是主动发起通信的它按照自己的逻辑轮询各个从站地址、定时读写寄存器、处理超时和异常码。这台F407要做的事就是“发起者”——它得能够在串口上主动丢出一帧请求然后在规定时间内等待从机响应如果没等到就重试连续失败就标记故障。整个逻辑链条比从机长不少这也是为什么很多人在从机上调通了换到主机上就卡壳的原因。1. 项目整体设计与协议栈拆解1.1 为什么选择状态机而不是阻塞式轮询打开很多网上的教程代码你会发现它们写Modbus主机的方式特别“暴力”uart_send(buf, len); delay_ms(50); if(uart_receive(...)) { ... }——发送完就死等等不到就延长延时一直阻塞到超时再继续下一轮。这种写法在小项目里确实能跑但工程上就是颗定时炸弹串口一忙其他任务全卡住延时时间全靠拍脑袋波特率一变超时就得重新调而且一旦从机响应慢半拍整个主循环就被拖死了。我在这个工程里用的是状态机驱动Modbus主机被拆成四个状态MODBUS_STATE_IDLE空闲、MODBUS_STATE_WAIT_RESP等待响应、MODBUS_STATE_PROCESS处理数据、MODBUS_STATE_TIMEOUT超时处理。主循环里每毫秒调用一次Modbus_Poll()这个函数只做一件事——检查当前状态推进状态迁移绝不在里面阻塞等待。发送用串口DMA或中断方式接收用串口中断挨个收字节配合一个基于定时器的超时计数器。这样设计的好处非常明显单片机在等待从机响应的空隙里还可以去刷LCD、读按键、处理传感器数据整个轮询周期不会被单个从机的延迟拖累。更关键的是超时时间通过计数器精确控制不依赖HAL_Delay这种不可靠的阻塞延时时间基准统一由SysTick或定时器提供移植到其他芯片时只需要改几个宏。1.2 代码目录结构与模块划分这个工程虽然只是个小项目但我还是按照“应用层—协议层—驱动层”三层架构来组织代码。很多入行不久的朋友写代码喜欢全塞进main.c一个文件上千行到最后自己都找不到函数在哪。这个习惯一定要改尤其是做工业通信这种需要长期维护的代码模块划分清晰比“代码跑通”更重要。工程里的核心目录如下Core/放HAL库初始化、系统时钟配置、中断服务函数Modbus/port/这一层是移植层专门放串口发送、接收、定时器相关的底层函数芯片换了只用改这几个文件Modbus/modbus.c和modbus.h协议栈主体帧封装、CRC校验、状态机的核心逻辑App/应用层定义从机地址表、轮询任务链表、数据存储区移植层和协议层分离是我特别强调的。Modbus_Phys_Init()、Modbus_Phys_Send()、Modbus_Phys_SetRts()这几个函数是协议栈和硬件之间的唯一接口。芯片从F407换成F103、F767甚至GD32modbus.c里的逻辑一行都不用动只需要重写port层的六个函数这个架构思路在工业项目里能替你省下大量重复劳动。2. 核心功能码与数据帧格式详解2.1 RTU帧结构与收发缓冲区设计Modbus RTU的帧格式说简单也简单实际写代码时会遇到一个容易栽的坑——CRC的字节序。一帧RTU报文的组成是从站地址1字节 功能码1字节 数据区N字节 CRC162字节。里边的CRC校验值发送时是低字节在前、高字节在后比如CRC算出来是0x8001那么线上先发0x01再发0x80。很多人第一次写的时候按习惯高字节先发结果从机一直没响应排查半天发现是字节序搞反了。接收缓冲区我定义的是RTU标准最大帧长256字节实际项目中一个请求帧很少有超过70字节的但缓冲区宁可给大一点也不要抠门。需要注意1600年代的老工程师有一个经典教训缓冲区大小不要用魔法数字要用宏定义比如#define MODBUS_RX_BUF_SIZE 256这样以后换从站、扩寄存器数量改起来也直观。从发起请求到响应到达中间的时间窗口也要认真对待。RTU协议规定帧内字节间隔不能超过3.5个字符时间超过就认为帧结束。我这里是利用片上的空闲中断IDLE Line Interrupt来检测帧结束接收完成一帧后进入空闲中断在中断里把RxCompleteFlag置1主循环的Modbus状态机发现这个标志后开始解析。还有一种实现方式是用定时器模拟帧超时每收到一个字节就重置计数器计数器溢出就认为帧结束这种方式在串口不带空闲检测的芯片上更适用。2.2 常用功能码的报文构造与解析这套代码里最常用的是03读保持寄存器和06写单个寄存器以及0x10写多个寄存器。功能码的选择完全取决于现场设备的寄存器类型比如读温控器的当前温度用03、读开关状态用01/02、复位累计电量有的设备要求写04寄存器这个要看具体设备手册。以读保持寄存器为例请求帧格式如下字段长度值/说明从站地址1字节0x01~0xF7功能码1字节0x03起始地址2字节如0x0000高字节在前寄存器数量2字节如0x000A表示读10个寄存器CRC162字节低字节在前响应帧就是地址1字节 功能码1字节 字节数1字节值为寄存器数量×2 寄存器数据N×2字节 CRC162字节。写单个寄存器的请求帧则是地址功能码0x06寄存器地址2字节寄存器值2字节CRC。注意读请求和写请求的“数据区”差异很大构造的时候千万别套同一个模板函数硬怼。在代码里Modbus_RTU_Master_ReadRegs()和Modbus_RTU_Master_WriteSingleReg()是暴露给应用层用的两个核心API。它们内部会把传入的寄存器地址、数量等参数打包进发送缓冲区调用CRC计算函数然后通过串口发出去。从机返回的数据经过解析后会存到App层提供的缓存数组里再由上层逻辑决定怎么使用。3. 关键实现细节与踩坑记录3.1 CRC16-Modbus的计算优化CRC16-Modbus的算法在嵌入式领域属于“必须会背”的级别。初值0xFFFF多项式0x8005实际计算时反映射成0xA001每次数据字节与CRC低字节异或后再逐位右移8次最后得到的值就是校验结果。代码里可以有两种实现方式查表法和逐位计算法。我这份代码里用的是逐位计算法因为它的可读性最好而且F407的主频足够高一个帧的CRC计算时间可以忽略不计。查表法的速度会快几十倍但需要额外维护一张512字节的表对F407来说没多大意义。计算CRC的C代码如下所示uint16_t Modbus_CRC16(uint8_t *pData, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ (uint16_t)pData[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; }生成帧的时候先往发送缓冲区里填入地址、功能码、数据最后调用这个函数算出CRC按低字节在前、高字节在后的顺序填入最后两个字节。校验响应的时候是把收到的整帧不含CRC重新算一遍CRC再跟帧尾的两个字节比对。注意不要在同一个缓冲区的末尾直接调用这个函数那样会把原帧数据覆盖掉最好复制到临时数组再计算。3.2 超时重试机制与重试次数的确定Modbus主机和从机的通信有一个现实问题——从机不是每次都及时响应的。可能是总线干扰导致帧丢了也可能是从机正在忙于内部处理所以主机必须有一个可配置的超时重试功能。我在代码里定义了MODBUS_TIMEOUT_BASE_MS和MODBUS_MAX_RETRY两个宏。超时基准时间通常是4个字符时间也就是3.5T加一点余量但这个值跟波特率强相关。举个实际例子波特率9600bps时一个字符约1.1ms4个字符约4.4ms那么超时时间我一般设成50ms波特率115200bps时一个字符约0.1ms超时时间建议设20ms。给太短会误判给太长会拖慢轮询周期需要现场实际调试。重试次数的设计也很有讲究。如果只试一次就报故障可能会有误报如果无限重试一旦某个从机掉线整个轮询序列会被它卡死。我的做法是每个从站独立维护重试计数连续重试3次仍然无响应才标记该站故障同时把该站从轮询队列中暂时摘除继续轮询下一个从站每30秒再自动恢复一次尝试。这样单站故障不会影响总线上其他设备的采集。3.3 定时器与串口中断的配合策略这个Modbus主机代码在中断层面的设计是串口接收中断负责把每个到达的字节搬进环形缓冲区每收到一个字节就重置一次帧超时计数器当串口空闲中断产生时通知协议栈“一帧已经接收完整”。这种做法的最大优势是协议栈不用在接收过程中干等而是在整帧到达后才做解析。实现的时候要小心一个优先级问题串口中断优先级要低于SysTick定时器否则在长时间高波特率通信时会卡死其他任务。F407有NVIC可配置优先级分组我使用的是NVIC_PriorityGroup_4抢占优先级4位无子优先级USART1中断优先级设为3SysTick优先级设为1数值越小优先级越高确保系统心跳稳定而串口中断不会疯狂抢占CPU。从机响应到达后主循环在MODBUS_STATE_PROCESS状态检查RxCompleteFlag如果置1了就解析缓冲区的帧如果没置1并且超时计数器已经溢出就跳到MODBUS_STATE_TIMEOUT做重试处理。这样整个收发逻辑完全在“被动接收”和“主动超时”之间切换CPU的占用率极低。4. 应用层封装与轮询任务管理4.1 从站地址表与轮询周期的实现方法现场一主多从的场景很常见轮询列表是主机逻辑的核心。我在App层设计了一个结构体数组每个元素定义一个轮询任务项typedef struct { uint8_t slave_addr; // 从站地址 uint8_t func_code; // 功能码 uint16_t reg_addr; // 寄存器起始地址 uint16_t reg_count; // 寄存器数量 uint16_t poll_interval_ms;// 轮询间隔 uint8_t retry_cnt; // 当前重试次数 uint8_t fault_flag; // 故障标志 uint8_t enable; // 是否启用该任务 } Modbus_PollItem_t;比如现场有3个从站1号从站是温控器2号是变频器3号是电表那就定义3个这样的结构体把各自的地址、寄存器和轮询间隔填进去。主循环的Modbus轮询函数每执行一次就按顺序检查当前任务的轮询间隔是否到达到达了就发送请求没到达就检查下一个任务。这样空出的时间可以用来处理其他业务。轮询间隔设置有个经验值普通PLC和仪表建议500ms以上高集成度的智能传感器可以跑到100ms但像老式电表这种响应慢的设备至少要留1秒的间隔。别一上来就全设50ms现场总线冲突和从机负载都会受不了。4.2 解析从机响应与异常码处理从机不是只会老老实实回数据它还可能回复异常帧。异常帧的特征是功能码的最高位置1比如主机发0x03读寄存器从机回0x83就表示异常。异常码存放在数据区的第一字节常见的有异常码含义常见原因0x01非法功能从机不支持该功能码0x02非法数据地址寄存器超出范围0x03非法数据值写入的值超范围0x04从站设备故障从机内部错误遇到异常帧协议栈会在串口调试助手上打印异常码同时把该任务标记为故障状态但不会无限重发因为异常帧本身说明从机是“活着”的问题出在请求内容上。这种情况一般要去查从机手册确认寄存器地址和功能码是否正确。4.3 发现一个隐患环形缓冲区的大小设置串口接收缓冲区我用的是环形队列大小256字节。实际项目中出现过一个很隐蔽的bug某个从机的响应帧里有很长的数据块超过了缓冲区剩余空间导致数据被截断。排查了半天才发现缓冲区定义小了。这里给一个建议缓冲区大小不仅要大于最大帧长还要留出至少1.5倍的裕量防止突发数据叠加。工业现场串口上偶尔会有干扰毛刺毛刺也会被串口接收进缓冲区如果缓冲区塞满后新数据就丢失了进而导致之后所有帧都解析失败。缓冲区定义成512字节反正F407的RAM非常充裕这种开销根本不用心疼。5. 常见问题与排查工具推荐5.1 用串口助手和逻辑分析仪定位通信问题调试Modbus主机最大的麻烦是“看不见摸不着”——你不知道线上到底传了什么。我的调试工具组合是USB转RS485模块串口调试助手逻辑分析仪。串口调试助手适合在开发阶段快速验证收发。特别注意调试时电脑要接的是RS485转USB模块波特率、数据位、校验位、停止位必须与F407侧完全一致。Modbus RTU标准是8位数据位、无校验、1位停止位但有些设备默认是8E1这里一定要看从机手册不匹配的话通信直接失败。逻辑分析仪用来抓波形最直观。把两个探头分别接在RS485的A、B线上触发方式设为上报文起始沿。从波形上你可以看到有没有帧在线上传输、帧间距是否正常、波特率有没有偏差。有一次我在项目里排查一个偶发性丢帧问题发现是PCB走线干扰导致RS485电平翻转毛刺逻辑分析仪上一眼就看出来了。5.2 移植到其他STM32型号时需要改什么这个工程虽然以F407为模板但整套代码的移植成本其实很低。移植的第一步是修改Modbus/port/modbus_port.c里的底层函数把串口收发从USART1改成你实际用的串口空间映射不同的引脚和时钟把定时器从TIM2改成TIM3或者其他定时器。协议层本身不需要动。第二步是检查HAL库版本。我写代码用的HAL驱动版本是1.25如果你工程里的HAL版本比较新串口初始化结构体里的参数可能会有差异编译报错时照着新版头文件改一下即可。第三步是波特率配置在CubeMX里直接改就可以了注意改完后主时钟的APB分频系数也要一起核对否则实际波特率会算错。5.3 时序上的几个隐藏杀手Modbus RTU通信对时序相当敏感。我见过的最常见的坑是主机发送完请求帧后没有等从机响应就立刻开始处理其他任务结果下次轮询来的时候把上次的响应帧误当成新响应。解决方案是每个从站任务都必须有严格的“发→等→收”状态流转我的代码里已经实现了但你二次开发的时候千万别自作聪明去删掉这个状态判断。另一个坑是RS485方向切换时序。如果你用的是RS485芯片发送结束后必须把DE/RE引脚拉低让总线恢复接收状态。这个延时至关重要发送完最后一个字节后要等待至少1个字符时间再拉低方向控制脚否则帧尾的CRC会被截断。我在Modbus_Phys_Send()函数里用了一个微秒级的延时就是干这个的。最后提醒一下算帧间隔的时候别忘了加上RS485方向切换的时间。有些廉价USB转RS485模块在高速切换方向时会有几十微秒的延迟如果主机和从机都是快速的RS485芯片而中间桥接模块拖了后腿那也会导致帧超时。6. 写在最后的一点建议这套Modbus RTU主机代码我从最初的“能通就行”版本改到现在这个通用性比较强的版本过程里踩过不少坑但每次踩坑都让代码健壮了一分。如果让我给刚起步的人一个建议拿到代码后不要急着往自己的板子上烧先在串口调试助手里把收发链路完全打通确认F407发出的报文在PC端能看到、PC端模拟的从机响应F407能正确解析再接入真实从机设备。通信协议不比业务逻辑一旦总线上有两台设备因为时序问题互相干等排查起来真的会怀疑人生。这套代码在F407上实测下来稳定跑过7×24小时的连续轮询目前在几个采集终端项目里还在服役。如果你在移植过程中遇到问题欢迎在评论区把现象发出来——带上你的波特率、设备型号和抓包截图咱们一起看看问题出在哪。本文还有配套的精品资源点击获取