4、EtherCAT从站软件架构：从站协议栈移植（SSC、SOES）、应用层任务设计、PDO映射与配置
好，咱们今天聊点实在的。EtherCAT从站开发，说白了就是两件事：让芯片能听懂EtherCAT的“话”，然后让它干你想要的“活”。前者是协议栈，后者是应用层。我见过不少新手，一上来就埋头写代码，结果协议栈跑不起来，或者跑起来了但数据对不上。嗯，这里面的坑，我踩过不少。
4.1 从站协议栈移植：SSC vs SOES
协议栈是什么？你可以把它想象成一个翻译官。EtherCAT主站发过来的报文，它负责解析，然后把有用的数据提取出来，放到你指定的内存里。反过来，你要发给主站的数据，它也帮你打包好。
目前主流的开源方案有两个：SSC（Slave Stack Code）和SOES（Simple Open EtherCAT Slave）。
4.1.1 SSC（倍福官方出品）
SSC是Beckhoff官方提供的代码生成工具。我个人习惯用这个，因为它生成的代码结构非常清晰，而且支持几乎所有的从站芯片。
- 优点：代码质量高，文档齐全，技术支持好。
- 缺点：需要License（虽然可以申请免费评估版），代码量较大，对MCU资源有一定要求。
- 适用场景：产品级开发，对稳定性和可靠性要求高的场合。
移植SSC时，你主要需要关注三个文件：ecat_slv.c、ecatappl.c和hal_xxx.c。其中hal_xxx.c是硬件抽象层，你需要根据你的MCU（比如STM32、GD32）实现底层的SPI或8/16位总线接口函数。
核心要点：SSC的移植，本质上是把“硬件接口”和“应用回调”填好。其他部分，相信我，别乱动。
4.1.2 SOES（轻量级开源方案）
SOES是RT-Labs开源的轻量级协议栈。如果你用的是资源受限的MCU，比如Cortex-M0或者M3，SOES会是个好选择。
- 优点：代码精简，移植简单，开源免费。
- 缺点：功能相对SSC少一些，比如不支持某些高级特性（如DC分布式时钟的某些模式）。
- 适用场景：学习研究、原型验证、成本敏感型项目。
SOES的移植更直接。你只需要实现osal.h中的几个宏定义和函数，比如CC_ASSERT、osal_memcpy等。然后实现esc_hw.c中的硬件接口函数。
我的建议：如果你是第一次接触EtherCAT，先从SOES入手。跑通了，理解了，再去看SSC。我曾经带过一个实习生，直接上SSC，结果被代码量吓到了。后来换成SOES，三天就跑通了。
4.2 应用层任务设计
协议栈跑起来之后，就该考虑应用层了。应用层任务，说白了就是你的“业务逻辑”。比如，你是一个伺服驱动器，应用层任务就是读取位置指令、计算电流环、输出PWM。
这里有一个关键点：实时性。EtherCAT的周期通常只有1ms甚至更短。你的应用层任务必须在这个周期内完成。
4.2.1 任务划分
我一般把应用层任务分成三类：
- 同步任务：必须在每个EtherCAT周期内执行。比如读取PDO数据、更新输出。
- 异步任务：不需要严格同步，但需要定期执行。比如温度监控、故障诊断。
- 后台任务：优先级最低，有空就做。比如参数保存、日志记录。
避坑指南：我曾经在一个项目中，把参数保存放在了同步任务里。结果每次保存参数，都会导致总线抖动。后来改成后台任务，问题就解决了。记住，同步任务里只做最核心的事。
4.2.2 任务调度
任务调度有两种常见方式：
- 轮询方式：在main函数的大循环里，依次检查各个任务是否需要执行。简单，但效率低。
- 中断+状态机方式：利用定时器中断触发同步任务，其他任务在后台轮询。效率高，但代码复杂度增加。
我个人更推荐第二种。因为EtherCAT的同步中断（SYNC0/SYNC1）本身就是最好的定时器。你只需要在中断服务函数里设置一个标志位，然后在主循环里检查这个标志位，执行同步任务。
// 伪代码示例
volatile uint8_t sync_flag = 0;
void SYNC0_IRQHandler(void) {
sync_flag = 1;
// 清除中断标志位
}
int main(void) {
while(1) {
if(sync_flag) {
sync_flag = 0;
// 执行同步任务：读取PDO，更新控制算法
sync_task();
}
// 执行异步任务
async_task();
// 执行后台任务
background_task();
}
}
4.3 PDO映射与配置
PDO（Process Data Object）是EtherCAT的灵魂。主站和从站之间交换的实时数据，都是通过PDO来传递的。
PDO映射，说白了就是告诉你：哪个数据放在哪个地址。比如，你把“电机目标位置”映射到PDO的字节0-3，把“电机实际速度”映射到字节4-7。
4.3.1 对象字典与PDO映射
每个EtherCAT从站都有一个对象字典（Object Dictionary）。对象字典里定义了所有可访问的参数。PDO映射就是把这些参数“打包”成一个个PDO。
举个例子，一个简单的数字量输入模块，它的对象字典可能长这样：
| 索引 | 名称 | 类型 | 说明 |
|---|---|---|---|
| 0x6000 | Digital Input 1 | UINT8 | 第1-8通道输入状态 |
| 0x6001 | Digital Input 2 | UINT8 | 第9-16通道输入状态 |
那么，PDO映射就可以这样配置：
- RxPDO（主站->从站）：无（数字量输入模块不需要接收数据）
- TxPDO（从站->主站）：包含0x6000和0x6001两个对象
4.3.2 配置方法
PDO映射的配置有两种方式：
- 静态配置：在从站代码中写死。适合功能固定的设备。
- 动态配置：通过SDO（Service Data Object）在线修改。适合需要灵活配置的设备。
静态配置很简单，你只需要在ecatappl.c中填充PDO映射表即可。动态配置稍微复杂一些，需要实现SDO访问的回调函数。
注意：动态配置虽然灵活，但会增加代码复杂度和出错概率。我建议，除非你的设备确实需要在线修改PDO映射，否则就用静态配置。简单、可靠。
4.3.3 实战中的PDO设计
在实际项目中，PDO的设计需要综合考虑数据量、周期时间和总线负载。我一般遵循以下原则：
- 最小化PDO数量：能用1个PDO搞定，绝不用2个。因为每个PDO都有额外的开销。
- 对齐数据：尽量把相同类型的数据放在一起。比如，所有32位整数放一个PDO，所有8位布尔量放另一个PDO。
- 预留扩展位：在PDO末尾预留几个字节，方便以后增加功能。我曾经因为没预留，后来不得不修改ESI文件，导致现场升级很麻烦。
这张图把整个架构串起来了。你看，主站通过EtherCAT总线与从站协议栈通信，协议栈解析报文后，通过PDO映射把数据交给应用层。应用层处理完业务逻辑后，再通过PDO把结果返回给协议栈，最终发回主站。
嗯，到这里，从站软件架构的核心内容就讲完了。记住，协议栈是骨架，应用层是血肉，PDO映射是血管。三者缺一不可。
最后说一句：开发EtherCAT从站，不要急于求成。先把协议栈跑通，再慢慢优化应用层。我见过太多人，一上来就想把所有功能都塞进去，结果调试了几个月都出不了活。稳扎稳打，才是正道。