STM32F103+MODBUS RTU实现6路继电器远程控制

简介面向工业现场与物联网设备控制的六通道继电器切换方案基于STM32F103与MODBUS RTU协议实现适用于远程开关控制的电力、环境监测或自动化设备场景也适合作为同类控制模块的参考设计。资源包含完整单片机源程序以及采用Cadence设计的原理图与PCB文件接口采用USB转TTL程序已在项目中落地可直接集成复用能有效缩短继电器控制模块的研发周期适合具备一定STM32开发经验的工程师学习使用。包体共246个文件、约7.24MB以C语言源码、头文件、Keil工程配置和Cadence设计文件为主附带hex、axf等编译输出既可阅读完整工程结构也能直接烧录验证。已有875人学习源码与设计文件齐全便于对照原理图理解MODBUS寄存器操作、继电器驱动逻辑与通道切换流程快速迁移到自己的控制电路或上位机联动开发同时可从Keil工程与Cadence文件中提取可复用的报文解析、板级布局经验整体是一份完整度较高的软硬件一体参考资源。 干嵌入式这些年经常会接到一类需求“用上位机或者触摸屏去远程控制几路开关”。这个项目就是非常典型的一个主控用STM32F103通过串口跑MODBUS RTU协议去驱动一块6通道继电器模块实现开关量输出并且支持随时回读每路继电器的真实状态。串口 MODBUS RTU 继电器切换这套组合在工业现场、物联网网关、小型自动化设备里实在太常见了。很多工厂设备、环境监控、灯光控制、水泵电机启停背后往往就是类似这样一个板子。对于刚开始接触协议栈或者想把自制的控制板做得“标准化”一点的开发者来说这个项目是一个特别合适的练手和实用方案硬件成本低、代码思路清晰、调试手段简单而且做完之后直接就能用组态软件或MODBUS调试工具控制完全不像自己发明一套私有协议那样还得到处和人解释协议格式。1. 方案选型与整体设计思路1.1 为什么选MODBUS RTU而不是自己定义一套协议很多初学者做串口控制第一反应是“我发一个0xAA再发一个0x01继电器就吸合了简单又直接”。这确实能跑但在实际项目中这种自定义协议往往会变成后期的坑。最大问题是上位机对接。如果你面对的是一台组态屏、一套工控组态软件或者一个客户自己写的监控平台它们默认都支持MODBUS协议。你做成MODBUS RTU从机直接把设备挂在总线上设好从机地址组态软件里填寄存器地址就能读写了。如果是自定义协议你还得给上位机单独写驱动不仅周期长而且出了问题责任说不清楚。MODBUS RTU本身也足够轻量。它的帧结构是“地址码 功能码 数据 CRC16校验”一帧完整命令通常也就8个字节左右在9600波特率下只用几毫秒就能传完。更重要的是它处理错误的机制非常成熟接收到非法地址返回异常码CRC校验错误直接丢弃总线上的其他从机也不会受到干扰。这套机制比自己从头写要严谨得多。1.2 为什么用STM32F103STM32F103在市场上流通量极大价格也压得很低。对于继电器控制这种场景F103C8T6的资源已经绰绰有余一个USART用来通信几个GPIO用来控制继电器一个定时器用来做帧超时判断。它的标准外设库非常成熟网上资料浩如烟海遇到问题随手就能搜到解法。另外F103的USART支持RXNE中断配合一个毫秒级的定时器中断就能很稳定地实现MODBUS RTU的帧接收判断不需要额外硬件、也不需要上DMA代码量小逻辑直观。如果你打算用HAL库开发F103也是ST官方支持最完善的系列之一CubeMX配置几个外设也很方便。总之这颗芯片做这个项目算得上“杀鸡用牛刀”但正因为冗余量足够后续要扩展更多功能也不用换平台。1.3 系统架构与数据流整个系统的数据流是这样的上位机串口调试助手、MODBUS Poll、组态软件、触摸屏等通过RS485或者TTL串口下发MODBUS RTU帧STM32F103的USART接收中断把帧收进缓冲区然后解析功能码和地址对16位寄存器/线圈区进行读写操作最终改变GPIO输出电平驱动光耦和三极管控制6路继电器的吸合与断开。同时STM32内部用一个变量保存当前6路继电器的输出状态。上位机发送读线圈命令时MCU把这个变量的状态拼接成响应帧返回实现“设置成功与否”的闭环确认。整个系统不是靠“发一次命令就完事”而是有严格的状态回读机制这也是工业设备可靠性的基本要求。2. 硬件设计要点2.1 最小系统与通信接口STM32F103最小系统本身不复杂8MHz晶振作为HSE时钟源两个20pF左右的负载电容NRST复位引脚接10k上拉电阻和0.1uF电容到地BOOT0下拉到GND让芯片从Flash启动。VDD每个引脚旁边都放一个100nF退耦电容电源入口再并一个10uF到100uF的电解电容。这套做法是所有STM32项目的通用配置直接照抄官方参考设计即可别在这上面省。通信接口分两种场合。如果只是自己调试、板子和电脑距离在一两米以内直接用TTL电平就行通过CH340或FT232的USB转串口模块连到电脑。CH340驱动网上就能找到兼容性好串口调试助手打开就能看到数据。如果是要用在工业现场距离几十米甚至更远那就必须走RS485加一颗SP3485或者MAX485做电平转换A/B线之间并联120Ω终端电阻MCU用另一个GPIO控制DE/RE方向。RS485是差分信号抗共模干扰能力比TTL强很多这也是MODBUS RTU在实际项目中最常见的物理层接口。2.2 继电器驱动与保护电路这里要提醒新手STM32的GPIO引脚绝对不能直接驱动继电器线圈。F103的GPIO输出能力一般在20mA左右而一个5V继电器线圈的吸合电流通常在50mA到80mA之间12V继电器线圈电流更高直接接IO口会把引脚拉垮甚至烧毁芯片。正确的做法是让IO口只负责控制三极管或达林顿管再由三极管驱动线圈。常用的方案有两种用NPN三极管比如SS9013、8050、S8050搭一个低边驱动IO输出高电平通过1k基极电阻给三极管提供基极电流三极管导通后继电器线圈得电吸合或者直接用ULN2003达林顿驱动芯片一片就能驱动7路内部自带续流二极管布线和器件数量都省很多。不管哪种方案继电器线圈两端必须并联一个续流二极管方向是阴极接电源正、阳极接三极管集电极。这个二极管的作用是当三极管关断、线圈电流突变时为线圈的自感电动势提供一个泄放回路防止反向高压打坏三极管。如果没有这颗二极管三极管很容易在继电器频繁通断时被击穿这个问题在继电器驱动的所有电路资料里都会被反复强调。另外如果系统里既有继电器又有单片机强烈建议在MCU和驱动电路之间加光耦隔离比如PC817。继电器吸合瞬间线圈电流突变会对电源造成冲击光耦能把继电器回路的电源和MCU电源在电气上隔离开即使继电器那边的电源被拉得抖动也不会直接干扰单片机复位或通信乱码。至于触点侧保护感性负载电机、电磁阀在断开瞬间会产生高压电弧可以在触点两端并联RC吸收电路或者用压敏电阻、TVS管。RC和TVS的取舍其实看负载类型阻性负载可以不处理感性负载建议用RC高频开关场景更适合TVS。2.3 TTL直连和RS485的取舍做样机验证时直接用TTL串口连继电器模块最省事但量产或安装到现场时RS485基本是标配。RS485是半双工总线同一时刻只能收或发所以代码里要处理好发送和接收方向的切换时间发完一帧后要把DE引脚拉低等待接收。常见的一个坑是发送完后立刻拉低方向引脚最后一个字节还没完全从移位寄存器送出导致数据截断对端收到不完整的帧CRC必然不过。解决方法是等USART的TC发送完成标志置位后再切换方向或者加一个小延时比如发送完成后延时1到2个字符时间。3. MODBUS RTU协议栈实现3.1 帧结构、功能码与CRC16MODBUS RTU的帧格式非常紧凑地址码1字节功能码1字节数据区N字节CRC校验2字节低字节在前。地址码范围是1到2470x00是广播地址从机收到广播帧后执行命令但不回复。功能码决定这条命令要做什么本项目只用到四个0x01读线圈读继电器状态0x05写单线圈控制单个继电器0x03读保持寄存器读状态寄存器0x06写单个保持寄存器写状态寄存器CRC16是MODBUS RTU的帧尾校验计算时对除CRC外的所有字节按多项式0xA001、初始值0xFFFF做位运算。代码实现如下uint16_t ModbusCRC16(uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; while (len--) { crc ^ *buf; for (uint8_t i 0; i 8; i) { if (crc 0x0001) { crc 1; crc ^ 0xA001; } else { crc 1; } } } return crc; }发送时CRC低字节在前、高字节在后。这个顺序经常有人搞反导致从机一直报非法功能码或者直接没反应。用串口调试助手手工发命令测试时尤其容易踩这个坑。3.2 寄存器地址规划寄存器规划是整个项目最容易扩展的部分。我这里用的是标准MODBUS地址分配思想线圈地址0x0000到0x0005分别对应K1到K6六路继电器。线圈的值只有两种0xFF00表示ON0x0000表示OFF这是MODBUS标准规定的。保持寄存器地址0x0000专门用一个16位寄存器存放6路继电器的状态字bit0到bit5分别对应K1到K6。这样上位机一次读一个寄存器就能拿到全部通道的开关状态比逐个读线圈效率高很多。设备地址我默认设置成0x01。实际项目里如果需要多个从机挂在同一条RS485总线上可以通过另一个寄存器动态修改并把修改后的地址存入EEPROM掉电不丢失。注意修改地址后从机立即生效上位机下一次必须用新地址通信。3.3 串口接收处理与帧超时判断MODBUS RTU没有帧头和帧尾它的帧边界靠“静默间隔”来区分帧与帧之间至少要有3.5个字符时间的静默超过这个间隔就认为一帧结束。在STM32上最常用的实现方法是串口中断接收 定时器超时判断。串口每收到一个字节就把字节存入缓冲区同时复位一个毫秒定时器的计数值。如果连续5毫秒没有再收到新字节9600波特率下3.5个字符时间大约是4ms5ms留了余量定时器中断就认为当前这一帧接收完成置一个帧完成标志主循环检测到标志后开始解析。这样能很好地处理粘包、半包和帧间隔过短的问题。实际编码时我习惯先把接收和解析彻底解耦串口中断只负责丢数据进buffer定时器中断只负责置“帧完成”标志主循环去做CRC校验和命令分发。这个模式在后面加第二路串口、加蓝牙模块时也能直接复用不会互相干扰。3.4 主流程状态机与代码框架主循环是一个典型的状态机空闲状态等待接收收到完整帧后进入校验状态CRC通过后进入执行状态按功能码分发到对应的处理函数最后组响应帧发回上位机。任一环节出错就返回MODBUS异常响应异常码有三种0x01非法功能码从机不支持该功能码0x02非法数据地址地址越界或者不存在的寄存器0x03非法数据值比如写线圈时数据不是0xFF00或0x0000注意异常响应的功能码是高位置1比如收到功能码0x05但地址非法回复的异常帧功能码应该是0x85。这个细节很多人会漏掉导致上位机解析异常。4. 6通道继电器控制与联调4.1 控制命令示例如果暂时没有组态软件用串口调试助手比如流行的XCOM、sscom直接发16进制帧就能验证基本功能。以设备地址0x01为例几个常用命令如下功能发送帧Hex说明K1吸合01 05 00 00 FF 00 8C 3A写线圈地址0数据0xFF00K1断开01 05 00 00 00 00 CD CA写线圈地址0数据0x0000读取全部状态01 01 00 00 00 06 8A 13读线圈0到5共6位这些帧的CRC是计算好的可以直接在串口助手里发送测试。收到K1吸合命令后正常的响应帧会和请求帧一模一样0x05功能码的响应就是原帧回显这就表示从机执行成功。然后观察继电器有没有咔嗒一声吸合同时用万用表量一下COM和NO引脚是否导通。如果要更系统的调试建议下载一个MODBUS Poll工具它能按周期连续轮询从机数据、自动计算CRC还能直接以表格形式编辑寄存器值比用串口助手手工拼帧高效得多。4.2 上电默认状态与安全性处理工业或智能家居场景大家最担心的往往是设备上电瞬间继电器的状态。初始化代码里有一个严格顺序先把GPIO全部配置为推挽输出、输出低电平确保所有继电器处于断开状态再初始化串口接收、开中断。如果顺序反了GPIO在复位后的浮空输入状态可能被外部干扰拉高导致上电瞬间某一路继电器误吸合。这在控制水泵、电热设备时是绝对不能接受的。有些场景需要断电恢复后保持上一次的状态那就额外加一片EEPROM比如AT24C02或者直接用STM32的Flash模拟EEPROM每次继电器状态改变时写入上电时读出并初始化GPIO。如果对状态恢复时间没要求我建议默认上电全断开逻辑最简单也是安全性最高的处理方式。另外一个很有用的做法是开独立看门狗IWDG喂狗放在主循环里。万一协议解析或者外部异常导致程序跑飞看门狗能自动复位系统避免继电器长时间维持在一个失控状态。4.3 常见问题排查表实际调试中会踩到的坑我整理了一张速查表现象可能原因排查与解决串口助手收不到任何数据USB转串口驱动未装、串口号选错、接线TX/RX交叉反了检查设备管理器COM口确认CH340或FTDI驱动正常对调TX/RX收到数据全是乱码波特率不一致、单片机时钟配置错误确认两边波特率相同检查8MHz晶振是否起振。命令发出后无响应从机地址不匹配、CRC字节序错误、静默间隔太短确认地址帧首字节重新计算CRC注意低字节在前延长帧超时时间到5ms以上继电器不动作GPIO初始化没做、驱动三极管不上拉、继电器低电平触发确认IO配置正确、基极有驱动电流、继电器模块的触发方式高/低电平继电器动作时MCU重启电源被拉垮缺续流二极管或光耦隔离线圈并联续流二极管继电器单独供电接触器/电机干扰导致通信偶发失败RS485缺少终端电阻、没做隔离在总线末端并联120Ω电阻必要时加磁珠和TVS防护5. 扩展与经验总结这个项目做完之后如果你想继续往下走有几个很自然的扩展方向第一在串口端挂一个蓝牙模块比如HC-05或者WiFi模块就能把MODBUS RTU变成无线控制手机端装一个MODBUS调试软件直接操作继电器第二把线圈区和寄存器区的定义保持不变用74HC595或MCP23017扩展GPIO一路串口控制32路甚至更多路继电器上位机代码完全不用改第三在F103上把第二路串口打开做协议转发网关让RS485总线上挂的其他MODBUS设备也能被统一管理。我在做这个项目的过程中体会最深的一点是协议这种东西越标准越省心。不要觉得MODBUS老就自己去发明新协议真正上了现场、对上位机、做联调之后你会发现MODBUS能活这么多年是有道理的。最开始花点时间把帧解析、CRC校验、异常码响应这些基础功能写扎实后面的扩展和应用都是在同一个框架上填肉而已。哪怕只是给自己做个简单的远程控制板用MODBUS RTU也一点不亏至少以后接任何组态屏你都不用在协议适配上浪费一个下午。本文还有配套的精品资源点击获取