注：以下文章内容通过网站资料整理而来，如有侵权，抱歉联系删除～
学习EtherCAT最好从从站开始，因为从站包含了EtherCAT大量原理，例如状态机，PDO映射等。学习从站代码有利于理解过程数据如何传输，XML有什么作用。本文介绍一些从站的基础知识，以及如何设计一个功能完善的从站。
从站硬件
无论是以ASIC还是FPGA的形式，ESC都是从站的核心，主站通过读写ESC的DPRAM空间实现数据传输。ESC通过PDI接口将数据发送到MCU，在MCU中执行实际的应用层操作。ESC根据倍福公司的IP core设计，目前主流的ESC芯片包括：
- ASIX公司的AX58100芯片；
- BeckHoff自己的ET1100芯片；
- Microchip的LAN9252芯片；
- FPGA：ET1810(altera)和ET181(xilinx)；
由于都是基于BeckHoff的IP core设计的，因此这几个芯片在实际功能上差距并不大，区别在于DPRAM的大小，SM的数量，FMMU的数量，PDI的方式等。
| 芯片 | 网口 | FMMU | SM | RAM (kBYTE) | 数字IO | SPI slave | Local BUS |
| AX58100 | 2内部PHY，1MII | 8 | 8 | 9 | 32 | Y | 8/16 async |
| Lan9252 | 2内部PHY，1MII | 3 | 4 | 4 | 32 | Y | 8/16 sync/async |
| ET1100 | 4EBUS/MII | 8 | 8 | 8 | 16 | Y | 8/16 sync/async |
关于芯片的详细参数，可以访问
The following is AX58100 block diagram：
ESC具有各类AL寄存器供主站访问，但实际不执行具体的应用层操作，从站应用层的管理由专门的MCU进行。stm32有强大的性能和完善的生态，因而是应用层使用最为广泛的芯片，也可以采用其他的硬件例如Arduino或者ESP32实现应用层逻辑，但是要支持对应ESC的相关PDI接口。
一般来说，从站硬件系统如下图所示：
从站最小系统
从站软件
从站帧的链路层功能都是由ESC完成的。从站软件运行在MCU中，主要执行的是应用层的操作。
MCU通过PDI接口读取ESC中的PDO和SDO数据，然后执行应用层的处理，例如状态机，COE，EOE等相关逻辑。MCU需要一套协议栈执行相关的逻辑，目前使用最多的从站协议栈是EtherCAT技术组（EtherCAT Technology Group，ETG）为会员提供的Slave Stack Code（SSC），SSC支持几乎所有应用层协议栈（EOE，COE，FOE）等，同时还提供了对专有协议Cia402等的支持。除此之外，SSC还提供了专门的工具来配置协议栈和PDO。
SSC的缺点是，它是针对BeckHoff自己的PIC和ET1100芯片写的，如果使用stm32或者其他通用处理器，需要手工移植代码。
ssc的代码框架
除了SSC之外，另一个比较有名的EtherCAT开源协议栈是SOES（GitHub - OpenEtherCATsociety/SOES: Simple Open Source EtherCAT Slave），SOES支持EOE和COE这两种较为常用的应用层协议，同时支持静态和动态的PDO映射。SOES的代码相较于SSC精简很多，代码可移植性较好。
商用从站协议栈中，比较具有代表性的是KPA协议栈（https://koenig-pa.de/products/ethercat/kpa-ethercat-slave-stack）。作为商用协议栈，KPA协议栈几乎支持所有的EtherCAT特性，包括：
- 邮箱协议：COE，EOE，FOE，SOE，VOE
- 分布时钟DC；
- 不同的扫描速率；
从可移植性的角度，KPA协议栈实现了一个硬件抽象层，支持不同ESC和主控芯片的数据交互。数据从PDI传输到MCU后，首先通过的是硬件抽象层，主循环轮询AL事件来获取过程数据和邮箱数据的更新，然后基于对象字典更新PDO和SDO。
从站功能
操作系统层
对于实时性和同步要求极高的场合，一般一个系统运行一个从站任务就好了，例如电机驱动从站，此时不建议使用操作系统，直接进行SSC协议栈移植即可。但是实时要求不强的场合，每个任务/接口使用一个从站是很浪费的，毕竟ESC还是有点小贵的，对于任务很多的从站，还是有必要上嵌入式实时系统。下面介绍一下嵌入式操作系统的作用。
操作系统层的主要作用是合理对从站任务进行调度。
作为现场总线的一部分，一个EtherCAT从站一般至少包含两个任务，一个从主站获取EtherCAT数据，另一个与控制设备（比如电机或CAN总线）交互。在多任务环境下，为了确保EtherCAT通信的实时性、增强任务调度的合理性、有效利用系统资源，从站应当基于实时操作系统进行开发。相较于Linux等操作系统，嵌入式操作系统具有如下特点：
- 小型系统：由于嵌入式设备功能明确，操作系统往往与应用程序编译在一起运行。
- 实时性：嵌入式操作系统往往是实时操作系统。很多嵌入式设备对处理的实时性有严格要求，这种实时性是通过操作系统层面的任务调度机制、任务优先级的设定和应用程序的快速处理来达到的。
- 可移植性：由于嵌入式设备的应用场景多样，复杂程度千差万别，应用程序的大小各不相同，移植的需求是频繁发生的。
ucos，vxworks，FreeRTOS和RT-thread是较具代表性的实时操作系统。
这里以RT-thread为例介绍嵌入式实时系统的组成，RT-thread不仅是一个实时操作系统，也是一个完善的嵌入式软件生态。它的底层是RT-thread内核，基于内核还提供了网络框架，设备框架，以及各类API。最后在应用层还提供了各类具体应用。
RT-thread架构
线程管理
RT-thread内核是一个RT-thread程序的核心，RT-thread内核是一个基于优先级的全抢占式多线程调度系统，在该实时系统中，线程是最小的调度单位，系统中除了中断处理函数、调度器上锁部分的代码和禁止中断的代码是不可抢占的之外，系统的其他部分都是可以抢占的，包括线程调度器自身。RT-thread的线程调度关系如下。在RT-thread 中，实际上线程并不存在运行状态，就绪状态和运行状态是等同的。
RT-thread线程
RT-thread最多支持256个线程优先级，0优先级代表最高优先级，最低优先级留给空闲线程使用。同时它也支持创建多个具有相同优先级的线程，相同优先级的线程间采用时间片轮转调度算法进行调度，使每个线程运行相应时间。
线程间通信
RT-thread支持线程间的同步和通信。采用信号量、互斥量与事件集实现线程间同步，线程通过对信号量、互斥量的获取与释放进行同步。支持邮箱和消息队列等通信机制。邮箱和消息队列的发送动作可安全用于中断服务例程中。通信机制支持线程按优先级等待或按先进先出方式获取。
时钟管理
任何操作系统都需要提供一个时钟节拍，以供系统处理所有和时间有关的事件，如线程的延时、线程的时间片轮转调度以及定时器超时等。时钟节拍是特定的周期性中断，中断之间的时间间隔取决于不同的应用，时钟节拍率越快，系统的额外开销就越大，从系统启动开始计数的时钟节拍数称为系统时间。RT-Thread 的时钟管理以时钟节拍为基础，时钟节拍是 RT-Thread 操作系统中最小的时钟单位。RT-Thread 的定时器提供两类定时器机制：
- 单次触发定时器：这类定时器在启动后只会触发一次定时器事件，然后定时器自动停止。
- 周期触发定时器：这类定时器会周期性的触发定时器事件，直到用户手动的停止定时器否则将永远持续执行下去。
通常使用定时器定时 回调函数（即超时函数），完成定时服务。用户根据自己对定时处理的实时性要求选择合适类型的定时器。
内存管理
内存是系统的重要资源，特别是对于资源紧张的嵌入式设备来说。RT-Thread将内存分为动态内存堆和静态内存池，对于动态内存的申请，RT-Thread提供小内存分配算法，slab算法和memheap算法。为了避免内存碎片，提高分配效率，RT-Thread还在.data段提供一个静态的内存池。
设备管理
和Linux驱动框架类似，RT-Thread也通过I/O设备模型框架对外设进行管理。I/O 设备管理层实现了对设备驱动程序的封装。应用程序通过 I/O 设备管理接口获得正确的设备驱动，然后通过这个设备驱动与底层 I/O 硬件设备进行数据交互。设备驱动程序的升级、更替不会对上层应用产生影响。这种方式使得设备的硬件操作相关的代码能够独立于应用程序而存在，双方只需关注各自的功能实现，从而降低了代码的耦合性、复杂性，提高了系统的可靠性。
硬件抽象层
硬件抽象层的主要作用是提升程序的可移植性。
与ESC的数据交互，是EtherCAT从站MCU最为重要的功能。MCU通过PDI访问ESC的内存空间，读取寄存器和过程数据，因此，有必要对ESC的数据访问进行封装，封装的目的是保证在MCU应用层能够通过通用的接口实现对不同类型从站ESC，不同接口PDI的访问。
关于硬件抽象层的封装，SOES实现了所有硬件访问相关函数：
应用层协议
EtherCAT从站的目标是能够支持各类应用层协议，这其中最主要的是COE协议和基于COE的各类行规。此外还需要支持FOE，EOE，SOE等协议。
- COE：CANopen over EtherCAT，EtherCAT协议在应用层支持CANopen协议，并作了相应的扩充，CoE协议完全遵从CANopen协议。COE协议十分核心且复杂，在此不作过多介绍。
- EOE：EtherNet over EtherCAT，该协议支持EtherCAT能分段传递标准的以太网数据报文，使得EtherCAT协议同样能支持TCP/IP、UDP/IP协议。
- SOE：Servo Drive over EtherCAT。SERCOS是世界首个应用于伺服控制的协议。EtherCAT协议在应用层接口上兼容了这个协议，简称为SOE。SERCOS应用层协议为主站设计了信息接口，可以通过配置EtherCAT过程数据报文，实现周期性传递伺服驱动器的数据。
- FOE：File Access over EtherCAT。该协议可以使用EtherCAT总线上传、下载固件，刷新从站的固件。并且可以通过命令行工具加载或存储文件。
结合实际需求，COE和基于COE的行规协议CiA402等是必须实现的，FOE、EOE作为程序的扩展功能有必要实现，而SOE不是常用需求。
动态PDO映射
静态PDO映射是将PDO变量“写死”在从站中，对于实际应用场景是十分不友好的，例如某个机型的电机需要实时传输电机温度，但在另一个机型中不需要温度信息，如果使用静态PDO映射，为了提升传输效率，删除温度PDO，则需要修改代码，烧写固件，更新XML文件。这样会带来巨大的工作量。特别是基于CiA402的驱动器来说，经常要根据上位机软件的需求修改传输变量。
动态PDO映射允许定制PDO以满足客户需求，TwinCAT和KPA studio等上位机软件都支持以勾选的形式动态配置PDO。为了使得上位机能够修改PDO assign，需要在xml中配置mandatory为false（SSC在EXCEL）中可以配置。
动态PDO映射的基本原理是操作对象字典的0x1C12和0x1C13对象，这两个对象分别管理输出和输入的PDO映射。过程如下：
- 将Ethercat状态机切换到PreOP状态，此状态可以用SDO来配置PDO映射；
- 清除PDO指定对象的PDO映射对象，即设置0x1C12-00,与0x1C13-00为0；
- PDO映射对象无效，即对0x1600-0x1603/0x1A00-0x1A01的子索引设置为0；
- 重新配置PDO映射内容；0x1600-01开始的是RxPDO内容，0x1A00-01开始的是TxPDO；
- 设置PDO映射对象总数；
- 写有效的PDO映射对象索引到PDO指定对象
- 设置PDO指定对象的总个数，即将映射对象个数写入到1C12-00h和1C13-00h
- 转换Ethercat状态机到安全操作以上，配置的PDO映射将有效。
分布时钟
EtherCAT各个从站得到帧后会进行处理或者转发，这需要一定的微小时间。但当需要经手的从站多，或者数据量大的时候，积少成多会导致较大的延迟，并且电缆线内信号传输也占有一定的延时时间。分步时钟可以使所有的EtherCAT设备使用相同的系统时间，从而控制各设备的任务的同步执行，支持分布式时钟的从站称为DC从站。
为使各个从站的参考时钟达到绝对同步，主站会计算各个从站的偏移时间，这个值会写入对应从站的系统时间偏移寄存器。在从站端，分布时钟由ESC芯片实现，ESC为从站控制微处理器提供同步的中断信号和时钟信息，分布时钟单元可以产生两个同步信号SYNC0和SYNC1，用于给应用层提供中断或直接触发的输出数据更新。MCU可以通过ESC的中断信息和时间漂移寄存器的值更新本地系统时钟。
分布时钟是从站的重要功能，SSC和SOES都实现了分布时钟，可以参考这两者的设计实现该功能。
SDK
目前从站代码开发主要有两种方式：
- 基于现有的代码进行移植：目前对于成熟的ESC（ET1100、LAN9252、AX58100）都有比较成熟的解决方案。但移植仍然要求对代码较为熟悉，如果添加新功能较为困难，综合来看较为麻烦；
- 基于从站软件生成：SSC，SOES和KPA都提供了对应的从站代码生成器，但是SSC是针对自己的的PIC32芯片的，仍然需要手动移植代码；SOES和KPA的从站软件都属于商用软件需要较高的授权费；
因此通过一个SDK简化从站开发流程是有必要的，参考SOES的slave editor，SDK所需的功能如下：
- 从站基本信息：允许通过界面添加XML的必要信息，例如vendor ID，product ID等；
- 数据链路层配置，允许通过界面配置FMMU，SM同步管理器和邮箱；
- PDI的配置：允许通过界面配置PDI相关寄存器；
- PDO的配置：这是从站软件的核心，允许通过界面直接添加和管理PDO，由于PDO是从站最重要的功能，此功能将极大简化从站开发过程；
- 代码生成和XML的生成。
SOES的上位机软件
从站性能
从站响应时间
从站响应时间是从站的性能指标，指从发送一帧数据，经过每个从站ESC的处理，到主站接收到这帧数据的时间。从站响应时间主要由硬件和网络结构，数据传输量决定，具体地：
- 带宽：传输延时和带宽有关系，对于单个bit，从发送到确认，不考虑线路损耗的时间是（1/BandWidth）。假设EtherCAT网络的带宽是100Mbit/s，则每字节的传输延时是（1/100M）*8 = 80ns；
- 主站硬件延时：主站硬件同样存在延时，一般在几us左右；
- 主站软件延时：主站软件一般会带来几微秒的延时，取决于主站的性能；
- 从设备数量：每个MII/PHY接口的ESC会带来1us的延时，而EBUS接口的则只有0.3us；
扫一扫
2592
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
