EtherCAT从站源代码应用举例
作者广州虹科电子EtherCAT团队  support@hkaco
一般从站代码内容如下（以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从站代码对比表
特性KPA从站协议栈其他代码（如免费）
支持的输入/输
出 SM数量无限制在样例中只支持一个输入和输出SM
过程镜像处理
过程镜像和对象的数据交换API功能（通
常调用一个功能就足够）过程镜像必须在应用中进行处理
对象字典创建
在应用代码中创建或从一个OD.xml文件
中装载（标准形式）在应用代码中创建
对象与变量绑定
每个对象条目都可以和独立的变量进行
绑定（通过其指针）
一个对象不能由一些不同的变量组成
—仅有一个指针能绑定整个对象（如，
对象条目的所有变量结构）
表一 KPA从站代码对比表（续）
特性KPA从站协议栈其他代码（如免费）
CoE对象参数支持所有参数，该过程在协议栈中完成不支持对象的最大、最小和默认值灵活映射用户
在固定和非固定映射之间没有区别只有固定映射可以在样例应用中实现
CoE SDO处理在协议栈中完全支持
邮箱储存残片不被支持用于对象和条目描述
从站协议的易操作性
对于常规的从站应用，调用一点点API功
能就足够了
一些从站的功能必须要在应用中实现
（如：过程镜像处理）
SDO和状态变换事件 SDO回调函数和状态变换事件都被支持，
并且可以在运行过程中设置或移除
SDO和状态变换事件的代码处理必须包
含在从站协议源码中
从站协议库
操作系统抽象层（OSAL）使用了一系列功
能—一个静态库可以作为一个协议的独立
部分来根据平台创建
使用定义（#define，#ifdef…）来适
配平台。平台与独立的协议不能独立作
为一个库没有OSAL

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。