2024年5月31日发(作者：)

广州虹科电子科技有限公司

EtherCAT从站源代码应用举例

作者 广州虹科电子EtherCAT团队 support@

一般从站代码内容如下（以KPA为例）:

1）一个调试和配置以及诊断用的软件KPA Studio：可以生成XML文件（从站的ESI文件），可以对EEPROM

编辑，可以诊断网络故障，可以模拟ECAT主站，可以记录报文和数据等；

2）提供的demo包括：STM32F407，TI DSP28335，TI Sitara，赛灵思FPGA（uBlaze），Altera FPGA(NiosII)；

3）大概2万行的代码量，详细的编程指导、帮助文档、API说明书等。

EtherCAT从站代码应用范围：

1） 开发伺服驱动器

2） 开发EtherCAT协议网关

3） 开发EtherCAT IO模块（普通IO和高速IO）

4） 其他：比如集采集和控制功能一起的应用模块

注：很多用户会误解：是否买了商业版的从站的代码就可以不用买专用芯片ESC或者IPcore了，答案是

否定的。从站源代码不能取代ESC（即ET1100等），也不能取代IPcore。IP Core和ESC处理的是EtherCAT

数据帧，把以太网数据转换到ESC的DPRAM等。而EtherCAT从站代码是加载到MCU或FPGA软核上的软协

议，基本是控制从站状态机，邮箱通信，过程数据通信，CoE，FoE等应用层协议。

EtherCAT从站开发的方案选型：

一：针对开发伺服驱动器的方案：

绝大部分KPA客户均开发伺服驱动器，。这些客户主要采用的硬件方案包括以下三种：

1） FPGA+IPcore：购买倍福的IPcore软核（IPcore只有库函数，没有源代码，开发包一年的开发年限，

以后每年交年费，不限产品数量）。FPGA可选Altera或者Xilinx，购买IPcore时，需要跟倍福确认

是哪款IPcore，因为针对Altera和Xilinx的IPcore是不同的。KPA的EtherCAT从站源代码移植到

Altera的FPGA软核NiosII或者Xilinx的FPGA软核uBlaze中，软核相当于一个CPU，IPcore是在

FPGA上划分了一个逻辑空间给IPcore封装后，这块逻辑资源相当于就是一个专用芯片ESC的作用，

软核与IPcore之间是内部总线通讯。

这个方案要求工程师具备FPGA的开发经验，如果产品数量较大的话，该方案的成本最优，而且FPGA

内部总线实现的数据通讯一般来说比SPI或者并行总线与ESC之间的数据交互更快，因此该方案的伺

广州虹科电子科技有限公司

服高速性能一般也较优秀。

2） CPU+专用芯片ESC的方案：最常见的客户是TI DSP28335+ET1100或者LAN9252，还有少量客户是用

STM32F103/F107+ET1100/LAN9252，这种客户大部分是采用SPI或者并行总线等将CPU与ESC相连。

KPA的从站代码移植到CPU上，负责处理从ESC中获取的数据或者将数据处理完再通过PDO等数据发

出去，大部分是Process Image的过程数据交互和更新。SPI总线方式比较慢，并行总线较快。

3） 少量集成了小型CPU+专用芯片功能的方案：比如AM335X，XMC4800， R-IN32等。有些用户认为集成

了小型CPU带来一个问题是功能比较受限制，不够灵活，所以有些用户是再外扩一个CPU，即比如采

用STM32F407+XMC4800的开发方案。

一般来说，以上三种方案的使用频率是：第二种>第一种>第三种。

二：EtherCAT网关：

目前KPA国内客户有一个是开发EtherCAT网关的，采用STM32F205+ET1100，开发EtherCAT转CANopen网

关。

三：EtherCAT IO模块：

（1） 普通IO模块：

目前KPA有四五个客户主要开发EtherCAT IO模块，大部分是因为自己的机器人系统以及数控系统的IO

用量很大，而外购的比如倍福模块的成本太高。采用的硬件方案包括：

1） STM32F103+LAN9252：目前这个方案的成本很低，性价比高，做IO模块非常合适。目前很多做

IO模块的客户用这个方案，KPA的EtherCAT从站代码移植到STM32F103。STM32F103与LAN9252

采用SPI总线连接。

2） 集成了ESC和小型CPU的ASIC，比如英飞凌XMC4800，瑞萨RZ-T1，TI AM335X等

（2） 高速IO模块：

大部分用FPGA（纯FPGA比如赛灵思Spartan6或Altera，2带ARM等的SoC，比如赛灵思ZYNQ或

者Altera Cyclone）：利用了FPGA高速IO处理的优势。EtherCAT协议栈移植到FPGA软核，或者

SoC器件的ARM端。

目前，EtherCAT从站开发面临的现状是：

a) 目前从站协议栈提供了匮乏的API 以及没有深入的支持。其结果是一个平坦的学习过程。

b) 对象字典要求多次迭代，每个ESI 和SII 文件都需要进行适配。需要手动进行同步

广州虹科电子科技有限公司

c) 有时协议栈需要一个操作系统，但是一个操作系统的抽象层没有被提供。

工程师在EtherCAT从站开发中的需求：

强大的 API、一个能够保持所有文件一致的工具和一个抽象层

从站源代码方案优势（以KPA为例）：

 KPA 从站向导根据任何描述创建过程数据和对象字典的数据结构

 KPA Studio集成了SII 编辑器EEPROM Editor（非常方便地编辑EEPROM并查看配置结果，最终生成

XML配置文件）

 从站协议栈已完成了硬件平台以及操作系统的适配（x86、ppc、ARM），如：Xenomal 用户/内核空间

 KPA把以下工作都简化成了API函数接口，用户根据说明书和文档可以直接找到自己需要的API函数

并应用。比如，PI的输入和输出、OD结构体的编辑、PDO映射、分布时钟、统计和诊断功能、对象字

典的解析、邮箱通讯的设置、状态切换机制、报错处理和紧急处理的机制、IRQ中断机制、轮询机制、

主站配置信息和设备EEPROM的实际配置的对比以及如果不匹配后的处理机制等等。所以，工程师无

需对寄存器和RAM操作。

 提供了操作系统抽象层并独立出来，方便用户移植到不同的OS。

 提供了完整的操作文档，API函数库，源代码，样例程序

 代码结构好，非常方便使用

 工程师协助一致性测试

 一次性买断，无任何授权费用

 赠送KPA Studio：可以模拟主站、配置网络、生成/导入/修改ESI/SII文件和XML文件，诊断网络故

障并给出建议，方便做网络/工程对比等等。

 充足的本地技术支持资源：广州配备技术支持中心，上海配备研发中心。可以为用户提供不同程度的

技术支持，从产品软件的使用到开发移植的指导。目前的研发经验包括：TI DSP 28335+ET1100、

STM32F103+ET1100、STM32F205+ET1100、STM32F103+LAN9252以及FPGA+IPcore

从站代码框架图（以KPA为例）如下：

广州虹科电子科技有限公司

图一 KPA从站代码框架图

KPA从站代码与其他代码的对比表：

表一 KPA从站代码对比表

特性

支持的输入/输

出 SM数量 无限制

过程镜像和对象的数据交换API功能（通

过程镜像处理 常调用一个功能就足够）

在应用代码中创建或从一个文件

对象字典创建 中装载（标准形式） 在应用代码中创建

一个对象不能由一些不同的变量组成

每个对象条目都可以和独立的变量进行—仅有一个指针能绑定整个对象（如，

对象与变量绑定 绑定（通过其指针）

对象条目的所有变量结构）

过程镜像必须在应用中进行处理

在样例中只支持一个输入和输出SM

KPA从站协议栈 其他代码（如免费）

广州虹科电子科技有限公司

表一 KPA从站代码对比表（续）

特性 KPA从站协议栈 其他代码（如免费）

CoE对象参数 支持所有参数，该过程在协议栈中完成 不支持对象的最大、最小和默认值

灵活映射 用户在固定和非固定映射之间没有区别 只有固定映射可以在样例应用中实现

邮箱储存残片不被支持用于对象和条

CoE SDO处理 在协议栈中完全支持 目描述

从站协议的易操 对于常规的从站应用，调用一点点API功 一些从站的功能必须要在应用中实现

作性 能就足够了 （如：过程镜像处理）

SDO和状态变换 SDO回调函数和状态变换事件都被支持， SDO和状态变换事件的代码处理必须包

事件 并且可以在运行过程中设置或移除 含在从站协议源码中

操作系统抽象层（OSAL）使用了一系列功 使用定义（#define，#ifdef…）来适

能—一个静态库可以作为一个协议的独立配平台。平台与独立的协议不能独立作

从站协议库

部分来根据平台创建 为一个库没有OSAL