3. 工业通信协议栈全景
STM32MP1 系列（如 STM32MP157）与 STM32MP2 系列（如 STM32MP257）在工业网关、边缘控制器和远程 IO 场景中经常需要同时面对多种工业协议。它们的共同点是：芯片本身只提供以太网 MAC、CAN-FD 控制器、UART、SPI 等物理与链路层外设，而 Modbus、CANopen、EtherCAT、PROFINET、OPC UA 这些协议栈，要么运行在 Cortex-A 侧的 Linux 用户态/内核态，要么运行在 Cortex-M 侧的裸机或 RTOS 上，要么由专用硬件加速单元承担。选型的第一步不是比较协议“谁更先进”，而是先判断协议栈落在哪一侧、需要什么实时性、需要什么硬件配合。
协议栈在 STM32MP 上的分层落点
把五类协议放到同一张分层图上，可以看清它们的本质差异。Modbus RTU/TCP 与 CANopen 属于“轻量级、可软件实现”的协议：Modbus RTU 走 UART 或 RS-485 收发器，Modbus TCP 走 Linux 的 socket；CANopen 走 CAN-FD 控制器，协议栈（如 CANopenNode）可跑在 Cortex-M 裸机或 Linux 的 SocketCAN 之上。EtherCAT 与 PROFINET 属于“硬实时工业以太网”：EtherCAT 从站通常需要 ESC（EtherCAT Slave Controller）专用芯片或支持 EtherCAT 的 MAC，主站则依赖 Linux 的 IgH EtherCAT Master 或 Xenomai/RT-Preempt 内核；PROFINET 的 RT/IRT 对周期抖动要求更严，STM32MP 上一般以 PROFINET RT 从站为主，IRT 需要专用 ASIC。OPC UA 则是“信息层协议”，它不关心底层是 Modbus 还是 PROFINET，运行在 Linux 用户态，用 open62541 或 UA-.NET 等栈实现，负责把现场数据统一成地址空间模型。
五类协议的适用性对比
从工程落地角度看，五类协议在 STM32MP 上的适用性可以按“实时性—实现成本—生态成熟度”三个维度判断。Modbus 的实时性最弱，但实现最简单：Linux 侧用 libmodbus 打开 /dev/ttySTM0 或 TCP 端口即可，Cortex-M 侧用 UART 中断收发也能实现从站。CANopen 的实时性中等，CAN-FD 在 1Mbps 仲裁段下典型周期 1~10ms，CANopenNode 在 Cortex-M 上占用约 20~40KB Flash，适合分布式 IO 和伺服驱动。EtherCAT 的实时性最强，从站周期可到 250μs，但必须依赖 ESC 芯片（如 LAN9252、ET1100），STM32MP 通常作为主站或通过 SPI/并口连接 ESC 做从站。PROFINET RT 从站可用 p-net 协议栈在 Linux 上实现，周期 1~4ms，适合工厂自动化；IRT 则必须专用 ASIC。OPC UA 不参与实时控制，它负责把上述协议的数据统一建模，典型周期 100ms~1s，适合边缘网关与 MES/SCADA 对接。
| 协议 | 典型周期 | STM32MP 落点 | 硬件依赖 | 典型场景 |
|---|---|---|---|---|
| Modbus RTU/TCP | 10~100ms | A 侧 Linux / M 侧裸机 | UART+RS485 / 以太网 | 仪表采集、老旧设备接入 |
| CANopen | 1~10ms | M 侧裸机 / A 侧 SocketCAN | FDCAN 控制器 | 分布式 IO、伺服、工程机械 |
| EtherCAT | 250μs~1ms | A 侧主站 / ESC 从站 | ESC 芯片、RT 内核 | 运动控制、高速 IO |
| PROFINET RT | 1~4ms | A 侧 Linux（p-net） | 以太网 MAC、RT 内核 | 工厂自动化、过程控制 |
| OPC UA | 100ms~1s | A 侧 Linux 用户态 | 无特殊硬件 | 边缘网关、SCADA/MES 集成 |
选型依据与决策路径
实际选型时，建议按以下顺序判断。第一，先问“控制周期是多少”：若周期小于 1ms 且要求抖动小于 10μs，直接排除 Modbus 和 OPC UA，优先 EtherCAT 或 PROFINET IRT，并确认是否需要 ESC/ASIC。第二，问“现场已有哪种总线”：若现场已有 CAN 线束，选 CANopen 成本最低；若已有 RS-485 仪表，Modbus RTU 最直接；若已有 PROFINET 网络，则用 p-net 做从站。第三，问“是否需要向上层系统暴露语义化数据”：若需要，则在实时协议之上叠加 OPC UA 信息模型，而不是用 OPC UA 替代实时协议。第四，评估 Cortex-M 侧资源：CANopenNode 约 30KB Flash、8KB RAM；Modbus 从站约 10KB Flash；若 M 侧还要跑电机控制，需预留算力。第五，确认 Linux 内核实时性：EtherCAT 主站和 PROFINET RT 从站建议使用 RT-Preempt 或 Xenomai，普通内核下周期抖动可能达到数百微秒，无法满足 1ms 周期要求。
一个典型的混合协议网关示例
假设一台 STM32MP157 网关需要同时接入 4 路 RS-485 Modbus RTU 仪表、1 路 CANopen 伺服，并把数据上传到 OPC UA 服务器。合理的分工是：Cortex-M4 侧用 UART 中断实现 4 路 Modbus RTU 从站轮询，周期 50ms，把寄存器值写入共享内存；Cortex-A7 侧用 SocketCAN 读取 CANopen 的 PDO 数据，周期 5ms；Linux 用户态运行 open62541，把 Modbus 寄存器和 CANopen 对象字典映射为 OPC UA 变量节点，发布周期 200ms。这样既保证了 CANopen 的实时性，又用 OPC UA 完成了语义化集成。若把 Modbus 轮询也放到 A 侧用户态，50ms 周期下 CPU 占用约 3%~5%，可接受；但若周期压到 5ms，则建议下移到 M 侧，避免 Linux 调度抖动导致轮询超时。
总结来看，STM32MP 的异构架构（Cortex-A + Cortex-M）恰好为“实时控制 + 信息集成”提供了天然分工：M 侧承担 CANopen、Modbus RTU 等轻量实时任务，A 侧承担 EtherCAT 主站、PROFINET RT、OPC UA 等需要 Linux 生态的任务。选型的核心不是比较协议优劣，而是把协议放到正确的核、正确的内核实时性配置和正确的硬件加速路径上。