1. 项目概述从零构建一个C语言Modbus RTU继电器控制器最近在做一个工业物联网的小项目需要远程控制几个继电器市面上现成的Modbus RTU继电器模块虽然多但要么功能太固定要么二次开发接口不友好。于是我决定自己动手用C语言从零撸一个。这听起来有点“造轮子”但实际做下来你会发现对Modbus协议的理解、对串口通信的掌控以及对嵌入式系统稳定性的考量都会提升一个层次。这个项目非常适合那些想深入工业通信协议、或者需要定制化硬件控制逻辑的嵌入式开发者。最终我们得到的不仅仅是一个能响应0x05写单个线圈和0x0F写多个线圈功能码的继电器板更是一套可以灵活移植到各种STM32、ESP32甚至Linux工控机上的核心通信框架。接下来我就把从方案选型、协议解析、代码实现到调试排坑的全过程毫无保留地分享给你。2. 核心设计思路与方案选型2.1 为什么选择Modbus RTU协议在工业控制领域通信协议的选择直接决定了系统的兼容性和稳定性。Modbus RTU之所以成为我的首选基于以下几个核心考量广泛兼容性与生态成熟度Modbus是事实上的工业标准几乎所有的SCADA系统如组态王、WinCC、HMI触摸屏以及主流的PLC西门子、三菱等都原生支持。这意味着未来你的这个自制继电器控制器可以无缝接入绝大多数现有的工业控制系统无需额外的协议转换网关极大地降低了集成成本和复杂度。你甚至可以用像“Modbus Poll”这样的通用调试软件直接对其进行测试和监控开发调试效率极高。协议本身简单高效Modbus RTU基于RS-485物理层采用主从问答式通信。协议帧结构非常简洁从站地址、功能码、数据域、CRC校验。这种简洁性带来了两个巨大优势一是对微控制器资源消耗极小一个8位单片机也能轻松跑起来二是通信效率高在9600bps的波特率下完成一次开关控制指令的收发通常在10毫秒以内完全满足大多数继电器的响应需求。相比于更复杂的TCP/IP栈或自定义二进制协议RTU模式的实现和调试门槛要低得多。成本与可靠性平衡RS-485总线支持多点通信一条总线上可以挂接多达32个甚至更多的设备通过中继器可扩展用一对双绞线就能连接所有继电器节点布线成本极低。同时RS-485的差分信号传输方式抗共模干扰能力强非常适合电气环境复杂的工厂车间。协议自带的CRC-16校验机制能有效检测传输过程中的数据错误保证了通信的可靠性。注意虽然Modbus TCP在以太网普及的今天也越来越流行但对于分散、强干扰、低成本的设备层控制RTU over RS-485仍然是不可替代的选择。除非你的所有设备都部署在机房且都有网口否则RTU是更务实的选择。2.2 硬件平台与开发环境搭建硬件是软件的舞台选对平台事半功倍。微控制器选型MCU我选择了STM32F103C8T6也就是常说的“蓝莓派”或“最小系统板”。理由很充分首先它基于ARM Cortex-M3内核性能对于处理Modbus协议绰绰有余。其次它拥有多个UART串口我们可以用一个UART专用于Modbus通信连接RS-485转换芯片另一个UART用于打印调试信息连接USB转TTL方便在电脑端用串口助手查看日志。最后它的GPIO数量足够可以轻松控制8路、16路甚至更多的继电器。当然这个框架同样适用于GD32、ESP32使用UART或Arduino软件串口或硬件串口。RS-485物理层接口这是连接MCU与外部总线关键。我选用了一颗常见的MAX3485芯片。它的作用是将MCU UART输出的TTL电平0V/3.3V转换为RS-485差分信号A、B线。这里有一个关键细节必须设计自动收发控制电路。因为RS-485是半双工的同一时刻只能有一个设备发送。我们需要用一个MCU的GPIO引脚比如PA8来控制MAX3485的发送使能端DE和接收使能端RE。当MCU要发送数据时先将这个GPIO置高使能发送器发送完成后立即置低切换回接收状态。这个切换速度必须快通常在字节之间不能有延迟否则会丢失数据。我的做法是在UART发送完成中断TC里立即拉低使能引脚。开发环境与工具链IDE我使用VSCode PlatformIO插件。PlatformIO完美集成了编译、烧录、库管理功能比传统的Keil或IAR更轻量、更现代特别是库依赖管理非常方便。调试工具硬件一个USB转RS-485的适配器用于连接电脑和你的继电器控制器。软件在电脑端我主要用两个软件Modbus Poll作为主站模拟器用于发送指令和解析响应串口调试助手如SecureCRT、Putty或PlatformIO自带的Serial Monitor用于查看控制器打印的调试信息。这两个软件窗口同时打开对照着看问题一目了然。库依赖我们不需要复杂的Modbus协议栈库。为了彻底理解原理我选择自己实现协议解析。但CRC校验计算可以使用现成的、经过优化的函数。在PlatformIO中你可以很容易地找到轻量级的CRC库或者直接从开源项目中拷贝一个可靠的crc16_modbus函数。3. Modbus RTU协议帧的深度解析与实现要实现从站必须吃透协议帧的每一个字节。Modbus RTU帧格式如下[地址][功能码][数据][CRC低][CRC高]。帧间需要至少3.5个字符时间的静默间隔作为分隔。3.1 从站地址与功能码映射从站地址1字节范围是1-2470为广播地址248-255保留。我们的继电器控制器可以设定一个拨码开关或通过软件配置这个地址实现总线上多设备共存。对于继电器线圈控制最核心的两个功能码是0x01 (Read Coils)读取线圈继电器状态。主站询问从站返回每个线圈的ON/OFF状态。0x05 (Write Single Coil)写单个线圈。强制某个继电器打开FF 00或关闭00 00。0x0F (Write Multiple Coils)写多个线圈。一次性控制多个继电器。我们的项目主要实现0x05和0x0F作为控制入口0x01用于状态反馈。下面重点剖析0x0F的请求与响应格式因为它稍微复杂一些。3.2 0x0F写多个线圈协议帧实例拆解假设我们要控制从线圈地址0开始的4个继电器对应我们板子上的4路继电器希望将第1路和第4路打开ON第2路和第3路关闭OFF。那么线圈的状态用位表示就是线圈0ON(1) 线圈1OFF(0) 线圈2OFF(0) 线圈3ON(1)。1. 主站请求帧Master → Slave我们按照协议格式一步步构建从站地址假设我们的设备地址是0x01。功能码0x0F。起始地址高/低我们要从地址0开始写所以是0x00, 0x00。线圈数量高/低我们要写4个线圈所以是0x00, 0x04。字节数4个线圈需要多少字节来存放(4个线圈 7) / 8 1字节。所以这里是0x01。数据域这1个字节如何表示4个线圈的状态Modbus规定每个线圈对应一个比特位线圈0对应最低位LSB。所以状态1,0,0,1在字节中的排列是位01, 位10, 位20, 位31。这个字节的二进制是0000 1001十六进制就是0x09。这里有个极易出错的点如果线圈数量不是8的倍数最后一个字节的高位未使用的比特位必须填0。比如只写5个线圈数据字节数还是1但这个字节只有低5位有效高3位必须为0。CRC校验计算前面所有字节01 0F 00 00 00 04 01 09的CRC-16 Modbus值。我们可以用在线计算工具验证结果假设是0xABCD低字节在前即0xCD 0xAB。最终主站发送的完整请求帧为01 0F 00 00 00 04 01 09 CD AB2. 从站正确响应帧Slave → Master如果从站成功执行了操作它应该回复从站地址0x01功能码0x0F起始地址高/低回显收到的起始地址0x00, 0x00线圈数量高/低回显收到的线圈数量0x00, 0x04CRC校验计算01 0F 00 00 00 04的CRC假设为0x1234即0x34 0x12完整响应帧01 0F 00 00 00 04 34 123. 从站异常响应帧Slave → Master如果从站处理出错例如线圈地址超范围则回复异常帧从站地址0x01功能码0x8F(原功能码 0x80)异常码例如0x02表示非法数据地址CRC校验计算01 8F 02的CRC完整异常响应帧01 8F 02 CRC163.3 CRC-16校验的软件实现要点CRC校验是保证数据正确性的最后一道关卡必须准确无误。Modbus使用的是CRC-16-IBM也称为CRC-16-MODBUS多项式是0x8005初始值是0xFFFF。这里分享一个经过验证、查表法优化的C语言实现效率极高// CRC16-MODBUS 预计算表 static const uint16_t crc16_table[256] { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, // ... 此处省略中间252个值实际代码中需补全完整的256项查表 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40 }; uint16_t modbus_crc16(const uint8_t *data, uint16_t length) { uint16_t crc 0xFFFF; // 初始值 while (length--) { crc (crc 8) ^ crc16_table[(crc ^ *data) 0xFF]; } return crc; // 注意返回的crc值低字节在前高字节在后组成帧 }实操心得务必使用查表法。如果是在资源极其紧张的8位MCU上每次收到一个字节就计算一次CRC而不是等整帧收完再算。这可以在帧接收中断服务程序ISR中完成一旦发现CRC错误可以提前丢弃该帧节省处理时间。另外发送时填充CRC一定要遵循低字节在前的规则这是Modbus RTU的标准很多新手在这里栽跟头。4. 软件架构与核心代码实现一个健壮的从站软件需要良好的状态机设计来管理串口接收、协议解析和命令执行。4.1 状态机设计与缓冲区管理我设计了一个简单的四状态接收状态机IDLE状态等待帧开始。当串口收到一个字节且距离上次接收结束超过3.5个字符时间认为新帧开始转入RECEIVING状态并重置缓冲区索引和CRC计算值。RECEIVING状态持续接收字节存入环形缓冲区或线性数组并同步计算CRC。同时启动或重置一个超时定时器例如如果超过1.5个字符时间没收到新字节则认为一帧结束。FRAME_RECEIVED状态超时定时器触发表示一帧数据接收完毕。此时校验缓冲区中最后两个字节接收到的CRC与自己计算的CRC是否匹配。若匹配则转入PROCESSING状态若不匹配则丢弃该帧回到IDLE状态并可通过调试串口打印“CRC Error”。PROCESSING状态解析帧内容地址、功能码、数据执行相应操作如驱动GPIO控制继电器然后组织响应帧放入发送缓冲区启动发送。发送完成后回到IDLE状态。typedef enum { MB_STATE_IDLE, MB_STATE_RECEIVING, MB_STATE_FRAME_RECEIVED, MB_STATE_PROCESSING } modbus_state_t; // 全局状态变量 static modbus_state_t mb_state MB_STATE_IDLE; static uint8_t rx_buffer[256]; static uint16_t rx_index 0; static uint16_t calculated_crc 0xFFFF;4.2 协议解析与命令分发核心代码在PROCESSING状态中我们解析接收到的有效帧。以下是处理0x0F功能码的核心逻辑void modbus_process_frame(uint8_t *frame, uint16_t length) { uint8_t slave_addr frame[0]; uint8_t func_code frame[1]; // 1. 检查地址是否匹配本机假设本机地址为1 if (slave_addr ! 1 slave_addr ! 0) { // 地址0是广播地址通常不响应 return; // 地址不匹配忽略此帧 } // 2. 根据功能码分发处理 switch (func_code) { case 0x0F: // 写多个线圈 handle_write_multiple_coils(frame, length); break; case 0x05: // 写单个线圈 handle_write_single_coil(frame, length); break; case 0x01: // 读线圈 handle_read_coils(frame, length); break; default: // 不支持的功能码回复异常码 0x01 (非法功能) send_exception_response(slave_addr, func_code, 0x01); break; } } void handle_write_multiple_coils(uint8_t *req, uint16_t len) { // 解析请求帧 uint16_t start_addr (req[2] 8) | req[3]; uint16_t coil_qty (req[4] 8) | req[5]; uint8_t byte_count req[6]; uint8_t *coil_data req[7]; // 检查地址和数量是否在有效范围内假设我们最多支持16路继电器 if ((start_addr coil_qty) MAX_COILS) { send_exception_response(req[0], 0x0F, 0x02); // 非法数据地址 return; } // 执行写操作将数据字节的每一位映射到对应的GPIO引脚 for (uint16_t i 0; i coil_qty; i) { uint8_t byte_index i / 8; uint8_t bit_index i % 8; uint8_t coil_value (coil_data[byte_index] bit_index) 0x01; // 控制实际的继电器GPIOON可能对应GPIO高电平也可能对应低电平取决于你的继电器模块驱动方式 set_coil_state(start_addr i, coil_value); } // 组织成功响应帧 uint8_t resp[8]; resp[0] req[0]; // 地址 resp[1] 0x0F; // 功能码 resp[2] req[2]; // 起始地址高 resp[3] req[3]; // 起始地址低 resp[4] req[4]; // 数量高 resp[5] req[5]; // 数量低 // 计算CRC并填充到resp[6], resp[7] uint16_t crc modbus_crc16(resp, 6); resp[6] crc 0xFF; resp[7] (crc 8) 0xFF; // 通过串口发送resp uart_send_bytes(resp, 8); }4.3 串口中断与超时定时器配置稳定可靠的通信依赖于精准的时序控制。串口中断配置使能UART的“接收数据寄存器非空”中断RXNE。在中断服务程序中读取接收到的字节并根据当前状态机状态进行处理。关键点是每次进入接收中断都要重置“帧间超时定时器”。void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t rx_byte USART_ReceiveData(USART1); // 重置帧间超时定时器例如设置为3.5个字符时间 timer_reset(frame_timer); switch (mb_state) { case MB_STATE_IDLE: // 开始新帧初始化缓冲区等 rx_index 0; calculated_crc 0xFFFF; rx_buffer[rx_index] rx_byte; calculated_crc update_crc(calculated_crc, rx_byte); mb_state MB_STATE_RECEIVING; break; case MB_STATE_RECEIVING: // 持续接收 if (rx_index sizeof(rx_buffer)) { rx_buffer[rx_index] rx_byte; calculated_crc update_crc(calculated_crc, rx_byte); } else { // 缓冲区溢出回到IDLE mb_state MB_STATE_IDLE; } break; // ... 其他状态处理 } } }超时定时器配置使用一个硬件定时器如TIM2配置其周期为3.5个字符时间例如在9600波特率下3.5 * 11位 / 9600 ≈ 4ms。在定时器中断中如果当前状态是RECEIVING则说明在超时周期内没有收到新字节认为一帧结束将状态改为FRAME_RECEIVED并触发主循环中的帧处理流程。void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); if (mb_state MB_STATE_RECEIVING) { mb_state MB_STATE_FRAME_RECEIVED; // 触发帧处理 } } }5. 硬件驱动与系统集成5.1 继电器驱动电路设计要点继电器是感性负载通断瞬间会产生很高的反向电动势必须妥善处理否则会损坏MCU的GPIO口甚至整个芯片。标准驱动电路MCU的GPIO引脚 - 限流电阻如1kΩ - NPN三极管如S8050的基极。三极管的集电极接继电器线圈一端和续流二极管负极继电器线圈另一端接电源VCC如12V。三极管发射极接地。续流二极管如1N4007正极接地负极接集电极。重要提示续流二极管必不可少它给继电器线圈断电时产生的反向电流提供泄放回路保护三极管。二极管应选择快恢复或肖特基二极管且耐压和电流要足够。GPIO控制逻辑根据你的继电器模块是低电平有效还是高电平有效来设置。通常GPIO输出高电平三极管导通继电器吸合。在代码中set_coil_state函数就是控制这个GPIO的高低电平。5.2 电源与隔离考虑工业现场噪声大良好的电源设计是稳定的基石。电源隔离如果条件允许为MCU的5V/3.3V数字电源和继电器的12V/24V驱动电源使用不同的隔离DC-DC模块。这能有效防止继电器动作时对数字电路的干扰。信号隔离在RS-485总线侧可以使用带隔离的RS-485收发芯片如ADM2483或者外加光耦隔离数字信号TX、RX、DE/RE控制脚进一步保护MCU。去耦电容在MCU的每个电源引脚附近放置一个0.1uF的陶瓷电容。在整板电源入口处放置一个10uF以上的电解电容或钽电容。5.3 软件看门狗与异常恢复工业设备要求长时间无故障运行必须加入看门狗Watchdog。独立看门狗IWDGSTM32的独立看门狗由独立的低速时钟驱动即使主时钟失效也能工作。在main函数的while(1)循环中定期“喂狗”。如果程序跑飞或陷入死循环无法按时喂狗看门狗将复位整个系统。喂狗策略喂狗点应放在主循环的关键路径上并且要避免在可能长时间阻塞的地方如等待某个硬件标志位喂狗。一个稳健的策略是在串口接收状态机的IDLE状态和成功处理完一帧命令后各喂一次狗。int main(void) { // 初始化硬件、看门狗等 IWDG_Enable(); // 使能独立看门狗 while (1) { // 主状态机调度 switch (mb_state) { case MB_STATE_FRAME_RECEIVED: process_received_frame(); IWDG_ReloadCounter(); // 成功处理一帧喂狗 break; case MB_STATE_IDLE: // 做一些其他后台任务 IWDG_ReloadCounter(); // 空闲时也定期喂狗 break; // ... } } }6. 调试、测试与常见问题排查实录理论完美调试“火葬场”。下面是我在调试过程中遇到的真问题及解决方法。6.1 调试流程与工具使用技巧分步调试法第一步验证硬件。先不写Modbus代码只写一个简单的GPIO测试程序控制继电器“咔哒”响确保驱动电路和电源没问题。第二步验证串口。让MCU定时通过调试串口发送“Hello World”在电脑串口助手上能看到确保串口硬件和波特率设置正确。第三步验证RS-485收发。将RS-485的A、B线短接MCU程序改为从RS-485收到什么就原样发回什么自发自收。用USB转485适配器发送数据看是否能收到同样的数据。这一步能验证自动收发控制电路和时序是否正确。常见坑发送使能DE信号切换太慢导致最后一个字节没发完就被切断或者切换太快导致第一个字节没发出去。需要用逻辑分析仪或示波器抓取DE信号和TX信号的时序确保DE在TX开始前变高在TX结束后变低。第四步接入Modbus Poll测试。在Modbus Poll中设置正确的串口、波特率、数据位、停止位、校验位。从最简单的0x05功能码开始测试先读再写。Modbus Poll使用技巧连接设置正确选择COM口、波特率如9600、数据位8、停止位1、校验None。RTU模式。Slave ID填写你的设备地址如1。Function选择05 (Write Single Coil)。Address填写线圈地址注意Modbus Poll的地址通常是“1-based”即地址1对应协议中的线圈地址0。你可以设置显示格式为“0-based”以避免混淆。Scan Rate初始测试时设为手动Manual点一次“Write”按钮发一次命令。查看原始数据打开“Display” - “Communication”窗口这里能看到收发数据的每一个字节的十六进制表示是排查CRC错误、帧格式错误的最直接窗口。6.2 常见问题、错误码与排查表下表总结了开发中最常遇到的几个“坑”现象可能原因排查步骤与解决方案Modbus Poll提示“CRC Error”或“Bytes Missing”1. 波特率、数据位、停止位、校验位不匹配。2. CRC计算错误高低字节顺序反了。3. RS-485收发切换时序问题导致帧不完整。4. 总线终端电阻未接或接错。1.核对两端串口参数必须完全一致。常用9600-8-N-1。2.检查CRC代码。用在线CRC计算器对比你代码计算的CRC和Modbus Poll发送的CRC是否一致。务必确认是低字节在前。3.用逻辑分析仪抓取A、B线差分信号和DE控制信号看数据波形是否完整DE切换点是否在数据包前后。4.在RS-485总线最远两端的设备上各接一个120Ω的终端电阻。能收到命令但继电器不动作1. GPIO引脚配置错误应为推挽输出。2. 继电器驱动电路三极管或二极管接反、损坏。3. 线圈地址映射错误。1.用万用表测量GPIO引脚电压当发送ON命令时电压应有变化如从0V变到3.3V。2.检查硬件连接特别是续流二极管方向负极接VCC侧。3.打印调试信息在set_coil_state函数里打印收到的地址和值确认解析正确。通信不稳定时好时坏1. 电源干扰。2. RS-485总线布线不规范靠近强电线路。3. 未接终端电阻或接地不良。4. 从站响应太慢主站超时。1.加强电源滤波增加磁珠、共模电感。2.使用双绞线作为RS-485通信线并远离电机、变频器等干扰源。3.检查并正确连接终端电阻和屏蔽层接地单点接地。4.优化从站代码确保在收到有效帧后尽快回复通常在几毫秒内。检查是否在中断中做了耗时操作。Modbus Poll显示“Illegal Data Address”1. 请求的线圈地址超出了你程序中定义的范围。2. 地址换算错误1-based vs 0-based。1.检查请求帧中的起始地址和数量与你程序中的MAX_COILS宏定义比较。2.统一地址规范。建议在从站程序内部全部使用0-based地址协议标准而在与Modbus Poll这类1-based工具交互时注意地址偏移。例如Modbus Poll里输入地址1你的程序应该处理地址0。多个从站通信冲突1. 从站地址重复。2. 某个从站故障持续发送数据霸占总线。1.确保总线上每个从站有唯一地址。2.为每个从站加入故障检测机制如看门狗。对于RS-485芯片检查其故障输出引脚。6.3 高级调试使用逻辑分析仪当软件调试手段用尽时逻辑分析仪是终极武器。我用的是Saleae Logic系列连接RS-485的A、B线和DE控制线。看什么看一帧完整的数据在A、B线上的差分波形以及DE信号的变化沿。怎么用设置串口解码器选择RS-485模式设置正确的波特率。你会直观地看到每个字节的数值以及DE信号是否完整地包裹住了发送数据段。如果DE信号提前拉低你会看到最后一个字节的停止位之后没有差分信号如果DE信号拉高太晚你会看到第一个字节的开始位不完整。通过调整代码中DE信号切换的时机例如在UART发送开始前拉高在发送完成中断TC中拉低直到波形完美。7. 项目优化与扩展思路一个基础版本跑通后可以考虑以下优化和扩展让你的继电器控制器更专业、更强大。7.1 功能扩展支持保持寄存器与掉电保存除了线圈Modbus的保持寄存器功能码0x03读0x06写单个0x10写多个也非常有用。你可以用它来存储设备参数比如继电器默认上电状态、通信地址、波特率等。实现要点在内存中定义一个数组作为保持寄存器映射区。实现0x03和0x06/0x10功能码的解析与响应。掉电保存当这些参数被修改时需要将其写入MCU内部的Flash或外部的EEPROM。注意Flash写入前需要先擦除扇区且寿命有限通常10万次不要频繁写入。可以设计一个“参数修改标志”只在标志置位且设备空闲时才执行实际的保存操作。7.2 性能优化响应速度与资源占用中断优化确保串口接收中断服务程序ISR尽可能短小。只做最必要的操作读取数据、存入缓冲区、更新CRC、重置超时定时器。绝对不要在ISR中解析协议或控制GPIO。缓冲区管理使用环形缓冲区Ring Buffer来接收串口数据避免线性数组的溢出和内存移动开销。动态超时超时定时器的时间可以根据波特率动态计算而不是写死。timeout (11 bits per byte * 3.5) / baud_rate。7.3 通信安全与可靠性增强广播命令处理地址0是广播地址。对于写命令从站应执行操作但不回复响应。你的代码需要识别地址0并跳过响应发送步骤。异常情况处理增加对异常帧长度的判断例如0x0F功能码的请求帧长度至少为8字节。增加对异常功能码的响应功能码0x80。通信超时与重试虽然Modbus是主从问答但从站也可以增加一种“安全模式”。如果长时间如10秒未收到任何有效命令自动将所有继电器恢复到安全状态如全部断开。7.4 移植到其他平台这套C语言核心逻辑是高度可移植的。Arduino使用SoftwareSerial库或HardwareSerial库将串口读写、定时器函数替换为Arduino的API即可。GPIO控制更简单。ESP32使用HardwareSerial并可以利用其强大的Wi-Fi和蓝牙功能将Modbus RTU网关转换为Modbus TCP接入物联网平台。Linux在树莓派或工控机上将串口操作改为操作/dev/ttyUSB0等设备文件使用termios库配置串口参数。协议解析和状态机代码几乎可以复用。整个项目做下来最大的体会是工业通信协议看起来神秘但拆解后无非是“帧格式”“状态机”“硬件操作”。把每一字节的含义搞清楚把状态切换的时机把握准把硬件底层的细节处理好剩下的就是耐心调试。当你第一次用Modbus Poll点击按钮听到自己做的继电器板“咔哒”一声响时那种成就感是直接用现成模块无法比拟的。这套代码框架我已经在几个不同的项目上用过稳定可靠希望它也能成为你工具箱里的一件利器。
1. 项目概述从零构建一个C语言Modbus RTU继电器控制器最近在做一个工业物联网的小项目需要远程控制几个继电器市面上现成的Modbus RTU继电器模块虽然多但要么功能太固定要么二次开发接口不友好。于是我决定自己动手用C语言从零撸一个。这听起来有点“造轮子”但实际做下来你会发现对Modbus协议的理解、对串口通信的掌控以及对嵌入式系统稳定性的考量都会提升一个层次。这个项目非常适合那些想深入工业通信协议、或者需要定制化硬件控制逻辑的嵌入式开发者。最终我们得到的不仅仅是一个能响应0x05写单个线圈和0x0F写多个线圈功能码的继电器板更是一套可以灵活移植到各种STM32、ESP32甚至Linux工控机上的核心通信框架。接下来我就把从方案选型、协议解析、代码实现到调试排坑的全过程毫无保留地分享给你。2. 核心设计思路与方案选型2.1 为什么选择Modbus RTU协议在工业控制领域通信协议的选择直接决定了系统的兼容性和稳定性。Modbus RTU之所以成为我的首选基于以下几个核心考量广泛兼容性与生态成熟度Modbus是事实上的工业标准几乎所有的SCADA系统如组态王、WinCC、HMI触摸屏以及主流的PLC西门子、三菱等都原生支持。这意味着未来你的这个自制继电器控制器可以无缝接入绝大多数现有的工业控制系统无需额外的协议转换网关极大地降低了集成成本和复杂度。你甚至可以用像“Modbus Poll”这样的通用调试软件直接对其进行测试和监控开发调试效率极高。协议本身简单高效Modbus RTU基于RS-485物理层采用主从问答式通信。协议帧结构非常简洁从站地址、功能码、数据域、CRC校验。这种简洁性带来了两个巨大优势一是对微控制器资源消耗极小一个8位单片机也能轻松跑起来二是通信效率高在9600bps的波特率下完成一次开关控制指令的收发通常在10毫秒以内完全满足大多数继电器的响应需求。相比于更复杂的TCP/IP栈或自定义二进制协议RTU模式的实现和调试门槛要低得多。成本与可靠性平衡RS-485总线支持多点通信一条总线上可以挂接多达32个甚至更多的设备通过中继器可扩展用一对双绞线就能连接所有继电器节点布线成本极低。同时RS-485的差分信号传输方式抗共模干扰能力强非常适合电气环境复杂的工厂车间。协议自带的CRC-16校验机制能有效检测传输过程中的数据错误保证了通信的可靠性。注意虽然Modbus TCP在以太网普及的今天也越来越流行但对于分散、强干扰、低成本的设备层控制RTU over RS-485仍然是不可替代的选择。除非你的所有设备都部署在机房且都有网口否则RTU是更务实的选择。2.2 硬件平台与开发环境搭建硬件是软件的舞台选对平台事半功倍。微控制器选型MCU我选择了STM32F103C8T6也就是常说的“蓝莓派”或“最小系统板”。理由很充分首先它基于ARM Cortex-M3内核性能对于处理Modbus协议绰绰有余。其次它拥有多个UART串口我们可以用一个UART专用于Modbus通信连接RS-485转换芯片另一个UART用于打印调试信息连接USB转TTL方便在电脑端用串口助手查看日志。最后它的GPIO数量足够可以轻松控制8路、16路甚至更多的继电器。当然这个框架同样适用于GD32、ESP32使用UART或Arduino软件串口或硬件串口。RS-485物理层接口这是连接MCU与外部总线关键。我选用了一颗常见的MAX3485芯片。它的作用是将MCU UART输出的TTL电平0V/3.3V转换为RS-485差分信号A、B线。这里有一个关键细节必须设计自动收发控制电路。因为RS-485是半双工的同一时刻只能有一个设备发送。我们需要用一个MCU的GPIO引脚比如PA8来控制MAX3485的发送使能端DE和接收使能端RE。当MCU要发送数据时先将这个GPIO置高使能发送器发送完成后立即置低切换回接收状态。这个切换速度必须快通常在字节之间不能有延迟否则会丢失数据。我的做法是在UART发送完成中断TC里立即拉低使能引脚。开发环境与工具链IDE我使用VSCode PlatformIO插件。PlatformIO完美集成了编译、烧录、库管理功能比传统的Keil或IAR更轻量、更现代特别是库依赖管理非常方便。调试工具硬件一个USB转RS-485的适配器用于连接电脑和你的继电器控制器。软件在电脑端我主要用两个软件Modbus Poll作为主站模拟器用于发送指令和解析响应串口调试助手如SecureCRT、Putty或PlatformIO自带的Serial Monitor用于查看控制器打印的调试信息。这两个软件窗口同时打开对照着看问题一目了然。库依赖我们不需要复杂的Modbus协议栈库。为了彻底理解原理我选择自己实现协议解析。但CRC校验计算可以使用现成的、经过优化的函数。在PlatformIO中你可以很容易地找到轻量级的CRC库或者直接从开源项目中拷贝一个可靠的crc16_modbus函数。3. Modbus RTU协议帧的深度解析与实现要实现从站必须吃透协议帧的每一个字节。Modbus RTU帧格式如下[地址][功能码][数据][CRC低][CRC高]。帧间需要至少3.5个字符时间的静默间隔作为分隔。3.1 从站地址与功能码映射从站地址1字节范围是1-2470为广播地址248-255保留。我们的继电器控制器可以设定一个拨码开关或通过软件配置这个地址实现总线上多设备共存。对于继电器线圈控制最核心的两个功能码是0x01 (Read Coils)读取线圈继电器状态。主站询问从站返回每个线圈的ON/OFF状态。0x05 (Write Single Coil)写单个线圈。强制某个继电器打开FF 00或关闭00 00。0x0F (Write Multiple Coils)写多个线圈。一次性控制多个继电器。我们的项目主要实现0x05和0x0F作为控制入口0x01用于状态反馈。下面重点剖析0x0F的请求与响应格式因为它稍微复杂一些。3.2 0x0F写多个线圈协议帧实例拆解假设我们要控制从线圈地址0开始的4个继电器对应我们板子上的4路继电器希望将第1路和第4路打开ON第2路和第3路关闭OFF。那么线圈的状态用位表示就是线圈0ON(1) 线圈1OFF(0) 线圈2OFF(0) 线圈3ON(1)。1. 主站请求帧Master → Slave我们按照协议格式一步步构建从站地址假设我们的设备地址是0x01。功能码0x0F。起始地址高/低我们要从地址0开始写所以是0x00, 0x00。线圈数量高/低我们要写4个线圈所以是0x00, 0x04。字节数4个线圈需要多少字节来存放(4个线圈 7) / 8 1字节。所以这里是0x01。数据域这1个字节如何表示4个线圈的状态Modbus规定每个线圈对应一个比特位线圈0对应最低位LSB。所以状态1,0,0,1在字节中的排列是位01, 位10, 位20, 位31。这个字节的二进制是0000 1001十六进制就是0x09。这里有个极易出错的点如果线圈数量不是8的倍数最后一个字节的高位未使用的比特位必须填0。比如只写5个线圈数据字节数还是1但这个字节只有低5位有效高3位必须为0。CRC校验计算前面所有字节01 0F 00 00 00 04 01 09的CRC-16 Modbus值。我们可以用在线计算工具验证结果假设是0xABCD低字节在前即0xCD 0xAB。最终主站发送的完整请求帧为01 0F 00 00 00 04 01 09 CD AB2. 从站正确响应帧Slave → Master如果从站成功执行了操作它应该回复从站地址0x01功能码0x0F起始地址高/低回显收到的起始地址0x00, 0x00线圈数量高/低回显收到的线圈数量0x00, 0x04CRC校验计算01 0F 00 00 00 04的CRC假设为0x1234即0x34 0x12完整响应帧01 0F 00 00 00 04 34 123. 从站异常响应帧Slave → Master如果从站处理出错例如线圈地址超范围则回复异常帧从站地址0x01功能码0x8F(原功能码 0x80)异常码例如0x02表示非法数据地址CRC校验计算01 8F 02的CRC完整异常响应帧01 8F 02 CRC163.3 CRC-16校验的软件实现要点CRC校验是保证数据正确性的最后一道关卡必须准确无误。Modbus使用的是CRC-16-IBM也称为CRC-16-MODBUS多项式是0x8005初始值是0xFFFF。这里分享一个经过验证、查表法优化的C语言实现效率极高// CRC16-MODBUS 预计算表 static const uint16_t crc16_table[256] { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, // ... 此处省略中间252个值实际代码中需补全完整的256项查表 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40 }; uint16_t modbus_crc16(const uint8_t *data, uint16_t length) { uint16_t crc 0xFFFF; // 初始值 while (length--) { crc (crc 8) ^ crc16_table[(crc ^ *data) 0xFF]; } return crc; // 注意返回的crc值低字节在前高字节在后组成帧 }实操心得务必使用查表法。如果是在资源极其紧张的8位MCU上每次收到一个字节就计算一次CRC而不是等整帧收完再算。这可以在帧接收中断服务程序ISR中完成一旦发现CRC错误可以提前丢弃该帧节省处理时间。另外发送时填充CRC一定要遵循低字节在前的规则这是Modbus RTU的标准很多新手在这里栽跟头。4. 软件架构与核心代码实现一个健壮的从站软件需要良好的状态机设计来管理串口接收、协议解析和命令执行。4.1 状态机设计与缓冲区管理我设计了一个简单的四状态接收状态机IDLE状态等待帧开始。当串口收到一个字节且距离上次接收结束超过3.5个字符时间认为新帧开始转入RECEIVING状态并重置缓冲区索引和CRC计算值。RECEIVING状态持续接收字节存入环形缓冲区或线性数组并同步计算CRC。同时启动或重置一个超时定时器例如如果超过1.5个字符时间没收到新字节则认为一帧结束。FRAME_RECEIVED状态超时定时器触发表示一帧数据接收完毕。此时校验缓冲区中最后两个字节接收到的CRC与自己计算的CRC是否匹配。若匹配则转入PROCESSING状态若不匹配则丢弃该帧回到IDLE状态并可通过调试串口打印“CRC Error”。PROCESSING状态解析帧内容地址、功能码、数据执行相应操作如驱动GPIO控制继电器然后组织响应帧放入发送缓冲区启动发送。发送完成后回到IDLE状态。typedef enum { MB_STATE_IDLE, MB_STATE_RECEIVING, MB_STATE_FRAME_RECEIVED, MB_STATE_PROCESSING } modbus_state_t; // 全局状态变量 static modbus_state_t mb_state MB_STATE_IDLE; static uint8_t rx_buffer[256]; static uint16_t rx_index 0; static uint16_t calculated_crc 0xFFFF;4.2 协议解析与命令分发核心代码在PROCESSING状态中我们解析接收到的有效帧。以下是处理0x0F功能码的核心逻辑void modbus_process_frame(uint8_t *frame, uint16_t length) { uint8_t slave_addr frame[0]; uint8_t func_code frame[1]; // 1. 检查地址是否匹配本机假设本机地址为1 if (slave_addr ! 1 slave_addr ! 0) { // 地址0是广播地址通常不响应 return; // 地址不匹配忽略此帧 } // 2. 根据功能码分发处理 switch (func_code) { case 0x0F: // 写多个线圈 handle_write_multiple_coils(frame, length); break; case 0x05: // 写单个线圈 handle_write_single_coil(frame, length); break; case 0x01: // 读线圈 handle_read_coils(frame, length); break; default: // 不支持的功能码回复异常码 0x01 (非法功能) send_exception_response(slave_addr, func_code, 0x01); break; } } void handle_write_multiple_coils(uint8_t *req, uint16_t len) { // 解析请求帧 uint16_t start_addr (req[2] 8) | req[3]; uint16_t coil_qty (req[4] 8) | req[5]; uint8_t byte_count req[6]; uint8_t *coil_data req[7]; // 检查地址和数量是否在有效范围内假设我们最多支持16路继电器 if ((start_addr coil_qty) MAX_COILS) { send_exception_response(req[0], 0x0F, 0x02); // 非法数据地址 return; } // 执行写操作将数据字节的每一位映射到对应的GPIO引脚 for (uint16_t i 0; i coil_qty; i) { uint8_t byte_index i / 8; uint8_t bit_index i % 8; uint8_t coil_value (coil_data[byte_index] bit_index) 0x01; // 控制实际的继电器GPIOON可能对应GPIO高电平也可能对应低电平取决于你的继电器模块驱动方式 set_coil_state(start_addr i, coil_value); } // 组织成功响应帧 uint8_t resp[8]; resp[0] req[0]; // 地址 resp[1] 0x0F; // 功能码 resp[2] req[2]; // 起始地址高 resp[3] req[3]; // 起始地址低 resp[4] req[4]; // 数量高 resp[5] req[5]; // 数量低 // 计算CRC并填充到resp[6], resp[7] uint16_t crc modbus_crc16(resp, 6); resp[6] crc 0xFF; resp[7] (crc 8) 0xFF; // 通过串口发送resp uart_send_bytes(resp, 8); }4.3 串口中断与超时定时器配置稳定可靠的通信依赖于精准的时序控制。串口中断配置使能UART的“接收数据寄存器非空”中断RXNE。在中断服务程序中读取接收到的字节并根据当前状态机状态进行处理。关键点是每次进入接收中断都要重置“帧间超时定时器”。void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t rx_byte USART_ReceiveData(USART1); // 重置帧间超时定时器例如设置为3.5个字符时间 timer_reset(frame_timer); switch (mb_state) { case MB_STATE_IDLE: // 开始新帧初始化缓冲区等 rx_index 0; calculated_crc 0xFFFF; rx_buffer[rx_index] rx_byte; calculated_crc update_crc(calculated_crc, rx_byte); mb_state MB_STATE_RECEIVING; break; case MB_STATE_RECEIVING: // 持续接收 if (rx_index sizeof(rx_buffer)) { rx_buffer[rx_index] rx_byte; calculated_crc update_crc(calculated_crc, rx_byte); } else { // 缓冲区溢出回到IDLE mb_state MB_STATE_IDLE; } break; // ... 其他状态处理 } } }超时定时器配置使用一个硬件定时器如TIM2配置其周期为3.5个字符时间例如在9600波特率下3.5 * 11位 / 9600 ≈ 4ms。在定时器中断中如果当前状态是RECEIVING则说明在超时周期内没有收到新字节认为一帧结束将状态改为FRAME_RECEIVED并触发主循环中的帧处理流程。void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); if (mb_state MB_STATE_RECEIVING) { mb_state MB_STATE_FRAME_RECEIVED; // 触发帧处理 } } }5. 硬件驱动与系统集成5.1 继电器驱动电路设计要点继电器是感性负载通断瞬间会产生很高的反向电动势必须妥善处理否则会损坏MCU的GPIO口甚至整个芯片。标准驱动电路MCU的GPIO引脚 - 限流电阻如1kΩ - NPN三极管如S8050的基极。三极管的集电极接继电器线圈一端和续流二极管负极继电器线圈另一端接电源VCC如12V。三极管发射极接地。续流二极管如1N4007正极接地负极接集电极。重要提示续流二极管必不可少它给继电器线圈断电时产生的反向电流提供泄放回路保护三极管。二极管应选择快恢复或肖特基二极管且耐压和电流要足够。GPIO控制逻辑根据你的继电器模块是低电平有效还是高电平有效来设置。通常GPIO输出高电平三极管导通继电器吸合。在代码中set_coil_state函数就是控制这个GPIO的高低电平。5.2 电源与隔离考虑工业现场噪声大良好的电源设计是稳定的基石。电源隔离如果条件允许为MCU的5V/3.3V数字电源和继电器的12V/24V驱动电源使用不同的隔离DC-DC模块。这能有效防止继电器动作时对数字电路的干扰。信号隔离在RS-485总线侧可以使用带隔离的RS-485收发芯片如ADM2483或者外加光耦隔离数字信号TX、RX、DE/RE控制脚进一步保护MCU。去耦电容在MCU的每个电源引脚附近放置一个0.1uF的陶瓷电容。在整板电源入口处放置一个10uF以上的电解电容或钽电容。5.3 软件看门狗与异常恢复工业设备要求长时间无故障运行必须加入看门狗Watchdog。独立看门狗IWDGSTM32的独立看门狗由独立的低速时钟驱动即使主时钟失效也能工作。在main函数的while(1)循环中定期“喂狗”。如果程序跑飞或陷入死循环无法按时喂狗看门狗将复位整个系统。喂狗策略喂狗点应放在主循环的关键路径上并且要避免在可能长时间阻塞的地方如等待某个硬件标志位喂狗。一个稳健的策略是在串口接收状态机的IDLE状态和成功处理完一帧命令后各喂一次狗。int main(void) { // 初始化硬件、看门狗等 IWDG_Enable(); // 使能独立看门狗 while (1) { // 主状态机调度 switch (mb_state) { case MB_STATE_FRAME_RECEIVED: process_received_frame(); IWDG_ReloadCounter(); // 成功处理一帧喂狗 break; case MB_STATE_IDLE: // 做一些其他后台任务 IWDG_ReloadCounter(); // 空闲时也定期喂狗 break; // ... } } }6. 调试、测试与常见问题排查实录理论完美调试“火葬场”。下面是我在调试过程中遇到的真问题及解决方法。6.1 调试流程与工具使用技巧分步调试法第一步验证硬件。先不写Modbus代码只写一个简单的GPIO测试程序控制继电器“咔哒”响确保驱动电路和电源没问题。第二步验证串口。让MCU定时通过调试串口发送“Hello World”在电脑串口助手上能看到确保串口硬件和波特率设置正确。第三步验证RS-485收发。将RS-485的A、B线短接MCU程序改为从RS-485收到什么就原样发回什么自发自收。用USB转485适配器发送数据看是否能收到同样的数据。这一步能验证自动收发控制电路和时序是否正确。常见坑发送使能DE信号切换太慢导致最后一个字节没发完就被切断或者切换太快导致第一个字节没发出去。需要用逻辑分析仪或示波器抓取DE信号和TX信号的时序确保DE在TX开始前变高在TX结束后变低。第四步接入Modbus Poll测试。在Modbus Poll中设置正确的串口、波特率、数据位、停止位、校验位。从最简单的0x05功能码开始测试先读再写。Modbus Poll使用技巧连接设置正确选择COM口、波特率如9600、数据位8、停止位1、校验None。RTU模式。Slave ID填写你的设备地址如1。Function选择05 (Write Single Coil)。Address填写线圈地址注意Modbus Poll的地址通常是“1-based”即地址1对应协议中的线圈地址0。你可以设置显示格式为“0-based”以避免混淆。Scan Rate初始测试时设为手动Manual点一次“Write”按钮发一次命令。查看原始数据打开“Display” - “Communication”窗口这里能看到收发数据的每一个字节的十六进制表示是排查CRC错误、帧格式错误的最直接窗口。6.2 常见问题、错误码与排查表下表总结了开发中最常遇到的几个“坑”现象可能原因排查步骤与解决方案Modbus Poll提示“CRC Error”或“Bytes Missing”1. 波特率、数据位、停止位、校验位不匹配。2. CRC计算错误高低字节顺序反了。3. RS-485收发切换时序问题导致帧不完整。4. 总线终端电阻未接或接错。1.核对两端串口参数必须完全一致。常用9600-8-N-1。2.检查CRC代码。用在线CRC计算器对比你代码计算的CRC和Modbus Poll发送的CRC是否一致。务必确认是低字节在前。3.用逻辑分析仪抓取A、B线差分信号和DE控制信号看数据波形是否完整DE切换点是否在数据包前后。4.在RS-485总线最远两端的设备上各接一个120Ω的终端电阻。能收到命令但继电器不动作1. GPIO引脚配置错误应为推挽输出。2. 继电器驱动电路三极管或二极管接反、损坏。3. 线圈地址映射错误。1.用万用表测量GPIO引脚电压当发送ON命令时电压应有变化如从0V变到3.3V。2.检查硬件连接特别是续流二极管方向负极接VCC侧。3.打印调试信息在set_coil_state函数里打印收到的地址和值确认解析正确。通信不稳定时好时坏1. 电源干扰。2. RS-485总线布线不规范靠近强电线路。3. 未接终端电阻或接地不良。4. 从站响应太慢主站超时。1.加强电源滤波增加磁珠、共模电感。2.使用双绞线作为RS-485通信线并远离电机、变频器等干扰源。3.检查并正确连接终端电阻和屏蔽层接地单点接地。4.优化从站代码确保在收到有效帧后尽快回复通常在几毫秒内。检查是否在中断中做了耗时操作。Modbus Poll显示“Illegal Data Address”1. 请求的线圈地址超出了你程序中定义的范围。2. 地址换算错误1-based vs 0-based。1.检查请求帧中的起始地址和数量与你程序中的MAX_COILS宏定义比较。2.统一地址规范。建议在从站程序内部全部使用0-based地址协议标准而在与Modbus Poll这类1-based工具交互时注意地址偏移。例如Modbus Poll里输入地址1你的程序应该处理地址0。多个从站通信冲突1. 从站地址重复。2. 某个从站故障持续发送数据霸占总线。1.确保总线上每个从站有唯一地址。2.为每个从站加入故障检测机制如看门狗。对于RS-485芯片检查其故障输出引脚。6.3 高级调试使用逻辑分析仪当软件调试手段用尽时逻辑分析仪是终极武器。我用的是Saleae Logic系列连接RS-485的A、B线和DE控制线。看什么看一帧完整的数据在A、B线上的差分波形以及DE信号的变化沿。怎么用设置串口解码器选择RS-485模式设置正确的波特率。你会直观地看到每个字节的数值以及DE信号是否完整地包裹住了发送数据段。如果DE信号提前拉低你会看到最后一个字节的停止位之后没有差分信号如果DE信号拉高太晚你会看到第一个字节的开始位不完整。通过调整代码中DE信号切换的时机例如在UART发送开始前拉高在发送完成中断TC中拉低直到波形完美。7. 项目优化与扩展思路一个基础版本跑通后可以考虑以下优化和扩展让你的继电器控制器更专业、更强大。7.1 功能扩展支持保持寄存器与掉电保存除了线圈Modbus的保持寄存器功能码0x03读0x06写单个0x10写多个也非常有用。你可以用它来存储设备参数比如继电器默认上电状态、通信地址、波特率等。实现要点在内存中定义一个数组作为保持寄存器映射区。实现0x03和0x06/0x10功能码的解析与响应。掉电保存当这些参数被修改时需要将其写入MCU内部的Flash或外部的EEPROM。注意Flash写入前需要先擦除扇区且寿命有限通常10万次不要频繁写入。可以设计一个“参数修改标志”只在标志置位且设备空闲时才执行实际的保存操作。7.2 性能优化响应速度与资源占用中断优化确保串口接收中断服务程序ISR尽可能短小。只做最必要的操作读取数据、存入缓冲区、更新CRC、重置超时定时器。绝对不要在ISR中解析协议或控制GPIO。缓冲区管理使用环形缓冲区Ring Buffer来接收串口数据避免线性数组的溢出和内存移动开销。动态超时超时定时器的时间可以根据波特率动态计算而不是写死。timeout (11 bits per byte * 3.5) / baud_rate。7.3 通信安全与可靠性增强广播命令处理地址0是广播地址。对于写命令从站应执行操作但不回复响应。你的代码需要识别地址0并跳过响应发送步骤。异常情况处理增加对异常帧长度的判断例如0x0F功能码的请求帧长度至少为8字节。增加对异常功能码的响应功能码0x80。通信超时与重试虽然Modbus是主从问答但从站也可以增加一种“安全模式”。如果长时间如10秒未收到任何有效命令自动将所有继电器恢复到安全状态如全部断开。7.4 移植到其他平台这套C语言核心逻辑是高度可移植的。Arduino使用SoftwareSerial库或HardwareSerial库将串口读写、定时器函数替换为Arduino的API即可。GPIO控制更简单。ESP32使用HardwareSerial并可以利用其强大的Wi-Fi和蓝牙功能将Modbus RTU网关转换为Modbus TCP接入物联网平台。Linux在树莓派或工控机上将串口操作改为操作/dev/ttyUSB0等设备文件使用termios库配置串口参数。协议解析和状态机代码几乎可以复用。整个项目做下来最大的体会是工业通信协议看起来神秘但拆解后无非是“帧格式”“状态机”“硬件操作”。把每一字节的含义搞清楚把状态切换的时机把握准把硬件底层的细节处理好剩下的就是耐心调试。当你第一次用Modbus Poll点击按钮听到自己做的继电器板“咔哒”一声响时那种成就感是直接用现成模块无法比拟的。这套代码框架我已经在几个不同的项目上用过稳定可靠希望它也能成为你工具箱里的一件利器。
