从 MCU + SOEM 到 Linux + IgH,一块32轴运动控制卡的选型思考

最近一直在看 EtherCAT 主站方案。

最开始我的想法比较简单：找一颗性能足够的 MCU，把 SOEM 移植进去，再把运动控制算法跑起来，应该就能做出一块成本不高的 EtherCAT 运动控制卡。

毕竟从表面上看，EtherCAT 主站无非就是扫描从站、配置 PDO、进入 OP，然后每隔一段固定时间收发一次过程数据。现在不少高性能 MCU 主频已经达到几百兆赫兹，甚至接近 1GHz，带两个以太网口，片上 SRAM 也不算小，似乎没有必要为了一个 EtherCAT 主站专门上一颗 Linux 处理器。

但随着方案逐渐往下细化，我发现这个问题并没有想象中那么简单。

真正难的并不是让 EtherCAT 从站进入 OP，也不是把伺服驱动器转起来，而是如何把它做成一块能够长期运行、可以扩展、能够处理异常的运动控制卡。

我的目标不是做一个简单的 EtherCAT 测试工具，而是希望它最终能够支持大约32轴点位控制、16轴联动插补，并且后续还能增加上位机、参数配置、日志记录和远程升级等功能。

在这个目标下，HPM6750、STM32MP257、RK3506、x86和专用 EtherCAT 主站芯片几条路线，实际对应的是几种完全不同的产品思路。

一开始最吸引我的是 MCU 加 SOEM

如果单纯从硬件成本和系统结构来看，HPM6750这一类高性能 MCU 确实很有吸引力。

它不需要 DDR，也不需要复杂的 Linux 启动环境。系统上电以后，可以很快进入控制程序。EtherCAT 周期任务可以直接运行在 RTOS 高优先级线程中，甚至可以裸机运行。

没有 Linux 调度器，没有文件系统后台任务，也没有各种不受控制的系统服务。从实时控制的角度来看，这种结构非常直接。

SOEM 本身也很轻量。它不像一些商业 EtherCAT 主站协议栈那样依赖复杂的操作系统环境，只要能够提供底层以太网数据收发、定时器和基本线程机制，就可以逐步移植。

如果只是固定连接几个 EtherCAT 从站，例如一台六轴机器人，驱动器型号固定，PDO 映射固定，系统出厂以后也不会更换从站，那么这种方案其实很合适。

所有从站参数都可以直接写在固件里，不需要做通用 ESI 配置器，也不需要动态识别几十种设备。上电后按照固定顺序配置，进入 OP，然后开始循环收发。

系统简单、启动快，硬件成本也低。

但问题是，我想做的不是这样一台固定设备。

如果要支持不同厂家的 EtherCAT 伺服，轴数可能从4轴增加到16轴甚至32轴，用户还可能修改 PDO、控制模式和同步周期，那么很多原来可以写死的东西都必须变成可配置功能。

这时 SOEM 只能解决 EtherCAT 通信的基础问题。剩下的大量工作仍然需要自己完成。

比如分布式时钟同步如何处理，DC 偏差过大时怎么补偿，Working Counter 异常时怎么判断是哪一个从站出了问题，某个从站掉线以后总线是否继续运行，重新接入后如何恢复。

再往上，还有 CiA402 状态机、控制字切换、故障复位、CSP、CSV和CST模式管理。

如果要做运动控制，还需要梯形速度规划、S曲线、多轴同步、直线插补、圆弧插补、电子齿轮和龙门同步。

这些功能本身并不一定需要 Linux，但全部放在 MCU 上以后，调试、配置和维护的压力会越来越大。

尤其是后面还要增加日志、参数文件、远程升级、Web配置页面和上位机通信时，系统会开始不断叠加各种自定义模块。

这也是我后来对 MCU 加 SOEM 方案比较谨慎的原因。

它不是性能不够，而是太多基础设施都要自己建设。

专用 EtherCAT 主站芯片也没有想象中省事

后来我又看了 ECM-XF 这一类专用 EtherCAT 主站芯片。

这类芯片最大的吸引力，就是它可以把 EtherCAT 通信部分从主控中独立出来。

主控不再直接操作 EtherCAT 网口，而是通过 SPI 等接口与主站芯片通信。从站扫描、PDO 收发和部分同步功能由专用芯片完成。

对于不熟悉 EtherCAT 底层协议的人来说，这种方式确实能够降低开发难度。

尤其是在项目时间比较紧、轴数不多、单台产品售价较高的情况下，多花几百元购买一颗专用主站芯片，可能比投入几个月时间自己调协议栈更划算。

但继续分析以后会发现，专用主站芯片只能替主控完成 EtherCAT 通信，不能替主控完成运动控制。

CiA402、轨迹规划、插补计算、限位处理、坐标变换和安全逻辑，依然需要主控自己实现。

而且这种架构在主控和 EtherCAT 网络之间增加了一层 SPI 通道。

少量轴时问题不大，但随着轴数和 PDO 数据量增加，每一个周期都要通过 SPI 读取输入数据，再写回输出数据。

例如32个轴，每个轴输入输出合计32字节，一个周期就是大约1KB数据。

如果周期是1ms，SPI压力并不算大。

但周期缩短到125μs以后，每秒需要传输的数据量就会达到8MB左右，这还没有计算命令、地址、状态和其他协议开销。

如果后面增加实际位置、实际速度、实际转矩、状态字、数字输入、探针位置和诊断信息，单轴 PDO 可能远不止32字节。

这时 SPI 本身就可能变成瓶颈。

所以专用 EtherCAT 主站芯片更适合“快速完成一个确定功能的产品”，而不一定适合做一块长期扩展的通用运动控制平台。

它能够降低 EtherCAT 入门难度，但无法降低整个运动控制系统的复杂度。

STM32MP257的架构很好，但对基础款来说有点重

STM32MP257是我比较认真考虑过的一颗处理器。

它有 Cortex-A35，可以运行 Linux，同时还有 Cortex-M33，可以处理实时任务。网口数量和工业接口也比较丰富。

从架构上看，它很适合工业控制器。

Linux 可以负责 IgH EtherCAT 主站、Web服务、OPC UA、数据库、远程升级和图形界面。M33可以负责急停、抱闸、看门狗、本地IO和电源时序。

如果产品带显示屏，还需要运行 Qt 或其他图形界面，STM32MP257的优势会很明显。

如果后面还要接入 ROS 2、视觉系统或者复杂的网络服务，它也能提供比较大的性能余量。

但它的问题同样明显，就是整体成本和硬件复杂度比较高。

除了处理器本身，还需要 DDR、eMMC、PMIC和多路电源。PCB层数、布线要求和调试难度都会上升。

如果只是做一块没有显示屏的 EtherCAT 运动控制卡，主要任务是32轴点位和16轴插补，那么STM32MP257有些性能过剩。

另一个需要注意的问题，是A35和M33之间如何分工。

很多人看到一个Linux核心加一个实时核心，会自然地想把EtherCAT通信放在Linux，把运动插补放在M33。

这样看起来分工很明确，但每一个控制周期都需要在两个系统之间传递PDO数据和运动指令。

如果控制周期是1ms，可能还能接受。到了500μs甚至250μs以后，跨核通信、共享内存、缓存一致性和同步机制都会成为新的问题。

我更倾向于把EtherCAT收发、CiA402和轨迹插补放在同一个Linux实时线程中。

M33只负责急停、抱闸、本地IO、看门狗和独立安全状态机。

这样实时数据从EtherCAT输入到运动算法，再到EtherCAT输出，全程不需要跨系统传递。

从技术上看，STM32MP257是一个很完整的方案，但更适合做高端型号，而不是用来做第一款追求成本和通用性的运动控制卡。

为什么最后更倾向于RK3506

相比之下，RK3506给我的感觉是一个比较折中的方案。

它不是性能最强的，也不是生态最完整的，但它的功能配置与一块嵌入式运动控制卡比较匹配。

它有多个Cortex-A7核心，可以运行Linux，也有两个以太网接口。

一个网口可以完全交给EtherCAT，另一个网口用于上位机、Web配置、调试或者Modbus TCP。

这点非常重要。

EtherCAT主站网口最好独占，不要同时承担普通TCP/IP通信。否则普通网络流量、驱动中断和系统网络栈都可能对实时周期产生影响。

在RK3506上，可以让一个A7核心专门运行IgH EtherCAT实时线程，其他核心运行日志、配置、升级和普通网络服务。

如果使用AMP架构，还可以让另一个核心运行RT-Thread或者裸机程序，处理急停、抱闸、本地IO和硬件看门狗。

但我不会让这个RTOS核心参与每一个EtherCAT周期的插补计算。

EtherCAT数据接收、PDO解析、CiA402处理、轨迹规划、插补运算和目标位置写入，应该尽量放在同一个Linux实时线程中完成。

这样可以减少线程切换，也可以避免大量锁、消息队列和跨核同步。

一个典型的周期线程大概会按照下面的顺序运行：

首先接收上一周期的EtherCAT帧，然后更新输入PDO。

接着读取各轴状态字、实际位置、实际速度和故障信息。

随后执行CiA402状态机，判断驱动器是否处于Operation Enabled，是否需要复位故障或者切换模式。

状态正常以后，执行轨迹规划和多轴插补，计算下一周期的目标位置、目标速度或者目标转矩。

最后把结果写入输出PDO，排队并发送下一周期的数据帧。

整个过程尽量在一个固定优先级的实时线程中完成。

这样做并不是为了让代码看起来简单，而是为了让控制周期更容易分析。

出现抖动时，可以清楚地知道每一个阶段消耗了多少时间，而不是在多个线程和多个操作系统之间寻找问题。

1ms并不丢人，稳定比极限周期更重要

在讨论EtherCAT主站时，很多人都会关注125μs或者250μs周期。

周期越短当然越好，但在实际产品中，更重要的是最坏情况下的抖动。

一套系统平均周期是250μs，但偶尔会跳到800μs，未必比稳定运行在1ms更好。

对于32轴点位控制和16轴插补，1ms已经可以满足大量工业自动化设备、机器人和多轴平台的需求。

第一版产品可以先把目标定在1ms。

在系统空闲时运行1ms并不难，真正需要验证的是，在CPU高负载、上位机持续通信、eMMC写日志、Web页面访问和普通网口大量传输时，EtherCAT周期是否仍然稳定。

如果系统在这些压力条件下仍然没有明显超时，才说明这套架构具备产品化基础。

等1ms稳定以后，再逐步进行优化。

例如隔离实时CPU核心，把EtherCAT网卡中断绑定到指定核心，关闭动态调频，锁定内存，避免实时线程发生缺页，减少日志输出，并调整PREEMPT_RT优先级。

完成这些工作以后，再尝试500μs。

至于250μs，可以作为后续高性能版本的目标，但没有必要在第一块板子上就追求极限。

运动控制器最终是要运行在设备里的，不是只在实验室里测一个漂亮的平均周期。

为什么我还会保留一套x86平台

虽然量产方向更倾向于RK3506，但在开发初期，我仍然会保留一套x86加Intel I210网卡的平台。

原因很简单：先把运动控制软件与ARM平台问题分开。

如果一开始就在RK3506上同时调试Linux实时性、网卡驱动、IgH、CiA402、轨迹规划和多轴插补，任何一个环节出现问题，都可能让整个系统表现为周期不稳定或者电机运动异常。

这时很难快速判断究竟是运动算法问题、EtherCAT配置问题，还是底层驱动问题。

x86平台性能充足，驱动和调试环境更加成熟，可以先用它完成CiA402、S曲线、直线插补、圆弧插补、电子齿轮和异常恢复。

当这些用户层软件已经稳定以后，再迁移到RK3506。

这样到了ARM阶段，需要解决的主要就是实时调度、网卡驱动和性能优化，不必同时怀疑运动算法是否正确。

这个过程看起来多了一套硬件，实际上能够明显缩短整体开发时间。

我准备采用的系统分层

目前比较倾向的架构，是把系统分成三个部分。

第一部分是Linux实时控制层。

这一层负责IgH EtherCAT Master、PDO数据处理、CiA402状态机、S曲线规划、多轴插补和控制周期管理。

所有与每个EtherCAT周期直接相关的运算，都尽量集中在这里。

第二部分是Linux普通业务层。

这一层负责参数配置、日志记录、文件系统、远程升级、Web页面、上位机通信和普通以太网协议。

这些任务可以很复杂，但不能干扰实时核心。

第三部分是独立安全控制层。

它可以运行在另一个RTOS核心，也可以使用一个独立的小型MCU。

它负责急停输入、抱闸控制、驱动器使能、电源时序、硬件看门狗和关键故障输出。

即使Linux完全死机，安全控制层也应该能够关闭驱动器使能，并根据设备状态控制抱闸。

对于运动控制器来说，实时性不仅是按时发送PDO，还包括发生故障以后，系统能够在确定时间内进入安全状态。

如果急停、抱闸和使能全部依赖Linux用户程序，那么无论正常运行时周期多漂亮，系统安全性都不够完整。

这几种方案最终分别适合什么产品

经过这段时间的比较，我对几种方案的定位也逐渐清晰。

HPM6750加SOEM适合轴数较少、拓扑固定、产品功能明确的专用设备。

它的硬件成本低、启动快、结构简单，但前提是团队有能力长期维护EtherCAT和运动控制底层软件。

专用EtherCAT主站芯片适合研发时间紧、轴数不多、单台设备价值较高的产品。

它能够快速解决EtherCAT通信问题，但不能替代运动控制软件，而且主控与主站芯片之间的接口会限制后续扩展。

STM32MP257适合带屏幕、多网口、复杂Linux应用和高端功能的控制器。

它的整体架构比较完整，但成本和硬件复杂度也明显更高。

x86加I210最适合做前期开发和高性能控制器。

开发效率高、实时性容易优化，但体积、功耗和硬件成本不一定适合所有量产产品。

RK3506加IgH则处在几个方案之间。

它的成本低于STM32MP257，软件生态和扩展能力又明显强于纯MCU方案，比较适合做一款通用的嵌入式EtherCAT运动控制卡。

最后的选择

如果让我现在确定第一版方案，我会选择：

量产硬件使用RK3506，配置512MB DDR3L和8GB eMMC，再增加一颗小容量QSPI NOR用于启动恢复和关键配置。

系统运行Linux PREEMPT_RT和IgH EtherCAT Master。

一个网口独占EtherCAT，另一个网口用于上位机和管理网络。

一个A7核心隔离出来运行EtherCAT、CiA402和运动插补，其他核心运行普通业务。

急停、抱闸、使能和看门狗交给独立RTOS核心或者外部MCU处理。

第一版先按照1ms周期设计，目标是稳定支持32轴点位和16轴插补。

等软件和硬件架构稳定以后，再优化到500μs。

前期算法和协议验证，则使用x86加Intel I210和IgH完成。

这并不是理论性能最高的方案，但从成本、开发难度、扩展能力和量产风险几个方面来看，它是目前比较均衡的选择。

写在最后

做EtherCAT主站很容易陷入一个误区，就是过度关注芯片性能和最短通信周期。

但真正做成产品以后会发现，决定控制器水平的不是它能不能在实验室跑到125μs，而是它能不能在复杂负载下保持稳定，能不能正确处理伺服报警和从站掉线，能不能在急停后进入安全状态，能不能方便地配置和维护。

从站能够进入OP，只能说明EtherCAT通信已经建立。

几个轴能够转起来，也只能说明基本控制链路已经打通。

真正能够让十几个轴长时间同步运行，并且在各种异常情况下保持可控，才是一块运动控制卡最难的部分。

所以相比于追求一颗看起来更强的芯片，我现在更看重的是整个系统架构是否清晰。

EtherCAT通信、运动控制、Linux业务和安全控制应该各自承担明确的任务，实时数据链路尽量短，非实时功能不能影响控制周期，故障处理也不能完全依赖单一操作系统。

从这个角度看，RK3506加IgH不一定是最强的方案，但它给后续的软件开发和产品扩展留下了足够的空间。

对第一版产品来说，先把1ms做好，把CiA402、插补、异常恢复和安全链路做完整，可能比一开始追求125μs更有价值。