基于STM32的PLC开发实战：从架构设计到工业应用

1. 项目缘起与目标定位几年前我们团队在工业嵌入式控制领域已经积累了不少项目经验从简单的单片机控制到复杂的多轴运动系统都有涉猎。但市场在变客户的需求也在升级。我们注意到很多中小型自动化设备厂商一方面对进口PLC可编程逻辑控制器的高昂价格和封闭生态感到头疼另一方面又觉得市面上一些低成本的国产PLC在性能和可靠性上差点意思。这中间似乎存在一个市场空档一款基于成熟、高性能的ARM Cortex-M内核兼具灵活性与可靠性的PLC产品。当时ST的STM32系列正凭借其出色的性价比和丰富的生态在国内攻城略地。一个想法自然而然地冒了出来为什么不把我们擅长的嵌入式开发能力与PLC这个标准化的工业控制产品结合起来呢用STM32做核心打造一款我们自己的PLC。这个想法就是“基于STM32的PLC”项目的起点。它的核心目标很明确利用STM32的性能和成本优势开发一款功能对标主流小型PLC、具备梯形图编程能力和工业总线通讯能力的产品目标是切入中低端自动化市场实现进口替代。这个项目对我们来说不仅仅是一个新产品开发更是一次技术能力的“升维”挑战。它要求我们从过去相对定制化的嵌入式软件思维转向标准化、图形化、高可靠性的工业控制器开发思维。整个过程充满了从硬件选型、实时操作系统适配、梯形图编译器开发到工业通讯协议栈实现的硬仗。今天我就把这个项目的完整历程、核心技术和踩过的那些“坑”系统地梳理一遍希望能给想涉足工业控制或者正在做类似产品的朋友一些实实在在的参考。2. 整体架构设计与核心思路拆解做PLC尤其是想替代三菱、西门子这些老牌厂商的部分产品绝不是简单地把STM32跑起来、接几个IO口那么简单。它是一套完整的软硬件体系。我们的设计思路可以概括为“硬件平台化软件分层化生态兼容化”。2.1 硬件平台化为什么是STM32F4硬件是基石。PLC对处理器的要求有几个关键点实时性、计算能力、外设丰富度、可靠性和成本。我们当时评估了多款MCU。早期的PLC多用8位或16位单片机但处理复杂逻辑和通讯时力不从心。一些高端PLC会用到MPU甚至x86但成本和功耗对我们目标市场来说太高。STM32的Cortex-M系列特别是M3和M4内核成了一个完美的平衡点。我们最终选择了STM32F407系列作为核心。理由很充分Cortex-M4内核带FPU这对于后续实现PID控制、浮点运算等高级指令至关重要软件做浮点模拟效率太低。主频168MHz提供了充足的性能裕量不仅能流畅运行实时操作系统RTOS还能为梯形图解释执行、通讯协议处理留出足够时间。丰富的外设这是STM32的强项。我们需要的多路USART/UART用于Modbus RTU串口通讯、编程口、调试口。CAN控制器原生支持CAN 2.0B这是实现CANopen等工业总线的基础比用外扩芯片稳定得多。高级定时器TIM1, TIM8支持互补带死区的PWM输出这是实现4路高速脉冲输出控制步进/伺服的关键频率轻松达到200KHz以上。多个通用定时器用于实现高速计数器HSC功能通过编码器接口模式可以直接连接正交编码器。充足的SRAM和FlashF407有192KB RAM和1MB Flash足够存储用户梯形图程序、数据寄存器和系统固件。工业级温度范围-40°C 到 85°C满足大多数工业环境要求。成熟的生态与供货这是量产产品的生命线ST的供货和资料支持在当时已经非常好了。注意硬件选型时一定要考虑5-10年的产品生命周期和供货稳定性。我们曾考虑过某款性能稍强的国产MCU但评估其供货渠道和长期支持后还是选择了更成熟的STM32。对于工业产品稳定压倒一切。2.2 软件分层化从寄存器到梯形图的跨越软件架构是PLC的灵魂。一个清晰的分层结构能让开发、维护和扩展事半功倍。我们设计的软件栈自底向上分为四层硬件抽象层HAL与驱动层基于STM32 HAL库或直接操作寄存器封装所有硬件操作。包括GPIO数字量输入输出、ADC模拟量输入、DAC/PWM模拟量/脉冲输出、定时器高速计数、定时中断、UART、CAN、SPI等驱动。这一层要确保高效和绝对可靠特别是中断服务程序ISR要尽可能短小精悍。实时操作系统RTOS层PLC需要同时处理多任务扫描用户程序、处理通讯请求、执行高速计数和脉冲输出、进行看门狗监控等。一个轻量级的RTOS是必须的。我们选择了FreeRTOS因为它免费、开源、稳定且对STM32支持极好。我们创建了几个核心任务主扫描任务周期性地执行用户梯形图程序这是PLC的“心跳”。通讯任务处理Modbus TCP/RTU、CANopen等协议栈与上位机或其他设备通信。高速处理任务优先级最高用于响应高速计数器中断和精确的脉冲输出控制。系统监控任务管理看门狗、LED指示灯、错误日志等。PLC运行时Runtime层这是最核心的一层它负责解释和执行用户程序。我们实现了虚拟执行引擎一个小的虚拟机可以执行编译后的“指令表”一种类似于汇编的中间代码。软元件管理管理X输入继电器、Y输出继电器、M辅助继电器、D数据寄存器、T定时器、C计数器等PLC的“软元件”本质上是在RAM中划分出不同的内存区域。系统时钟与扫描周期管理控制主扫描任务的执行节奏确保周期性稳定。编程工具链上位机这是用户直接接触的部分。我们开发了一个基于PC的梯形图编程软件。它的工作流程是用户绘制梯形图 - 软件进行语法和逻辑检查 - 将梯形图编译成紧凑的指令表 - 通过串口或以太网下载到STM32 PLC的Runtime层执行。2.3 生态兼容化为什么支持梯形图和Modbus/CAN这是产品能否被市场接受的关键。我们决定部分兼容主流小型PLC如三菱FX系列的编程习惯和通讯协议。梯形图编程这是工控工程师最熟悉的语言学习成本低。我们并没有完全照搬某一家而是吸收了主流梯形图的共性元素如常开/常闭触点、线圈、定时器/计数器方块、应用指令形成了自己的指令集。兼容性是为了降低用户迁移门槛但完全兼容意味着巨大的开发和专利风险需要谨慎权衡。Modbus通讯这是工业领域事实上的串行通讯标准几乎所有的HMI人机界面、传感器、仪表都支持。我们在STM32上移植了开源的FreeMODBUS协议栈实现了RTU和TCP从站功能让我们的PLC能轻松融入现有系统。CAN总线在汽车、轨道交通、高端机械设备中应用广泛。我们基于STM32的CAN控制器实现了CAN 2.0B的底层驱动并在此基础上计划后期集成CANopen协议栈实现多节点组网控制。这个“兼容化”策略极大地降低了客户的学习成本和系统集成难度是我们产品能够快速切入市场的重要原因。3. 核心功能模块的深度实现有了顶层设计接下来就是啃下一个又一个硬骨头。这里我挑几个最有代表性的功能模块讲讲具体是怎么做的。3.1 梯形图编译与执行引擎的实现这是整个项目的技术制高点。我们的思路是“编译解释”混合执行。第一步梯形图到指令表的编译在上位机完成梯形图本质上是一种图形化的布尔逻辑和控制流程描述。我们的编译器工作流程如下语法解析将梯形图网络Network解析成节点触点、线圈、功能块和连接关系构成一个有向图。逻辑化简与优化对简单的并联、串联触点进行逻辑化简减少运行时计算量。生成指令表将优化后的逻辑图按扫描顺序从左到右从上到下转换成一系列虚拟机指令。这些指令非常精简例如LD X0将输入X0的状态0或1加载到运算栈顶。AND X1将栈顶值与X1的状态进行逻辑“与”结果存回栈顶。OUT Y0将栈顶值输出到线圈Y0。CALL PID D100 D200 D300调用PID功能块参数在D100, D200, D300寄存器中。地址分配为所有用到的软元件X, Y, M, D等分配在Runtime内存中的实际地址。第二步指令表在STM32上的解释执行在Runtime层完成STM32中的Runtime引擎就是一个循环解释执行这些指令的小型虚拟机。// 简化的虚拟机循环示意 void plc_vm_execute_cycle(void) { uint8_t *program_counter instruction_memory[0]; // 指令指针 while(*program_counter ! OPCODE_END) { // 遇到结束指令停止 switch(*program_counter) { case OPCODE_LD: program_counter; int addr *(uint16_t*)program_counter; // 读取操作数地址 stack_push(get_io_value(addr)); // 从IO映射区取值压栈 program_counter 2; break; case OPCODE_AND: program_counter; addr *(uint16_t*)program_counter; stack_top() get_io_value(addr); // 栈顶与操作数“与” program_counter 2; break; case OPCODE_OUT: program_counter; addr *(uint16_t*)program_counter; set_io_value(addr, stack_pop()); // 出栈并写入输出映射区 program_counter 2; break; // ... 处理其他指令 } } // 一个扫描周期结束将输出映射区的值同步到物理GPIO io_sync_outputs(); }这个执行引擎被放在FreeRTOS的一个定时任务中以固定的扫描周期例如10ms循环执行从而实现了PLC的确定性扫描。实操心得扫描周期的稳定性是PLC可靠性的核心。我们最初将虚拟机循环放在一个简单while里发现扫描时间会随程序复杂度波动。后来改为定时任务看门狗机制FreeRTOS任务以固定周期唤醒执行同时用一个硬件看门狗监控整个任务执行流程。如果某次扫描超时可能由于程序死循环看门狗会复位系统保证设备能从故障中恢复。这是工业产品必须具备的“自愈”能力。3.2 高速脉冲输出与高速计数器这是实现精确定位和速度测量的关键。STM32的高级定时器如TIM1, TIM8是完美实现这两项功能的硬件基础。高速脉冲输出PTO 目标产生频率、脉冲数均可控的方波用于驱动步进电机或伺服驱动器的脉冲方向接口。 实现我们使用定时器的PWM输出模式结合DMA和中断。频率控制通过配置定时器的预分频器PSC和自动重载寄存器ARR来设定PWM的频率。例如产生100kHz的脉冲系统时钟84MHz预分频设为0ARR设为840-1即可。脉冲数控制这是难点。我们采用“更新中断递减计数器”的方式。在定时器的更新中断UEV服务函数中对一个全局脉冲计数器进行递减。当减到0时在中断里关闭定时器输出或切换到一个固定占空比的PWM停止发脉冲。同时为了减轻CPU负担脉冲序列的启停控制可以通过DMA来改变CCR捕获/比较寄存器的值来实现更复杂的脉冲包络。// 简化的脉冲数控制中断服务例程 void TIM1_UP_IRQHandler(void) { if(TIM1-SR TIM_SR_UIF) { // 更新中断标志 TIM1-SR ~TIM_SR_UIF; // 清除标志 if(pulse_counter 0) { pulse_counter--; } else { // 脉冲发完停止输出或保持最后状态 HAL_TIM_PWM_Stop(htim1, TIM_CHANNEL_1); } } }高速计数器HSC 目标对来自编码器的A/B相正交脉冲进行高速计数频率可达200KHz以上。 实现STM32的通用定时器如TIM2-TIM5直接支持编码器接口模式。只需将编码器的A、B相信号接到定时器的CH1和CH2通道然后配置定时器为编码器模式即可。定时器的计数器CNT寄存器会自动根据A、B相的边沿和方向进行增减计数完全由硬件完成不占用CPU资源。我们只需要在需要的时候例如在扫描周期开始时去读取CNT的值并经过换算得到位置或速度信息。// 配置TIM3为编码器模式 TIM_Encoder_InitTypeDef sConfig {0}; sConfig.EncoderMode TIM_ENCODERMODE_TI12; // 在TI1和TI2边沿都计数 sConfig.IC1Polarity TIM_ICPOLARITY_RISING; sConfig.IC1Selection TIM_ICSELECTION_DIRECTTI; sConfig.IC1Prescaler TIM_ICPSC_DIV1; // 不分频 sConfig.IC1Filter 6; // 设置滤波器抗干扰 // ... 类似配置IC2 HAL_TIM_Encoder_Init(htim3, sConfig); HAL_TIM_Encoder_Start(htim3, TIM_CHANNEL_ALL); // 启动编码器接口 // 之后随时读取 htim3.Instance-CNT 即可获得计数值踩坑记录高速脉冲和计数最怕干扰。我们最初的产品在电机启停时偶尔会出现计数不准或脉冲丢失。排查后发现是电源和地线处理不当电机的大电流变化引起了电源噪声。解决方案是模拟电源与数字电源、电机驱动电源彻底隔离编码器信号线使用双绞屏蔽线并在MCU入口处加RC滤波和钳位二极管PCB布局上高速信号线远离噪声源并保证完整的地平面。这些硬件上的功夫是软件无法弥补的。3.3 工业通讯协议栈的集成PLC不是孤岛必须能联网。我们集成了Modbus和CAN。Modbus RTU/TCP 我们选择了开源的FreeMODBUS协议栈进行移植。移植工作主要围绕端口层展开RTU串口实现xMBPortSerialInit,xMBPortSerialPutByte,xMBPortSerialGetByte等函数底层调用STM32的HAL_UART函数。注意串口中断的优先级设置不能影响高速定时器中断。TCP以太网这需要STM32具备以太网MAC如STM32F407自带或外接PHY芯片。我们使用了LWIP这个轻量级TCP/IP协议栈。移植工作是将FreeMODBUS的TCP层与LWIP的Socket API对接。关键点在于处理好LWIP的网络任务与FreeMODBUS轮询任务之间的数据交换通常使用消息队列或信号量。CAN总线应用 我们首先实现了裸的CAN 2.0B通讯提供基础的发送/接收帧的API。这对于点对点通讯或简单的自定义主从协议已经足够。例如可以定义一种简单的命令-响应协议让主站读写PLC的寄存器。// 自定义的简单CAN应用层协议帧结构 typedef struct { uint32_t id; // CAN ID包含优先级、源地址、目标地址等信息 uint8_t data[8]; // 数据域 // data[0]: 命令码 (如 0x01读0x02写) // data[1]: 寄存器类型 (如 0xD0 代表D寄存器) // data[2-3]: 寄存器地址 // data[4-7]: 数据值如果是写命令 } simple_can_frame_t;对于更复杂的多主、分布式系统我们计划集成CANopen协议栈如CANopenNode。这是一个系统工程需要实现对象字典OD、网络管理NMT、过程数据对象PDO和服务数据对象SDO等机制。这通常是产品迭代到更高阶段的任务。4. 开发流程、测试与问题排查实录4.1 从原理图到样机的实战流程我们的硬件开发遵循标准的流程但针对PLC做了特别强化原理图设计核心最小系统STM32F407、复位电路、晶振8MHz主晶振32.768KHz RTC晶振、启动模式选择、调试接口SWD。电源树设计这是工业产品的生命线。输入采用24VDC工业电源通过宽压输入DC-DC模块如9-36V输入转5V得到5V再用LDO如AMS1117-3.3得到3.3V给MCU和数字电路。模拟电路部分如果有使用独立的LDO供电。TVS管和压敏电阻用于电源入口的浪涌防护。数字量输入DI电路采用光耦隔离如TLP281将外部的24V/0V信号隔离转换为MCU的3.3V/0V信号。串联电阻限流并接双向TVS防过压。数字量输出DO电路晶体管输出型。MCU GPIO通过限流电阻驱动光耦光耦驱动MOSFET如AO3400来控制外部24V负载。输出端必须并联续流二极管给感性负载继电器、电磁阀提供泄放回路。模拟量输入/输出根据精度要求选择ADC/DACSTM32内置或外扩前端/后端必须配合运算放大器进行信号调理缩放、偏移、滤波。通讯接口RS485接口使用隔离型收发器如ADM2483CAN接口使用隔离型CAN收发器如ISO1050。注意终端电阻的配置。PCB Layout要点强电弱电分区将电源模块、输出驱动等大电流区域与MCU、通讯等小信号区域严格分开。地平面分割与单点连接数字地、模拟地、电源地功率地在底层通过磁珠或0欧电阻在一点连接形成“星型接地”。信号完整性高速脉冲PWM和编码器信号线尽可能短走差分线包地处理。时钟线远离其他信号线。散热与安规功率器件下方铺铜并开窗加锡保证散热。注意爬电距离和电气间隙特别是高压部分。软件调试分模块调试先调通HAL库和FreeRTOS让LED闪烁起来。然后逐个调试GPIO输入输出、定时器PWM、编码器计数、串口通讯、CAN通讯。使用调试器STM32的SWD接口配合J-Link或ST-Link是必备的。善用断点、实时变量观察、串口打印。逻辑分析仪是神器对于调试PWM波形、编码器信号、串口/CAN数据帧一个便宜的USB逻辑分析仪比示波器更直观。4.2 典型问题排查与解决技巧在开发和测试中我们遇到了无数问题。这里列几个典型的问题一PLC运行一段时间后死机或无响应。排查思路看门狗首先检查独立看门狗IWDG和窗口看门狗WWDG是否启用并正确喂狗。这是第一道防线。堆栈溢出这是FreeRTOS中最常见的问题。使用FreeRTOS提供的uxTaskGetStackHighWaterMark()函数检查每个任务的剩余堆栈空间在开发阶段预留足够余量比如比峰值使用量多50%。内存泄漏检查是否有动态内存分配malloc/free未配对。在嵌入式系统尤其是RTOS中建议使用静态内存分配或者使用RTOS提供的内存管理API。中断冲突检查中断优先级配置。确保系统滴答定时器Systick和PendSV的优先级最低高速计数器、通讯中断的优先级合理且没有中断服务程序执行时间过长。电源问题用示波器监测3.3V电源纹波特别是在大负载开关瞬间。纹波过大会导致MCU工作异常。问题二高速计数器在电机高速运行时计数不准。排查思路信号质量用示波器看编码器的A、B相信号。是否有毛刺幅值是否足够通常应为3.3V或5V边沿是否陡峭滤波器配置STM32的定时器输入通道有数字滤波器。如果信号有抖动适当增加滤波器参数ICxFilter。但注意滤波值太大会降低最高计数频率。接地与屏蔽确保编码器电缆是屏蔽双绞线屏蔽层在PLC端单点接地。编码器电源和PLC电源最好共地且地线足够粗。软件去抖在硬件滤波基础上可以在读取计数值后进行软件上的“去抖”处理比如连续多次采样判断一致后才更新。问题三Modbus通讯偶尔出现超时或错误帧。排查思路波特率与格式确认主站和从站PLC的波特率、数据位、停止位、校验位完全一致。线路与终端电阻RS485是差分总线必须使用双绞线。长距离超过100米或高速率超过115200时必须在总线首尾两端各接一个120欧姆的终端电阻消除信号反射。收发器控制检查RS485收发器的方向控制引脚DE/RE的时序。必须在发送数据前拉高发送完成后延迟一段时间再拉低切换太快或太慢都会导致帧不完整。这个延迟时间需要根据波特率精确计算。协议栈配置检查FreeMODBUS的从站地址、超时时间等配置是否正确。下表总结了一些常见问题的快速排查指南现象可能原因排查步骤与解决方法上电不启动1. 电源异常2. 复位电路问题3. 晶振不起振4. 启动模式错误1. 测量各点电压3.3V, 1.2V内核电压2. 检查复位引脚电平手动复位试试3. 用示波器测晶振引脚波形注意探头电容影响4. 检查BOOT0/BOOT1引脚电平设为从主Flash启动通常都拉低程序下载失败1. 调试器连接问题2. 芯片被写保护3. 电源不稳定1. 检查SWD连线SWDIO, SWCLK, GND尝试降低下载速度2. 使用STM32CubeProgrammer连接尝试解除读保护RDP3. 确保调试时系统供电充足数字输入无反应1. 光耦损坏或接反2. 限流电阻过大3. 软件GPIO配置错误应为浮空输入或上拉1. 测量光耦输入侧电压和输出侧电压变化2. 计算输入电流是否在光耦LED工作范围内通常5-20mA3. 用调试器直接读取GPIO输入数据寄存器的值输出点带载能力弱1. 输出MOSFET选型不当导通电阻Rds_on太大2. 散热不足导致热保护3. 续流二极管未接或损坏1. 根据负载电流如0.5A选择足够低Rds_on的MOSFET2. 触摸MOSFET温度必要时加散热片3. 检查感性负载两端是否并联了快恢复二极管5. 从项目到产品的思考与建议这个基于STM32的PLC项目从最初的计划表到最终成型的产品花了我们团队近两年的时间。回过头看它不仅仅是一个技术项目更是一次从技术研发到产品化、市场化的完整历练。首先关于技术选型STM32的选择被证明是极其正确的。其强大的生态让我们在开发工具、参考代码、问题解答上节省了大量时间。FreeRTOS和LWIP这类成熟的开源组件极大地加速了开发进程。但切记“拿来主义”要有度。对于核心的PLC运行时和梯形图编译器我们坚持自己开发虽然难度大但形成了最关键的技术壁垒和差异化优势。其次工业产品的可靠性是设计出来的不是测出来的。除了之前提到的电源、信号隔离、PCB布局等硬件设计准则在软件上我们加入了多重保护两级看门狗独立窗口、关键数据在Flash中的备份与校验、上电自检RAM、Flash、外设、运行期异常日志记录。这些机制让产品在恶劣的工业现场也能稳定运行。再者关于梯形图编程软件的开发这是一个容易被低估的难点。它涉及到图形化编辑、编译原理、用户交互、工程管理等多个方面。如果团队资源有限一个务实的建议是前期可以专注于Runtime引擎的稳定和高效上位机软件可以先做一个简单的指令表编辑器或者尝试与第三方开源PLC编程软件如OpenPLC Editor进行适配快速推出原型验证市场待产品方向明确后再投入重金开发完善的IDE。最后我想对也想尝试类似项目的朋友说PLC是一个系统工程涉及硬件、固件、上位机软件、甚至后续的编程语言标准。不要指望一蹴而就。可以从一个超小型的、只有基本逻辑控制功能的“软PLC”开始比如先用STM32实现一个支持20点IO、能用串口下载指令表程序的小盒子。把这个最小可行产品MVP做稳定摸清从设计、生产到测试的全流程。然后再逐步添加高速计数、脉冲输出、模拟量、通讯等功能。每一步都扎扎实实地做好测试和可靠性验证。这条路走下来很辛苦但当看到自己设计的PLC在设备上稳定运行替代了那些昂贵的进口品牌时那种成就感是无与伦比的。它不仅是一个产品更是我们团队能力的一次淬炼。希望我的这些经验能为你点亮前行路上的一盏小灯。