此翻译主要是用翻译软件翻译，部分自己修改，若有不当之处，可以下方评论或私聊我提醒修改，若转载，请注明出处
本文是１－４章节。

1 The IgH EtherCAT Master

本章介绍有关EtherCAT主站的一些常规信息。

1.1功能摘要

下面的列表简要介绍了主要功能。
•设计为Linux 2.6 / 3.x的内核模块。
•根据IEC 61158-12 [2] [3]实施。
•带有支持EtherCAT的本地驱动程序，可用于几种常见的以太网芯片，以及用于Linux内核支持的所有芯片的通用驱动程序。
–本地驱动程序操作硬件时不会中断。
–可以轻松实现用于其他以太网硬件的本地驱动程序
使用主机提供的通用设备接口（请参见第4.6节）模块。
–对于任何其他硬件，可以使用通用驱动程序。它使用较低的Linux网络堆栈的各个层。
•主站模块支持并行运行的多个EtherCAT主站。
•主站代码通过其独立体系结构支持任何Linux实时扩展。
– RTAI [11]（包括通过RTDM的LXRT），ADEOS，RT-Preempt [12]，Xenomai（包括RTDM）等。
–即使没有实时扩展，它也可以很好地运行。
•想要使用EtherCAT的应用程序的通用“应用程序接口”功能（请参阅第3章）。
•引入了域，以允许将过程数据传输与不同的从属组和任务时段进行分组。
–处理具有不同任务期限的多个域。
–自动计算过程数据映射，FMMU和同步管理器每个域中的配置。
•通过多个有限状态机进行通信
–拓扑更改后自动进行总线扫描。
–运行期间的总线监视。
–在运行期间自动重新配置从站（例如在电源故障后）。
•分布式时钟支持（请参阅第3.5节）。
–通过应用程序接口配置从站的DC参数。
–分布式从属时钟与参考时钟的同步（偏移和漂移补偿）。
–参考时钟与主时钟的可选同步，或者相反。
•通过EtherCAT（CoE）的CANopen
– SDO上传，下载和信息服务。
–通过SDO进行从站配置。
–从用户空间和应用程序进行SDO访问。
•EtherCAT上的以太网（EoE）
–通过虚拟网络接口透明地使用EoE从站。
–本机支持交换式或路由式EoE网络体系结构。
•通过EtherCAT（VoE）特定于供应商
–通过API与供应商特定的邮箱协议进行通信。
•通过EtherCAT（FoE）进行文件访问
–通过命令行工具加载和存储文件。
–更新从站的固件很容易
•通过EtherCAT（SoE）的伺服配置文件
–根据IEC 61800-7 [16]实施。
–存储在启动期间写入从站的IDN配置。
–通过命令行工具访问IDN。
–在运行时通过用户空间库访问IDN。
•用户空间命令行工具“ ethercat”（请参阅第7.1节）–有关主站，从站，域和总线配置的详细信息。
–设置主机的调试级别。
–读/写别名地址。
–列出从站配置。
–查看过程数据。
– SDO下载/上传；列出SDO字典。
–通过FoE加载和存储文件。
– SoE IDN访问。
–访问从站寄存器。
–从站SII（EEPROM）访问。
–控制应用层状态。
–从现有从站生成从站描述XML和C代码。
•通过符合LSB的无缝系统集成。
–通过sysconfig文件配置主设备和网络设备。
–用于主控制的初始化脚本。
– systemd的服务文件。
•虚拟只读网络接口，用于监视和调试。

1.2许可证

该主代码是根据GNU通用公共许可证（GPL [4]）版本2的条款和条件发布的。邀请其他希望在Linux系统上使用EtherCAT的开发人员使用该主代码，甚至参与开发。 。
为了允许将用户空间应用程序与主应用程序接口静态链接（请参阅第3章），用户空间库（请参见第7.2节）已根据GNU通用公共许可协议（LGPL [5]）的条款和条件获得许可，2.1版本。

2 结构

EtherCAT主站已集成到Linux内核中。这是一个早期的设计决定，出于以下几个原因：
•内核代码具有明显更好的实时特性，延迟时间比用户空间代码短。可以预见，现场总线主站有很多周期性的工作要做。循环工作通常由内核内部的计时器中断触发。 当它驻留在内核空间中时，处理计时器中断的函数的执行延迟较小，因为不需要费时的上下文切换到用户空间进程。
•还可以预见，主代码必须直接与以太网硬件通信。 无论如何，这必须在内核中完成（通过网络设备驱动程序），这也是主代码位于内核空间中的另一个原因。
图2.1概述了主体系结构。
主环境的组件描述如下：
Master Module包含一个或多个EtherCAT主实例（请参见第2.1节），“设备接口”（请参见第4.6节）和“应用程序接口”（请参见第3章）的内核模块。
Device Modules支持EtherCAT的以太网设备驱动程序模块，通过设备接口将其设备提供给EtherCAT主站（请参见4.6节）。这些经过修改的网络驱动程序可以并行处理用于EtherCAT操作的网络设备和“常规”以太网设备。主站可以接受某个设备，然后能够发送和接收EtherCAT帧。主模块拒绝的以太网设备通常连接到内核的网络堆栈。
Application使用EtherCAT主站的程序（通常用于与EtherCAT从站循环交换过程数据）。这些程序不是EtherCAT主代码的一部分，而是必须由用户生成或编写。应用程序可以通过应用程序接口请求主服务器（请参见第3章）。如果成功，则可以控制主站：它可以提供总线配置并交换过程数据。应用程序可以是内核模块（直接使用内核应用程序接口）或用户空间程序，可以通过EtherCAT库（请参见7.2节）或RTDM库（请参见7.3节）使用应用程序接口。

2.1 主站模块

EtherCAT主站内核模块ec_master可以包含多个主站实例。 每个主机等待由其MAC地址标识的某些以太网设备。这些地址必须通过主设备（和可选的：备用设备）模块参数在模块加载时指定。要初始化的主实例的数量来自给定的MAC地址的数量。
以下命令使用一个主实例加载主模块，该主实例等待一个MAC地址为00：0E：0C：DA：A2：20的以太网设备。主机可以通过索引0访问。

# 	00：0E：0C：DA：A2：20

多个主机的MAC地址必须用逗号分隔：

# modprobe ec_master main_devices=00：0E：0C：DA：A2：20,00：e0：81：71：d5：1c

这两个主机可以分别通过其索引0和1进行寻址（见图2.2）。
应用程序接口的ecrt_master_request（）函数（请参阅第3章）和ethercat命令行工具的–master选项（请参见7.1节）需要master索引，该索引默认为0。

调试级别(Debug Level)主模块还具有参数调试级别，可为所有主模块设置初始调试级别（另请参见第7.1.6小节）
初始化脚本(Init Script)在大多数情况下，不需要手动加载主模块和以太网驱动程序模块。 有一个可用的初始化脚本，因此可以将主服务器作为服务启动（请参阅第7.4节）。 对于由systemd [7]管理的系统，还有一个服务文件可用。
Syslog主模块将有关其状态和事件的信息输出到内核环形缓冲区。 这些也最终出现在系统日志中。 上面的模块加载命令应导致以下消息：

主站日志输出带有EtherCAT前缀，这使搜索日志更加容易。

2.2 主站阶段

主站模块（请参阅第2.1节）提供的每个EtherCAT主站都经历多个阶段（请参见图2.3）：

Orphaned phase：当主机仍在等待其以太网设备连接时，此模式才会生效。 在此之前，无法进行总线通讯。
Idle phase：当主机已接受所有必需的以太网设备但尚未被任何应用程序请求时，此命令才生效。 主机运行其状态机（请参阅第5.3节），该状态机自动在总线上扫描从机，并从用户空间接口执行挂起的操作（例如SDO访问）。可以使用命令行工具访问总线，但是由于缺少总线配置，因此没有过程数据交换。
Operation phase：可以通过提供总线配置并交换过程数据的应用程序请求主机。

2.3过程数据

本节将介绍一些术语和构想，说明主服务器如何处理过程数据。
过程数据映像（Process Data Image）从站通过显示主要的“过程数据对象”（PDO）提供其输入和输出。可以通过从EEPROM中读取从站的TxPDO和RxPDO SII类别（对于固定PDO）来确定可用的PDO，或者通过读取适当的CoE对象（请参见6.2节）来确定。该应用程序可以注册PDO的条目，以便在循环操作期间进行交换。 所有已注册的PDO条目的总和定义了“过程数据映像”，它通过数据报与引入了“逻辑”内存访问（例如LWR，LRD或LRW）的数据报进行交换。[详细参见5.4]
过程数据域（Process Data Domains）通过创建允许分组PDO交换的所谓“域”，可以轻松管理过程数据映像。他们还负责管理交换PDO所需的数据报结构。域对于过程数据交换是必不可少的，因此必须至少有一个。引入它们的原因如下：
•数据报的最大大小由于以太网帧的大小而受到限制：最大数据大小是以太网数据字段的大小减去EtherCAT帧头，EtherCAT数据报头和EtherCAT数据报页脚：1500 -2-12-2 = 1484个八位位组。如果过程数据映像的大小超过此限制，则必须发送多个帧，并且必须对映像进行分区以使用多个数据报。域自动进行管理。
•并非每个PDO都必须以相同的频率进行交换：PDO的值会随时间缓慢变化（例如温度值），因此以高频率进行交换会浪费总线带宽。因此，可以创建多个域，以将不同的PDO分组，从而允许单独交换。
域的数量没有上限，但是每个域在每个涉及的从站中都占用一个FMMU，因此，最大的域数实际上受从站的限制。
FMMU配置（FMMU Configuration）应用程序可以注册PDO条目以进行交换。每个PDO条目及其父PDO都是从站物理内存中存储区域的一部分，该区域由同步管理器保护以进行同步访问。为了使同步管理器对访问其内存的数据报做出反应，有必要访问同步管理器覆盖的最后一个字节。否则，同步管理器将不会对数据报做出反应，也不会交换任何数据。这就是为什么必须将整个同步存储区包括在过程数据映像中：例如，如果注册了从站的某个PDO条目以与某个域进行交换，则将配置一个FMMU来映射完整的同步管理器。受保护的内存，则PDO条目将驻留在其中。如果已注册同一从站的第二个PDO条目以在同一域内进行过程数据交换，并且它与第一个PDO条目位于相同的受同步管理器保护的内存中，则FMMU配置不会更改，因为所需的内存已经是域的过程数据映像的一部分。如果第二个PDO条目将属于另一个同步管理器保护的区域，则该完整区域也将包含在域过程数据映像中。图2.4概述了FMMU如何配置为将物理内存映射到逻辑过程数据映像。

3.应用层接口

应用程序接口为应用程序提供访问EtherCAT主站的功能和数据结构。 接口的完整文档作为Doxygen [13]注释包含在头文件include/ecrt.h中。 它可以直接从文件注释中读取，也可以作为更舒适的HTML文档读取。 HTML生成在第9.3节中描述。
以下各节介绍了应用程序界面的一般说明。
每个应用程序都应分两个步骤使用主服务器：
配置（Configuration）请求主服务器并应用配置。 例如，创建域，配置从站并注册PDO条目（请参阅第3.1节）。
操作运行（Operation）循环代码并交换过程数据（请参阅第3.2节）。
示例应用程序（Example Applications）主代码的examples /子目录中有一些示例应用程序。 它们记录在源代码中。

3.1主站配置

总线配置通过应用程序接口提供。 图3.1概述了可以由应用程序配置的对象。

3.1.1从站配置

该应用程序必须告知主机有关预期的总线拓扑。 这可以通过创建“从站配置”来完成。 从站配置可以视为预期的从站。创建从站配置后，应用程序将提供总线位置（请参见下文），供应商ID和产品代码。
应用总线配置后，主服务器将检查在给定位置是否存在具有给定供应商ID和产品代码的从属设备。在这种情况下，从站配置将“附加”到总线上的实际从站，并且根据应用程序提供的设置来配置从站。可以通过应用程序界面或通过命令行工具查询从站配置的状态（请参见第7.1.3节）。
从站位置：必须将从站位置指定为“别名”和“位置”的元组。 这允许通过绝对总线位置或存储的称为“别名”的标识符或二者的混合来寻址从站。 别名是存储在从站EEPROM中的16位值。可以通过命令行工具对其进行修改（请参见7.1.2小节）。 表3.1显示了如何解释这些值。

图3.2显示了如何附加从站配置的示例。 一些配置已附加，而其他配置仍保持分离。 下面的列表给出了从顶级从站配置开始的原因。
1.别名为零意味着使用简单的位置寻址。从站1存在，并且供应商ID和产品代码与期望值匹配。
2.尽管找到了位置为0的从站，但产品代码不匹配，因此未附加组态。
3.别名非零，因此使用别名寻址。从站2是第一个别名为0x2000的从站。由于位置值为零，因此使用相同的从站。
4.没有具有给定别名的从站，因此无法附加配置。
5.从站2再次是别名为0x2000的第一个从站，但是位置现在为1，因此连接了从站3。 如果主源配置了–enable-wildcards，则0xffffffff会匹配每个供应商ID和/或产品代码。

3.2循环运行

要进入循环操作模式，必须“激活”主站以计算过程数据映像并首次应用总线配置。 激活后，应用程序负责发送和接收帧。 激活后无法更改配置。

3.3 VoE处理程序

在配置阶段，应用程序可以为6.3节中描述的VoE邮箱协议创建处理程序。 一个VoE处理程序始终属于某个从属配置，因此创建功能是从属配置的一种方法。
VoE处理程序：管理VoE数据和用于发送和接收VoE消息的数据报。是包含传输VoE消息所需的状态机。
VoE状态机一次只能处理一个操作。结果，可以在时间1发出读取或写入操作。启动该操作后，必须循环执行该处理程序，直到完成为止。之后，可以检索操作结果。
VoE处理程序具有自己的数据报结构，该数据报结构被标记为在每个执行步骤之后都可以交换。因此，应用程序可以确定在发送相应的EtherCAT帧之前要执行多少个处理程序。
有关使用VoE处理程序的更多信息，请参见应用程序接口功能的文档以及examples /目录中提供的示例应用程序。

3.4并发主站访问

在某些情况下，多个实例使用一个主设备，例如，当应用程序进行循环过程数据交换时，并且有支持EoE的从设备需要与内核交换以太网数据（请参见6.1节）。因此，主站是共享资源，必须按顺序对它进行访问。通常，通过使用信号量锁定或其他保护关键部分的方法来完成此操作。
主站本身不能提供锁定机制，因为它没有机会知道适当的锁定类型。例如，如果应用程序在内核空间中并使用RTAI功能，那么普通的内核信号量将不够。为此，做出了一个重要的设计决策：保留主站的应用程序必须拥有全部控制权，因此它必须负责提供适当的锁定机制。如果另一个实例想要访问主站，则它必须通过回调请求总线访问，而回调必须由应用程序提供。此外，如果应用程序认为此主站现在很尴尬，则可以拒绝其访问。
图3.3示例显示了两个进程如何共享一个主站：应用程序的循环任务使用主站进行进程数据交换，而主站内部的EoE进程使用它与支持EoE的从站进行通信。两者都必须不时访问总线，但是EoE进程通过“询问”应用程序对其进行总线访问来实现此目的。这样，应用程序可以使用适当的锁定机制来避免同时访问总线。有关如何使用这些回调的信息，请参见应用程序接口文档（第3章）。

3.5分布式时钟

从1.5版开始，主机支持EtherCAT的“分布式时钟”功能。 可以将总线上的从时钟同步到“参考时钟”（这是具有DC支持的第一个从时钟的本地时钟），并且可以将参考时钟同步到“主时钟”（这是DC的本地时钟）。 总线上的所有其他时钟（参考时钟之后）均被视为“从时钟”（见图3.4）。

Local Clocks：任何支持DC的EtherCAT从站都有一个纳秒级分辨率的本地时钟寄存器。 如果从站通电，则时钟从零开始，这意味着从站在不同时间通电时，其时钟将具有不同的值。 这些“偏移”必须通过分布式时钟机制进行补偿。 另一方面，由于使用的夸脱单位具有自然的频率偏差，因此时钟的运行速度并不完全相同。这种偏差通常很小，但是在更长的时间内，误差会累积，本地时钟之间的差异也会增大。该时钟“漂移”也必须通过直流机制进行补偿。
Application Time：总线的通用时基必须由应用程序提供。使用该应用时间tapp：
1.配置从站的时钟偏移（请参见下文），
2.对从站的启动时间进行编程以生成同步脉冲（请参见下文）。
3.使参考时钟与主时钟同步（可选）。
Offset Compensation：为了进行偏移补偿，每个从机都提供一个“系统时间偏移”寄存器toff，该寄存器与内部时钟值tint相加以获得“系统时间”tsys：

主机读取两个寄存器的值，以某种方式计算新的系统时间偏移，以使所得的系统时间与主机的应用时间tapp相匹配：

由于寄存器的读写时间不同而产生的较小的时间偏移误差将通过漂移补偿得到补偿。
Drift Compensation：由于每个具有DC功能的从站都有特殊的机制，因此可以进行漂移补偿：对“系统时间”寄存器的写操作将使内部时间控制回路将写时间（减去编程的传输延迟，请参见下文）进行比较。当前系统时间。计算出的时间误差将用作时间控制器的输入，该时间控制器将根据误差的符号将本地时钟速度调整为更快或更慢。
Transmission Delays：以太网帧从从站到从站需要少量时间。 由此产生的传输延迟时间会累积在总线上，并可能达到微秒级，因此必须在漂移补偿期间加以考虑。 支持DC的EtherCAT从站提供了一种测量传输延迟的机制：对于四个从端口，每个端口都有一个接收时间寄存器。 一旦在相应端口上接收到帧，对端口0的接收时间寄存器的写操作就开始测量，并且当前系统时间被锁存并存储在接收时间寄存器中。 主机可以读取相对接收时间，然后（使用其对总线拓扑的了解）计算从机之间的时间延迟，最后计算从参考时钟到每个从机的时间延迟。 这些值被编程到从站的传输延迟寄存器中。这样，漂移补偿可以达到纳秒级同步。
Checking Synchrony：具有DC功能的从机在地址0x092c处提供32位“系统时间差”寄存器，最后一次漂移补偿的系统时间差以纳秒分辨率和符号倍数编码3进行存储。 要检查总线同步，还可以通过命令行工具循环读取系统时差寄存器（请参见小节7.1.14）：

$ watch -n0 “ethercat reg_read -p4 -tsm32 0x92c”

Sync Signals：同步时钟只是总线上同步事件的前提条件。 每个具有DC支持的从站都提供两个“同步信号”，可对其进行编程以创建事件，例如，这些事件将导致从站应用程序在特定时间锁存其输入。同步事件可以一次生成，也可以循环生成，具体取决于对从站应用程序有意义。 对同步信号进行编程只需设置所谓的“ AssignActivate”字样以及同步信号的周期和移位时间即可。 AssignActivate字是从站特定的，必须从XML从站描述文件（设备→Dc）中获取，在该处也可以找到典型的同步信号配置“ OpModes”。

4.以太网设备

EtherCAT协议基于以太网标准，因此主站依靠标准以太网硬件与总线进行通信。
术语设备被用作以太网网络接口硬件的同义词。
Native Ethernet Device Drivers：有一些本机设备驱动程序模块（请参见第4.2节）处理以太网硬件，主机可以使用该模块连接到EtherCAT总线。他们通过设备接口将以太网硬件提供给主模块（请参阅第4.6节），并且必须能够使用内核的网络堆栈为EtherCAT（实时）操作或“正常”操作准备以太网设备。这种方法的优点是主机可以直接在硬件上直接运行，从而实现高性能。 缺点是原始以太网驱动程序必须具有支持EtherCAT的版本。
Generic Ethernet Device Driver：从主版本1.5开始，有一个通用的以太网设备驱动程序模块（请参阅第4.3节），该模块使用网络堆栈的下层连接到硬件。优点是，可以将任意以太网硬件用于EtherCAT操作，而与实际的硬件驱动程序无关（因此，所有Linux以太网驱动程序都无需修改即可支持）。缺点是该方法不支持RTAI等实时扩展，因为已解决了Linux网络堆栈。此外，由于以太网帧数据必须遍历网络堆栈，因此性能比本地方法稍差。

4.1网络驱动程序基础

EtherCAT依赖于以太网硬件，并且主站需要物理以太网设备才能与总线进行通信。 因此，有必要了解Linux如何分别处理网络设备及其驱动程序。
Tasks of a Network Driver：网络设备驱动程序通常处理OSI模型的下两层，即物理层和数据链路层。 网络设备本身就可以处理物理层问题：物理层协议描述了它代表连接到介质以及以某种方式发送和接收数据的硬件。 网络设备驱动程序负责从内核的网络堆栈中获取数据，并将其转发到进行物理传输的硬件。如果数据分别由硬件接收，则通知驱动程序（通常通过中断），并且必须从硬件存储器读取数据并将其转发到网络堆栈。网络设备驱动程序还必须处理一些其他任务，包括队列控制，统计信息和与设备相关的功能。
Driver Startup：通常，驱动程序会在模块加载时搜索兼容的设备。对于PCI驱动程序，这是通过扫描PCI总线并检查已知设备ID来完成的。如果找到设备，则会分配数据结构并使该设备投入运行。
Interrupt Operation：网络设备通常提供硬件中断，该硬件中断用于分别通知驱动程序收到的帧以及传输成功或发生错误。驱动程序必须注册一个中断服务程序（ISR），该程序每次在硬件发出此类事件信号时执行。如果中断是由自己的设备抛出的（多个设备可以共享一个硬件中断），则必须通过读取设备的中断寄存器来确定中断的原因。例如，如果设置了接收帧的标志，则必须将帧数据从硬件复制到内核内存，然后传递到网络堆栈。
The net_devices Structure：驱动程序为每个设备注册一个net_device结构，以与网络堆栈进行通信并创建“网络接口”。如果是以太网驱动程序，则该接口显示为ethX，其中X是内核在注册时分配的数字。net_device结构通过几个回调接收事件（从用户空间或从网络堆栈），这些回调必须在注册之前进行设置。并非每个回调都是强制性的，但是为了进行合理的操作，无论如何都需要以下回调：
open()：例如，在必须从用户空间建立命令ip link ethX之后，必须启动网络通信时调用此函数。帧接收必须由驱动程序启用。
stop()：该回调的目的是“关闭”设备，使硬件停止接收帧。
hard_start_xmit()：对于必须传输的每个帧，都会调用此函数。网络堆栈会将帧作为指向sk_buff结构（“套接字缓冲区”，请参见下文）的指针传递，该结构必须在发送后释放。
get_stats()：此调用必须返回指向设备的net_device_stats结构的指针，该结构必须永久填充帧统计信息。这意味着，每当接收，发送帧或发生错误时，都必须增加此结构中的适当计数器。
实际注册是通过register_netdev（）调用完成的，注销是通过unregister_netdev（）完成的。
The netif Interface：方向接口→网络堆栈中的所有其他通信都是通过netif _ *（）调用完成的。 例如，成功打开设备后，必须通知网络堆栈，网络堆栈现在可以将帧传递到接口。 这是通过调用netif_start_queue（）完成的。调用之后，网络堆栈可以调用hard_start_xmit（）回调。此外，网络驱动程序通常管理帧传输队列。如果已填满，则必须告知网络堆栈暂时停止传递其他帧。调用netif_stop_queue（）会发生这种情况。如果已经发送了一些帧，并且又有足够的空间来排队新帧，则可以通过netif_wake_queue（）进行通知。另一个重要的调用是netif_receive_skb（）1：它将帧传递给网络堆栈，该帧刚被设备接收到。为此，帧数据必须包含在所谓的“套接字缓冲区”中（请参见下文）。
Socket Buffers：套接字缓冲区是整个网络堆栈的基本数据类型。它们充当网络数据的容器，并且能够快速添加数据标题和页脚，或再次剥离它们。因此，套接字缓冲区由分配的缓冲区和几个标记缓冲区的指针组成，这些指针标记缓冲区的开始（head），数据的开始（data），数据的结束（tail）和缓冲区的结束（end）。另外，套接字缓冲区保存网络标头信息和（在接收到数据的情况下）指向net_device的指针，该信息将在其上被接收。存在创建套接字缓冲区（dev_alloc_skb（）），从前面（skb_push（））或后面（skb_put（））添加数据，从前面（skb_pull（））或后面（skb_trim（））删除数据的函数，或者删除缓冲区（kfree_skb（））。 套接字缓冲区从一层传递到另一层，并由上次使用它的层释放。在发送的情况下，必须由网络驱动程序完成释放。

4.2本地EtherCAT设备驱动程序

与具有EtherCAT功能的本地以太网驱动程序一起使用时，有一些要求适用于以太网硬件。
Dedicated Hardware：出于性能和实时目的，EtherCAT主站需要直接和排他访问以太网硬件。 这意味着网络设备一定不能像往常那样连接到内核的网络堆栈，因为内核会尝试将其用作普通的以太网设备。
Interrupt-less Operation：EtherCAT帧通过逻辑EtherCAT环行进，然后发送回主站。 通信是高度确定性的：发送帧并将在固定时间后再次接收，因此无需通知驱动程序有关帧接收的信息：主设备可以代替硬件向硬件查询接收到的帧（如果它希望已接收到帧） 收到。
图4.1显示了有和没有中断的循环帧发送和接收的两个工作流程。
在左侧的工作流“中断操作”中，首先处理来自最后一个周期的数据，然后将新的帧与新的数据报组装在一起，然后将其发送。循环工作现在已经完成。稍后，当硬件再次接收到该帧时，将触发中断并执行ISR。 ISR将从硬件中获取帧数据并启动帧剖析：将处理数据报，以便准备好在下一个周期中进行处理。
在正确的工作流程“无中断操作”中，没有启用硬件中断。相反，硬件将通过执行ISR由主机轮询。如果在此期间已接收到帧，则将其解剖。现在的情况与左工作流程开始时的情况相同：处理接收到的数据，并组装并发送新的帧。在剩余的周期中，没有任何事情要做。
无中断操作是理想的，因为硬件中断不利于改善驾驶员的实时行为：不确定的事件会增加抖动。此外，如果使用实时扩展（如RTAI），则必须付出一些额外的努力来确定中断的优先级。

Ethernet and EtherCAT Devices：另一个问题在于Linux处理相同类型设备的方式。 例如，PCI驱动程序扫描PCI总线以查找其可以处理的设备。 然后，它会将自己注册为找到的所有设备的负责任驱动程序。问题是，无法告知未修改的驱动程序忽略设备，因为该设备稍后将用于EtherCAT。必须有一种方法可以处理多个相同类型的设备，其中一个设备保留用于EtherCAT，而另一个设备则视为普通的以太网设备。
出于所有这些原因，作者认为唯一可接受的解决方案是修改标准以太网驱动程序，使其保持其正常功能，但具有将一个或多个设备视为具有EtherCAT功能的能力。
以下是此解决方案的优点：
•无需告诉标准驱动程序忽略某些设备。
•一个用于EtherCAT和非EtherCAT设备的网络驱动程序。
•以前的开发人员已经解决了，无需从头开始实施网络驱动程序而不会遇到问题。
选择的方法具有以下缺点：
•修改后的驱动程序变得更加复杂，因为它必须处理EtherCAT和非EtherCAT设备。
•驱动程序代码中的许多其他区分大小写。
•必须不时将标准驱动程序上的更改和错误修复移植到支持Ether CAT的版本。

4.3通用EtherCAT设备驱动程序

由于存在使完整的Linux内核实现实时操作的方法[12]，因此可以在不具有EtherCAT功能的以太网设备驱动程序的本地实现的情况下进行操作，而是使用Linux网络堆栈。图2.1显示了“通用以太网驱动程序模块”，该模块通过网络堆栈连接到本地以太网设备。内核模块名为ec_generic，可以在主模块之后加载，就像支持EtherCAT的本地以太网驱动程序一样。
通用设备驱动程序会在网络堆栈中扫描以太网设备驱动程序已注册的接口。它为EtherCAT主站提供了所有可能的设备。如果主机接受设备，则通用驱动程序会创建一个数据包套接字（请参见man 7数据包），其socket_type设置为SOCK_RAW，并绑定到该设备。 然后，设备接口的所有功能（请参见4.6节）将在该插槽上运行。
以下是此解决方案的优点：
•EtherCAT可以使用Linux以太网驱动程序涵盖的任何以太网硬件。
•无需修改实际的以太网驱动程序。
通用方法具有以下缺点：
•性能比本地方法差一些，因为帧数据必须遍历网络堆栈的较低层。
•不能将RTAI之类的内核内实时扩展与通用驱动程序一起使用，因为网络堆栈代码使用动态内存分配等功能，这可能导致系统在实时上下文中冻结。
Device Activation：为了通过套接字发送和接收帧，必须激活链接到该套接字的以太网设备，否则所有帧将被拒绝。 必须在加载主模块之前进行激活，激活可以通过以下几种方式进行：
•A-hoc使用命令ip link将dev ethX up设置为up（或将较旧的ifconfig ethX up设置为），
•根据发行版本进行配置，例如在openSUSE和其他版本中使用ifcfg文件（/ etc / sysconfig / network / ifcfg-ethX）。 如果EtherCAT主站应在系统启动时启动，则这是更好的选择。 由于仅应激活以太网设备，而不能分配IP地址等，因此使用STARTMODE = auto作为配置就足够了。

4.4提供以太网设备

加载主模块后，必须加载其他模块才能将设备提供给主模块（请参见第4.6节）。 主模块知道要从模块参数中选择的设备（请参见第2.1节）。 如果使用init脚本启动主服务器，则可以在sysconfig文件中指定要使用的驱动程序和设备（请参见7.4.2小节）。
提供以太网设备的模块可以是
•具有本地EtherCAT功能的网络驱动程序模块（请参阅第4.2节）或
•通用EtherCAT设备驱动程序模块（请参阅第4.3节）。

4.5冗余

冗余总线操作意味着从主站到从站之间有多个以太网连接。过程数据交换数据报在每个主链路上发送，因此即使总线之间的某个地方断开连接，交换仍将完成。
完全冗余总线操作的前提条件是，至少一个主链路可以访问每个从站。在这种情况下，单个连接故障（即电缆断开）将永远不会导致不完整的过程数据。用两个以太网设备不能处理双重故障。
在配置时使用–with-devices开关配置冗余（请参见第9章），并使用ec_master内核模块的backup_devices参数（请参见第2.1节）或（sys-）config文件中的相应变量MASTERx_BACKUP（见7.4.2小节）。
在任何以太网链路上更改拓扑后，都会执行总线扫描。应用程序界面（请参见第3章）和命令行工具（请参见第7.1节）都具有查询冗余操作状态的方法。

4.6 EtherCAT设备接口

为了了解主模块的这一节（第2.1节），必须预料一下，网络设备驱动程序模块才能将设备连接到特定的EtherCAT主站。
主模块为网络设备驱动程序提供“设备接口”。 要使用此接口，网络设备驱动程序模块必须包含EtherCAT主代码随附的头文件device / ecdev.h。 该头提供了EtherCAT设备的功能接口。 设备接口的所有功能均以前缀ecdev命名。
设备接口的文档可以在头文件或接口文档的相应模块中找到（有关生成说明，请参见9.3节）。

4.7修补本机网络驱动程序

本节将介绍如何使用本机方法（参见第4.2节）使标准的以太网驱动程序具有EtherCAT功能。不幸的是，没有标准的程序可以使以太网驱动程序与EtherCAT主站一起使用，但是有一些通用技术。
1.第一个简单的规则是，必须避免对所有EtherCAT设备进行netif _ *（）调用。如前所述，EtherCAT设备没有与网络堆栈的连接，因此不得调用其接口功能。
2.另一个重要的事情是，EtherCAT设备应无中断运行。因此，也必须避免任何在硬件级别注册中断处理程序和启用中断的调用。
3.主机不为每个发送操作使用新的套接字缓冲区：相反，在主站初始化阶段创建一个固定的缓冲区。该套接字缓冲区在每次发送操作时都填充有一个EtherCAT帧，并传递给hard_start_xmit（）回调。为此，有必要确保网络驱动程序不像往常那样释放套接字缓冲区。
以太网驱动程序通常处理多个以太网设备，每个设备由一个带有priv_data字段的net_device结构描述，以将依赖于驱动程序的数据附加到该结构。 为了区分普通以太网设备和EtherCAT主设备使用的设备，可以使用指针扩展驱动程序使用的私有数据结构，该指针指向ecdev_offer（）返回的ec_device_t对象（请参见4.6节）（如果使用了设备） 由一个主，否则为零。
RealTek RTL-8139快速以太网驱动程序是“简单”以太网驱动程序，可以作为修补新驱动程序的示例。 可以通过在文件devices / 8139too-2.6.24-ethercat.c中搜索字符串“ ecdev”找到有趣的部分。