STM32F4上跑EtherCAT主站这事我琢磨了很久。之前项目里需要带十几个伺服轴PLC加专用主站板卡的价格实在让人肉痛工控机加软主站的方案又太大塞不进设备里。后来看到SOEM这个开源主站库再配上STM32F407自带的MAC外设和一颗LAN8720 PHY芯片基本就是一套成本极低、体积很小的EtherCAT主站方案。我把SOEM 1.4.0完整移植到STM32F4上跑通了带过伺服、接过IO从站也踩了一堆文档里根本不会写的坑。这篇文章就把整个移植过程、关键原理和排查思路完整记录下来给有同样需求的朋友做个参考。1. 项目从哪来为什么要在STM32F4上跑EtherCAT主站先交代背景。我做的是一台小型自动化设备需要控制6个伺服轴加若干IO模块原来用的是某大厂PLC配专用EtherCAT主站模块整套下来成本一直压不下去。后来算了一笔账STM32F407芯片几十块LAN8720模组十几块加上电源、晶振、PCB整个主站硬件的物料成本不到PLC方案的十分之一。而且设备对体积有要求PLC那一大坨实在塞不进去自研主站板卡的尺寸可以做到很小。有人会问直接用STM32的普通以太网加TCP/IP不行吗不行。EtherCAT的实时性和同步机制是普通以太网协议完全不具备的。EtherCAT采用集总帧机制主站发送一帧数据所有从站在帧经过时同步处理并插入数据一帧走完整个网络多个轴的数据就全部更新完了。这种运行机制决定了它必须有专门的主站协议栈不能拿LwIP那套东西硬套。再回答另一个常见问题为什么选SOEM而不是IGHIgH EtherCAT MasterIGH功能确实更全但它主要面向Linux平台要在STM32F4这种裸机或RTOS环境下跑起来改动量非常大。SOEM的设计更轻量核心代码不依赖操作系统移植到裸机环境相对容易。SOEM 1.4.0版本在稳定性上也有明显改善这也是我选用它的原因。做嵌入式主站SOEM是最务实的选择。1.1 方案选型对比我把几个可选方案简单列一下方便大家对照自己的情况判断方案硬件成本估算开发难度体积适用场景PLC 厂商主站模块高低大传统设备改造、批量产线工控机 软主站中高中大需要视觉、上位机复杂逻辑ARM Cortex-A系列 网卡 IGH中高中Linux平台、功能复杂的控制系统STM32F4 LAN8720 SOEM低中高小轴数不多、嵌入式设备内置专用EtherCAT主站ASIC中中小高性能、高同步精度场景STM32F4方案最大的优势是把成本和体积压到了极致劣势是单核主频168MHz带轴数量有限。以我实测的经验F407带6个伺服轴加几个IO从站周期1msCPU占用率在50%到60%之间还算从容。如果你要带16个轴以上我建议直接上A系列处理器或者专用ASIC别在F4上硬撑。1.2 SOEM 1.4.0版本带来的变化SOEM的历史版本里有个比较烦人的问题就是对裸机环境的支持不够统一早期版本里很多代码路径预设了Linux的线程和信号量机制。1.4.0版本里RT-Labs对代码结构做了整理osal层操作系统抽象层的职责更清晰这给跨平台移植省了不少事。我在移植过程中重点确认了osal、nicdrv网卡驱动和ethercat主协议栈的接口边界这三层的关系在后面章节会详细拆解。2. 开搞之前需要搞懂的三个核心概念在动手移植之前我建议先把三个基础概念弄清楚EtherCAT协议的运行机制、SOEM代码的模块划分、LAN8720在数据链路里的角色。这三个东西一旦理解透了移植过程中遇到问题才能快速定位否则就是在瞎猜。2.1 EtherCAT协议到底在干什么EtherCAT本质上是把以太网帧复用成工业实时总线。主站发送一个标准以太网帧EtherType为0x88A4帧里面包含多个数据报Datagram每个数据报对应一组从站设备里面携带这些设备的输出数据和命令。帧经过每一个从站时从站硬件ESC芯片在几十纳秒内把数据读取或插入到帧的指定位置同时把帧转发给下一个从站。所有从站处理完成后帧从最后一个从站返回主站主站解析帧里带回的输入数据。这个机制有几个关键点主站和所有从站的通信在一帧内完成所以网络负载低、同步性好。从站的处理延迟不受CPU性能影响由ESC硬件决定。帧是经过每个从站再从末端返回的所以从站物理上必须串联成线型或环型拓扑。SOEM在发送数据时会先根据PDO配置构建以太网帧然后通过网卡硬件发送。STM32F4的以太网MAC支持硬件CRC校验这点很重要——SOEM构造的帧是不带FCS的FCS需要由MAC硬件自动添加。2.2 SOEM的代码模块划分SOEM的源码结构大致可以分三层协议栈核心层ethercatbase、ethercatcoe、ethercatconfig、ethercatmain等这些文件实现了EtherCAT状态机管理、CoECANopen over EtherCAT协议、SII从站信息接口读取、FMMU配置等所有主站逻辑。这一层基本不需要动。OSAL层操作系统抽象层跨平台的关键。裸机环境下需要自己实现定时器、微秒延时、互斥锁如果没有多线程可以做成空函数、毫秒/微秒计时接口。SOEM 1.4.0里这层的接口集中在timer和osal相关文件中。NIC驱动层nicdrv.c负责最底层的以太网帧收发。SOEM默认提供Linux socket版本和WinPcap版本MCU环境下需要重写里面的收发函数对接STM32的HAL以太网驱动。简单说移植SOEM 实现OSAL层接口 把nicdrv的底层收发替换成STM32的ETH驱动核心协议栈代码原封不动。2.3 LAN8720在数据链路里的角色LAN8720是10/100M以太网PHY芯片负责把STM32 MAC输出的数字信号转换成网线上的模拟差分信号。在EtherCAT应用中PHY就是个物理层收发器不参与协议处理——协议处理完全在STM32的MAC里。LAN8720支持RMII接口接口信号线少TXD0/1、TX_EN、RXD0/1、CRS_DV、REF_CLK加MDIO/MDC管理接口很适合STM32F4。另一个要搞清楚的是时钟方案。RMII模式下PHY和MAC必须共用同一个50MHz参考时钟这个时钟可以由外部50MHz有源晶振提供也可以由STM32的MCO引脚输出还可以让LAN8720自己从25MHz晶振倍频到50MHz后输出给STM32。三种方案各有坑后面详细说。3. 半物连接与STM32以太网外设的初始化硬件是移植的基础。先把STM32F407和LAN8720之间的引脚关系理清楚再谈软件。引脚接错或者时钟方案不对后面跑协议栈的时候会出现各种莫名其妙的问题。3.1 RMII接线与原理图要点STM32F407的以太网MAC在RMII模式下使用9根信号线加两根管理线。我使用的引脚分配如下信号STM32引脚说明ETH_RMII_REF_CLKPA150MHz参考时钟输入ETH_RMII_MDIOPA2管理数据输入输出ETH_RMII_MDCPC1管理时钟输出ETH_RMII_CRS_DVPA7载波检测与数据有效ETH_RMII_RXD0PC4接收数据位0ETH_RMII_RXD1PC5接收数据位1ETH_RMII_TX_ENPB11发送使能ETH_RMII_TXD0PB12发送数据位0ETH_RMII_TXD1PB13发送数据位1注意RMII模式下RXD1/RXD0只有两位TXD1/TXD0也只有两位数据在50MHz时钟下每个时钟周期传4位即100Mbps这是RMII和MII最大的区别。很多新手拿到MII的图纸抄过来引脚对不上就卡住了。原理图上还有几个容易被忽略的点LAN8720的nRST引脚要接RC复位电路R取10k左右C取100nF上电时给一个足够宽的低电平复位脉冲。这个复位时序极其重要后面踩坑部分会说。PHYAD0引脚决定PHY地址悬空或下拉后默认地址是0x00。注意PHY地址是芯片复位时锁存的运行中改不了。REF_CLK引脚LAN8720的第2脚在RMII从钟模式下接收STM32或外部晶振送来的50MHz数据采集在REF_CLK的上升沿。LAN8720的nINT引脚也连出来比较方便它可以作为Link状态变化中断调试时很有用。3.2 STM32以太网DMA的描述符配置STM32F4的以太网外设使用DMA来搬运数据帧DMA描述符Descriptor是一块内存区域中的数据结构每个描述符对应一帧缓冲区。初始化时要把TX和RX描述符链表建好再通过HAL库的HAL_ETH_Init和HAL_ETH_Start_DMA把外设跑起来。描述符数量上我建议RX至少分配8个TX分配4个。太少了在EtherCAT高速收发时很容易丢帧多了浪费内存每个缓冲区默认1524字节。用HAL库默认的ETH_DMADescTypeDef数组即可注意这些数组要按4字节对齐在裸机环境下可以用attribute((aligned(4)))强制对齐。HAL库初始化以太网时的参数项里有个要留意的点DMA描述符的环回模式LoopbackMode。以太网初始化时如果设置成了MAC和PHY的环回EtherCAT协议栈能正常初始化并读取PHY寄存器但帧发不出去数据永远到不了从站。我调试时踩过一次现象是从站扫描偶尔成功偶尔失败最后发现是某个初始化配置里把环回打开了关掉后一切正常。3.3 LAN8720 PHY芯片的寄存器配置PHY芯片初始化时主站需要通过MDIO总线读写PHY的寄存器。LAN8720有几个关键的寄存器寄存器0BCR基本控制寄存器用于复位、速率配置、自协商配置。寄存器1BSR基本状态寄存器可以读取链路状态、自协商完成标志。寄存器31PHY Special Control/StatusLAN8720特有的寄存器用于配置RMII模式其中bit15是RMII模式使能位必须置1才能工作在RMII模式。在SOEM移植过程中每次上电先通过MDIO读PHY ID寄存器2和3LAN8720的ID是0x0007C0F1。如果读出来不对多半是MDIO时序或者PHY复位出了问题。SOEM的nicdrv.c里有ecx_init函数会调用ccx_setup里面会重置PHY并等待自协商这部分逻辑在移植时也能利用起来但要在ccx_setup里调用我们自己实现的MDIO读写接口。4. SOEM 1.4.0在STM32F4上的移植全流程现在进入核心部分。我按实际移植的顺序来写从拿到源码到跑通第一个周期每一步都给出具体做法和需要注意的细节。4.1 源码准备与文件裁剪SOEM 1.4.0从官方仓库下载后源码在soem/soem目录下。移植时不需要把所有文件都加进工程只需要复制以下内容soem/soem/ethercat*.cethercatbase、ethercatcoe、ethercatconfig、ethercatdc、ethercatfoe、ethercatmain、ethercatprint、ethercatsoe这些文件soem/soem/nicdrv.csoem/soem/osal/下的timer.c和osal.c这两个文件提供接口里面平台相关的部分需要重写所有对应的头文件目录包括soem/soem/soem_km、soem/soem/osal等在裸机工程里我知道很多人喜欢把所有源文件一股脑放进Keil或IAR工程然后挨个编译报错再挨个改。这样效率太低。建议先把协议栈核心文件加进来OSAL层先用自己的实现替代NIC层先写好空壳然后逐步填充底层函数这样每一步都容易定位问题。4.2 OSAL层的裸机实现OSAL层主要提供以下接口timer_start和timer_timeout毫秒级定时器用于协议栈的超时判断。裸机环境直接用SysTick产生1ms时基维护一个全局毫秒计数器timer_start记录当前值timer_timeout比较差值。osal_usleep微秒延时在SOEM里很多地方用于短等待比如PHY复位后等待、周期任务调度。STM32F4可以通过DWTData Watchpoint and Trace的CYCCNT寄存器做精确微秒延时代码量很小且精度高。osal_mutex相关如果裸机单线程跑主站锁可以直接留空实现。如果跑RTOS就要把信号量接口和RTOS的互斥锁对应上。Timer接口有个容易出错的细节SOEM内部很多地方使用的超时值是毫秒而有些底层驱动用的是系统节拍计数。如果SysTick配置的是1ms中断一次那timer_start后第200个节拍就是200ms。但要注意如果中断里又调用了printf或者做了太多事情就会影响定时精度甚至造成EtherCAT丢包所以定时器中断函数要保持极简。这里是我的darwin实现片段SysTick中断里只做两件事毫秒计数器加一调度标志位置位供主循环周期任务使用。volatile uint32_t g_tick_ms 0; volatile uint8_t g_dc_trigger 0; void SysTick_Handler(void) { g_tick_ms; g_dc_trigger 1; } uint32_t timer_start(void) { return g_tick_ms; } uint32_t timer_timeout(uint32_t start, uint32_t timeout_ms) { if ((uint32_t)(g_tick_ms - start) timeout_ms) { return 1; } return 0; } void osal_usleep(uint32_t usec) { DWT-CYCCNT 0; while (DWT-CYCCNT (SystemCoreClock / 1000000) * usec) { } }4.3 nicdrv网卡驱动的完整对接这是整个移植过程中最关键的部分。SOEM的nicdrv.c里定义了底层收发接口需要对接STM32 HAL库的以太网驱动。SOEM 1.4.0里底层网卡的抽象接口主要在ecx_setup、ecx_send、ecx_recv这三个函数路径上。实际需要落实的是三个静态函数ccx_setup、ccx_send、ccx_recv。ccx_setup要做的事初始化STM32的ETH DMA描述符配置PHY通过MDIO读取并配置LAN8720使其工作在RMII 100M全双工模式等待自协商完成和链路建立确认PHY地址正确ccx_send要做的事把SOEM给出的以太网帧数据不含CRC拷入TX DMA描述符对应的发送缓冲区设置描述符的发送长度启动DMA发送等待发送完成ccx_recv要做的事查询RX DMA描述符的状态如果收到新帧则返回帧指针和长度如果无新帧则返回0数据被上层处理完后需要把描述符重新挂到RX链上需要注意的一点是SOEM内部会对接收到的帧做解析和校验所以ccx_recv只需要把原始帧交上去就行不需要做任何EtherCAT协议处理。同时因为SOEM是有状态的主站逻辑recv函数在超时时间内没有收到新帧时要及时返回0不能死等。我实现时给ccx_recv加了一个微秒级的轮询循环超过500us没有新帧就强制返回这样SOEM的调度不会被卡死。下面是我移植的ccx_send和ccx_recv的核心逻辑片段用的是STM32 HAL库接口static int ccx_send(void *netif, int idx, uint8_t *buffer, uint16_t len) { ETH_TxPacketConfig txConfig {0}; /* 确保上次发送已完成 */ if (HAL_ETH_Transmit_Frame_IT(heth, buffer, len, ETH_TRANSMIT_CRC) ! HAL_OK) { return 0; } /* 等待TX完成标志位由DMA中断/轮询置位 */ while (tx_done_flag 0) { if (timer_timeout(tx_wait_start, 100)) { return 0; } } tx_done_flag 0; return len; }这里用HAL_ETH_Transmit_Frame_IT传入ETH_TRANSMIT_CRC是为了让MAC硬件自动加上FCS尾巴。如果传成ETH_TRANSMIT_NO_CRCSOEM发出的帧就缺失CRC从站根本不会应答这个问题我栽过一次非常隐蔽。ccx_recv则直接用HAL_ETH_GetRxFrameBuffer循环取出新帧static int ccx_recv(void *netif, int idx, uint8_t *buffer, int maxlen) { ETH_BufferTypeDef rxBuffer; uint32_t framelength 0; int len 0; if (HAL_ETH_GetRxFrameBuffer(heth, rxBuffer) ! HAL_OK) { return 0; } HAL_ETH_GetRxFrameLength(heth, framelength); if (framelength (uint32_t)maxlen) { framelength maxlen; } len ReadFrameData(rxBuffer, buffer, framelength); HAL_ETH_ReleaseRxFrameBuffer(heth); return len; }HAL库的这套接口有个使用习惯要注意每次处理完一帧后必须调用HAL_ETH_ReleaseRxFrameBuffer把RX描述符重新交给DMA否则DMA收帧收着收着就停在某个描述符上不再接收新帧了。这个释放动作如果漏掉EtherCAT从站扫描时很容易出现“能发不能收”的假故障。4.4 周期任务与DC同步EtherCAT主站的核心运行逻辑是一个周期性任务发送过程数据、接收过程数据、根据DC同步信号决定轴运动的相位。在裸机上这个周期任务用SysTick产生1ms周期标志位主循环里检测到标志位后调用SOEM的发送接收接口。下面是从站配置和周期运行的简略流程ecx_context context; char IOmap[4096]; int slavecnt 0; uint8_t group; /* 1. 初始化协议栈和网卡 */ ecx_init(context, NULL); /* 2. 扫描总线上所有从站 */ slavecnt ecx_config_init(context, TRUE); /* 3. 从站配置状态机映射PDO到IOmap */ group ecx_config_map_group(context, IOmap, 0); /* 4. 配置DC分布式时钟 */ ecx_configdc(context); /* 5. 切换到OP状态 */ ecx_statechange(context, 0);周期任务里主要的两个调用是ecx_send_processdata和ecx_receive_processdata。发送前需要更新PDO数据区IOmap接收后从IOmap里解析从站状态。这套流程SOEM官方示例写得很清楚但在STM32上要注意两点第一ecx_receive_processdata的第二个参数是超时时间微秒如果设置太短在总线上从站数量多时容易返回超时导致数据解析不完整设置太长又会拖慢周期。我实测1ms周期下这个超时参数设为200到300us比较稳妥。这个值本质上是在等一个周期的EtherCAT帧跑完整条链路后返回。第二如果使用DC时钟同步需要在周期任务开始时等待DC中断标志或者从站时钟同步标志到达。F407没有专门的EtherCAT从站ESC硬件所以DC同步的基准是让主站根据SOEM测得的传播延迟值在合适时机发帧。SOEM的ecx_configdc和ecx_dcsync0会处理这些计算底层只需要给ecx_send_processdata传入正确的group编号即可。5. 踩坑记录与排查实录这部分是我花最多精力整理的内容。SOEM移植中的很多坑网络上的文档不会写但在实际项目中一定会遇到。5.1 LAN8720上电不复位PHY地址永远不对这个坑几乎是每个人都会踩。LAN8720的复位引脚如果只接了一个简单的上拉电阻上电时PHY可能没有完成有效复位导致MDIO读取到的PHY ID不对甚至PHY地址不是期望的0x00。解决办法是在初始化代码的开始处把nRST引脚如果接到了GPIO做一次显式的低电平复位拉低至少10ms再拉高然后等待至少100us。如果是硬件RC电路要确认RC的充电时间足够给PHY一个不低于几十毫秒的复位周期。实测发现如果上电后立即读取LAN8720的寄存器0或1经常读到全0xFF或全0x00这是PHY还没ready的典型表现。正确做法是初始化流程里先做软件复位等待再开始访问。5.2 RMII 50MHz时钟方案的选择与坑RMII模式下50MHz参考时钟是整个链路稳定运行的关键。我一开始用的是STM32F407的MCO1引脚输出50MHz时钟但实测发现MCO输出的50MHz时钟抖动比较大EtherCAT包收发偶发的CRC错误率居高不下。后来改成LAN8720外接25MHz晶振由PHY内部倍频到50MHz再由REF_CLK引脚输出给STM32数据链路就稳定了。这个经验不一定适用所有板子但如果你用MCO方案出现了偶发丢包、偶尔掉线优先怀疑时钟质量。另外如果用外部50MHz有源晶振给LAN8720提供时钟需要注意晶振的电源滤波REF_CLK引脚下最好加一个小电容滤波减少高频干扰。5.3 发送帧不完整从站毫无反应排查EtherCAT从站扫描不到时最有效的手段是在主站端抓以太网帧。如果手头没有逻辑分析仪可以在ccx_send里加一个调试钩子统计最近发送帧的前几个字节和长度。有一次我发现发送帧长度一栏一直不对检查后定位到是发送描述符的FrameLength字段赋值位置错了导致MAC实际发送的数据长度和缓存不一致从站自然无法解析。另一个经典问题是发送时忘了让MAC硬件补FCS。SOEM构造的EtherCAT帧不包含尾部CRC这部分必须由MAC硬件在发送时自动补齐。如果初始化DMA的时候配置成了NO_CRC模式总线上的帧就是不完整的整个扫描过程就废了。这个问题一旦发生表现非常隐蔽因为PHY链路正常、发送中断正常、接收缓冲区里也偶尔能看到一些回包但从站状态确认为INIT/ERROR。5.4 从站扫描能扫到但状态机切换失败能扫描到从站说明底层收发已经通了。状态机切换失败的原因常见的是PDO映射配置问题或FMMU分配问题。SOEM的ecx_config_map_group会从从站EEPROM里读PDO信息如果从站EEPROM里的映射数据和实际不一致或者主站的IOmap矩阵长度不够状态切换就会卡在PREOP到SAFEOP这段。排查方法是打开SOEM的调试信息打印。SOEM 1.4.0支持自定义调试输出可以配置ecx_setup使用自己的print函数打印每个从站的SII内容和映射信息。我建议在一开始就把调试开关打开把每个从站读到的PDO数量和映射内容打印出来比对着从站手册看很快就能定位问题。不要相信“程序没报错就说明配置没错”这种话。5.5 DC时钟同步的一个细节DCDistributed Clock分布式时钟同步是EtherCAT实现高精度轴同步的关键。SOEM的ecx_configdc会在启动时测量主站到各个从站的数据传播延迟并计算偏移。实测下来这部分计算在F407上跑得很稳。但有一个细节要注意如果总线上混用了支持DC和不支持DC的从站需要在ecx_configdc之后手动检查每个从站的DC支持能力对不支持DC的从站跳过同步配置。否则SOEM在尝试配置不存在的同步单元时会返回错误导致后续的ecx_dcsync0直接失败。5.6 周期抖动与实时性调优裸机跑EtherCAT周期抖动是绕不开的话题。F407没有硬件EtherCAT从站控制器也没有独立的高精度运动控制定时器虽然PWM定时器很多很精准但主站周期调度依赖以太网收发完成后的中断。我实测在裸机环境下主站周期抖动大概在正负50us级别如果要带高同步要求的运动控制这个抖动水平可以通过软件调整来改善以太网接收中断优先级调到最高不让其他中断打断帧接收处理。周期任务里不要做printf之类的IO操作调试打印放到周期外。发送和接收函数在周期内只做DMA搬运和协议栈解析剩下的应用层逻辑坐标计算、插补放到该周期收完帧之后的剩余时间里完成。有RTOS的情况下可以把主站任务优先级设为最高并用mutex保护对IOmap的访问没有RTOS就直接让主循环跑周期调度。6. 常见问题速查表与调试技巧考虑到很多人会照着这篇文章去做我把实际遇到的典型问题整理成一个速查表方便现场快速定位。这张表的每个条目都对应我在调试过程中真实遇到过的现象。现象可能原因排查方法PHY寄存器读不到值或读到全F复位时序不足、MDC/MDIO引脚复用配置错先拉低nRST 20ms检查GPIO复用用单独函数轮询PHY ID能发帧但没有收包中断RX描述符释放遗漏、HAL接收缓冲配置不足检查HAL_ETH_ReleaseRxFrameBuffer是否被调用RX描述符数量加到8从站扫描不到设备帧缺少FCS、PHY工作在半双工、TX描述符长度配置错打印发送长度抓帧看头部和尾部检查自动协商结果状态机卡在PREOPPDO映射不匹配、FMMU配置失败打开SOEM调试打印对比从站EEPROM映射DC同步后轴动作偶发跳变周期抖动大、DC配置延时未生效提高接收中断优先级检查ecx_configdc的返回值运行一段时间后网络无响应描述符泄漏、内存踩踏统计空闲描述符数量支持内存调试内存边界加哨兵字符调试技巧方面我强烈建议在移植初期就实现一个简易的串口调试输出通过UART打印SOEM的调试信息和周期统计。裸机上printf重定向到串口用DMA方式发送不要在中断里直接用阻塞发送。软件调试这个环节花的时间后期排查问题能几百倍地省回来。还有一个小技巧SOEM提供了ethercatdbg和测量传播延迟的调试指令编译开关打开后可以从主站端tcp/udp下发命令查看从站状态和链路情况。在裸机上虽然没有网络调试接口但仍可以利用SOEM内部的ecx_dump等函数把拓扑信息打印到串口。这些信息在排查从站参数错误时价值极大。7. 一点个人体会做完这个项目我最大的感受是SOEM能跑通底层网络链路占七成功劳协议栈本身反而不用怎么动。STM32F4的以太网外设并不复杂但每个细节——PHY复位、RMII时钟、DMA描述符、CRC配置——都藏着雷。真正动手之前一定要把PHY的数据手册读透尤其是LAN8720的寄存器定义和时钟要求这些文档里的内容比任何博客都准确。后面如果还有余力我打算把SOEM移植到RT-Thread或者FreeRTOS上跑这样周期任务可以交给RTOS调度进一步加强实时性也让整个主站具备多任务处理能力。再往后可以考虑把常用的CoE对象字典、CiA402伺服控制协议封装成一套简洁的API让上层应用不用关心EtherCAT细节直接轴控制逻辑。到时候再写一篇新的记录出来。