EtherCAT从站同步实战：从PDI配置到SYNC/Latch信号全解析

做EtherCAT从站有一类坑特别隐蔽——它不是跑不起来，而是跑起来之后，你用示波器一看，该同步的地方全在抖。PLC那边觉得网络通了，报文也在收，但一到多轴联动或者高精度采集，误差就肉眼可见。前阵子我把PDI接口和同步采样完整捋了一遍，从SYNC0跳线到Latch时间戳全部打通，这篇文章就把整个过程写下来，包括当初踩过的坑和最后的经验总结。

文章内容主要围绕EtherCAT从站控制器的PDI接口、分布式时钟同步以及Sync/Latch信号的实际应用展开，适合正在调从站固件、准备搞多轴同步或高精度采集的工程师。不管你是用ET1100、AX58100这类独立ESC芯片，还是用LAN9252加MCU的方案，底层逻辑都是一样的，把这套机制看懂了，后面换芯片就是换个寄存器地址的事。

1. 先把底层逻辑讲明白：ESC是怎么“卡点”的

很多人拿到从站参考代码第一件事就是查寄存器表，哪个地址配SYNC0、哪个地址读Latch，抄完能跑就不管了。结果一旦出问题就懵了。我说句实在话，EtherCAT同步这件事，真正值钱的是底层那套时序机制，而不是那几行寄存器操作代码。所以先花点篇幅把原理讲透，后面配起来你才能知道自己在干什么。

1.1 PDI：主控和ESC之间那道门

EtherCAT从站有两张嘴。一张嘴面对主站，走的是EtherCAT报文，这是ESC芯片干的活；另一张嘴面对本地微控制器，也就是从站主控，这叫PDI（Process Data Interface，过程数据接口）。

PDI的类型一般有SPI从站、8位并行、16位并行、寄存器模式等。你可以把ESC理解成一个带硬件邮箱的收发室：主站的报文到了，收发室先把数据整理好，再通过PDI这扇门交给你的MCU去处理。MCU想往主站发数据，也是通过这扇门递出去。

这里有个关键点：EtherCAT的实时性体现在ESC硬件层面，也就是报文处理和分布式时钟完全由ESC内部硬件完成，MCU参与得越少越好。PDI接口的作用就是“批量搬运”，把输入输出数据在ESC和MCU之间搬来搬去，千万不要让MCU在数据通路里面做太多判断和转发，否则延迟和抖动立刻就会上来。

所以配置PDI的第一步不是查代码，而是想清楚你的应用需要哪种PDI。后面我会展开讲。

1.2 DC分布式时钟：所有从站对同一个表

分布式时钟（Distributed Clock，DC）是EtherCAT同步的核心机制。主站会选定一个参考时钟从站，通常是第一个支持DC的从站，然后通过报文把系统时间广播给所有从站，再不断测量和补偿每个从站的本地时钟偏移，最终让所有从站在同一个时间基准上运行。

你可以把DC理解成每个从站手腕上都戴了一块表，主站每天对表，同时针对每块表的走时误差做修正。但不同的是，EtherCAT的“对表”是硬件自动完成的，主站通过ARMW（Auto-Read-Multiple-Write，自动读多写）指令周期性校正，从站在收到对应帧时捕获接收时间戳，并计算出传输延迟和漂移量，写入ESC内部的时钟补偿寄存器。

这个机制决定了：只要主站开启了DC，从站本地的SYNC0/SYNC1信号就不会依赖报文到达的瞬时时刻，而是依赖统一的DC系统时间。这句话一定要记住，因为很多同步抖动问题，归根结底是有人绕过了DC时间直接拿报文中断当同步信号用，那抖动不大才怪。

1.3 Sync和Latch：一根针管输出，一个记录仪输入

Sync和Latch是ESC上两个方向的特殊信号。

SYNC0和SYNC1是ESC根据DC系统时间产生的输出信号。你可以配置它们的周期、起始时间，ESC到了设定时刻就会拉高或翻转这些引脚。MCU通常把SYNC0接到中断输入，在精确时间点触发ADC采样、PWM更新、IO输出切换，以及执行其他需要全部从站同步动作的任务。

Latch方向和Sync相反，它是输入信号，用来“捕获时间戳”。外部信号来了，比如编码器Z相脉冲、位置开关跳变、故障信号上升沿，ESC硬件会立刻把当时的DC系统时间锁存到寄存器里。MCU后续读取这个时间戳，就能知道事件到底发生在哪个精确时刻，而不是等中断处理完才打软件时间戳。软件时间戳的延迟可能是微秒到几十微秒，硬件锁存是纳秒级完成，精度差着几个数量级。

SYNC负责“定时输出”，Latch负责“定时记录”，两者配合起来，你就能在一个统一的时间轴上完成激励与测量的对齐。这就是EtherCAT做高精度同步的基础。

2. 从零到一：PDI接口配置完整流程

PDI配置看似简单，实际上特别容易出幺蛾子。我第一次调的时候，光SPI通信就折腾了半天，后来发现是EEPROM里的PDI配置和代码里不一致，ESC一开始就没按我预想的模式工作。这一节我把完整流程拆开讲，包括选型、接线、初始化和中断配置。

2.1 选哪种PDI模式：SPI还是并行

我见过很多产品最终选了SPI模式，原因很直接：占用IO少，接线简单，PCB面积也小。ET1100、AX58100这类ESC芯片的SPI从站接口，在几MHz到十几MHz的时钟下，每个周期搬运几十字节的过程数据绰绰有余，非常适合大多数伺服、IO、采集模块。

16位并行模式适合高速大容量数据交换的场景，比如高端伺服驱动器或者需要大量参数上传下载的设备。但并行模式占用的MCU管脚非常多，而且对PCB布线要求更高，线不短了有时序问题，开发调试难度也上去了。

寄存器模式则不太适合作为主工作模式，更多用于调试或者特殊访问场景。

以下是我个人对PDI选择的建议汇总：

还有一个很多人忽略的点：PDI模式是存在EEPROM里的配置项，而不是光在MCU代码里定义。上电后，ESC会读取EEPROM中的PDI配置，然后决定引脚功能。如果你的代码里用的是SPI，而EEPROM里配的是并行模式，那么ESC引脚行为会变得很怪，通信根本建立不起来。所以我强烈建议，第一次调板子，先用SSC工具或者官方配置工具把EEPROM完整烧录一遍，确认PDI配置正确后再动代码。

2.2 硬件接线的3个关键点

如果你选了SPI模式，那么硬件上需要注意下面几个点。

第一，SCLK频率不要一上来就拉满。ET1100和AX58100在手册里给出的最高SPI时钟，通常是在理想电气环境下测出来的。实际板子上，如果走线过长、没有包地或者电源纹波大，速度可能就要打折。我一般先降到2~4MHz跑通基本读写，再慢慢提上去，看ESC访问有没有偶发错误。

第二，片选信号SCS必须干净。SPI从站的时序对片选要求比较严格，尤其是命令结束后的片选释放时机。MCU的SPI外设在连续传输多个字节时，片选容易出现毛刺，最好用GPIO手动控制SCS，把命令阶段和数据阶段包在一个完整的低电平窗口里，减少误触发的概率。

第三，中断引脚不要偷懒。SYNC0、SYNC1以及ESC的PDI中断请求引脚，尽量接到MCU的中断引脚上，不要在外部并到一起再通过查询方式处理。同步中断本身要的就是优先级和确定性，如果靠轮询，抖动会明显增大，等于把硬件能力白白浪费了。

2.3 初始化流程：从EEPROM到中断使能

PDI初始化有个固定的先后顺序，我把它列出来，每一步都配上原因。

第一步，复位ESC。通过复位引脚或者写控制寄存器，让ESC回到初始状态，此时EEPROM加载完成，PDI模式字段已经生效。

第二步，读取EEPROM中的配置。重点看PDI配置寄存器0x0140附近的字段，确认SPI模式还是并行模式，以及同步中断的极性等。如果发现和预期不符，立刻停止后续操作，先修EEPROM。

第三步，配置站地址。如果主站没启用“通过地址别名方式配置”，从站需要从EEPROM或者外部拨码读取站地址，写入0x0120寄存器。注意这个过程要在ESC进入OP状态之前完成，否则地址无效。

第四步，配置PDI控制寄存器0x0150，使能需要的同步中断源。这里可以设置SYNC0中断的输出极性，比如高电平有效还是低电平有效，以及中断是否被锁存。

第五步，初始化MCU侧外设。如果SPI模式，配置MCU为SPI从机模式；如果是并行模式，配置对应的并行接口时序。重点确认MCU的SPI引脚功能复用、DMA链路和中断入口都设置正确。

第六步，使能ESC中断。不同型号的ESC中断事件寄存器可能不同，但思路是统一的：把需要的中断事件源（SYNC0、SYNC1、PDI请求等）在中断使能寄存器里打开。之后MCU就能收到ESC发出的同步中断请求。

这套流程看起来简单，但每一步都值得花时间验证，尤其是前两步。很多从站跑不稳定，问题不是出在应用代码，而是EEPROM配置和PDI初始化在打架。

3. 同步采样实战：让ADC/PWM在同一个节拍上动

同步采样是EtherCAT从站最典型的应用场景之一：多个从站在同一时刻采集模拟量，或者同一时刻更新PWM输出。这里的“同一时刻”指的是DC系统时间轴上的同一时刻，而不是“大家收到处理数据帧后赶紧干活”的那个时刻。后者只要网络稍有抖动，各从站动作就会出现偏差，系统精度马上崩掉。

3.1 SYNC0周期怎么设

主站在配置DC时，会给所有从站下发周期和起始时间。从站自身也要把对应的同步单元寄存器配好。

一般做法是把SYNC0周期设成和主站任务周期一致。比如主站运行周期是1ms，那SYNC0周期设置成1ms；如果主站是125us级别的快速任务，那就设成125us。注意SYNC0周期寄存器通常是32位的，单位是ns。1ms就是1,000,000，这个换算很容易被忽略，我犯过好几次只写1000的低级错误，结果同步周期变成微秒级，中断风暴直接把MCU跑死了。

SYNC1通常作为辅助事件使用。有的应用会在SYNC0触发采样后，延迟一小段时间用SYNC1触发PWM更新，这样可以错开模拟量采样和功率开关切换的干扰。但大多数系统只用SYNC0就够了，SYNC1留作备用或者特殊时序需求。

配置SYNC周期后，不要忘记使能同步单元。ET1100/AX58100这类ESC有SYNC激活寄存器，只有置位后SYNC信号才会按照DC时间产生。如果主站已经开启了DC，但你没有打开SYNC激活，那么中断永远不会来，这时你排查的方向应该往这个寄存器上靠，而不是去查SPI通信。

3.2 中断里到底该干什么

SYNC0中断服务函数是同步采样的核心。我的经验是，中断服务函数只做必须在这个时间点做的事情，其他能推迟的一律推迟。

以ADC采样为例，在SYNC0中断里你要做的是：

• 关闭当前中断或者标记中断已响应，清掉ESC侧对应的事件标志；
• 触发ADC采样，或者读取已由硬件定时器触发的ADC结果；
• 更新需要同步输出的PWM比较寄存器；
• 如果有数据需要上报主站，把这些数据写入PDO缓存，交给主循环或者周期任务去转发。

代码结构大致是这样的：

void SYNC0_IRQHandler(void) { // 1. 清除ESC中断事件标志，避免重复进入 ESC_INT_Event = ESC_INT_EVENT_SYNC0; // 2. 启动ADC采样（如果支持硬件触发，优先用定时器PWM触发，而不是软件启动） ADC_StartConversion(); // 3. 从接收PDO缓存取出最新目标值，更新PWM占空比 pwm_update(pdo_in_data.target_current); // 4. 标记本次同步中断已处理，供主循环统计/处理 sync0_flag = 1; }

这里有一个关键点：不要中断里直接做耗时操作，比如浮点运算、复杂滤波、外部存储写入。这些操作会占用中断执行时间，导致下一次SYNC0来临时前面还没处理完，轻则延迟，重则中断嵌套丢失。更合理的做法是中断里只做硬件触发和缓存交换，复杂算法放到主循环或者低优先级任务里做。

3.3 把采样抖动压到纳秒级

很多人完成SYNC0中断后，测一圈发现抖动还在微秒级，就开始怀疑DC没配好。其实在大多数情况下，DC层面已经没问题了，问题出在中断响应链路和采样触发方式上。

首先要检查MCU的中断优先级配置。SYNC0中断应该设置为最高优先级，不能被其他外设中断抢占。尤其是在低优先级中断里做长时间处理后，如果没有正确处理抢占关系，SYNC0的响应时间就会随着系统负载变化而波动，这个抖动反映到采样结果上非常明显。

其次，尽量让ADC用硬件触发，而不是在中断里写软件启动命令。软件触发到ADC真正的采样保持之间有一段不确定的延迟，例如代码执行时间、外设总线等待、时钟分频对齐等，这些都会造成采样点抖动。而如果定时器能产生与SYNC0严格同步的触发信号，再通过硬件直接触发ADC，抖动可以控制在极低水平。

还有一种常见问题：PWM更新时机不对。如果PWM定时器开着、比较寄存器值却在任意时刻被修改，输出波形相位就会变化。正确做法是利用PWM定时器的“周期匹配更新锁存”机制，在周期开始时统一装载比较寄存器值，确保每次PWM周期都从同一个基准点开始。

我在实际调板子时，还会用示波器同时观察SYNC0引脚和ADC的采样保持信号，专门看它们的对齐程度。如果每次触发都在固定的几个纳秒窗口内变化，说明硬件链路已经很稳；如果抖动达到几百纳秒甚至微秒级，基本可以断定中断链路或触发源有问题。

4. Latch信号实战：给外部事件盖时间戳

Latch信号往往被新手忽略，但在故障分析和精密测量场景里非常有用。举个实际例子：现场有多个从站，每个从站的IO输入都可能触发一个物理开关信号，如果用MCU中断去记录时间，不同从站的软件处理延迟不同，时间戳几乎没有可比性。而用Latch功能，所有从站都在硬件层面记录同一个DC时间轴的时刻，这样对比才有意义。

4.1 Latch信号接到哪、怎么配

先把Latch信号接到ESC对应引脚上。不同型号的ESC芯片Latch引脚数量不一样，可能只有Latch0，也可能有Latch0和Latch1。这部分必须查看数据手册，确认物理引脚位置，别接错了。

然后配置Latch使能及状态寄存器。配置内容包括：

• 选择Latch输入的有效沿，上升沿还是下降沿；
• 是否启用输入滤波，有的芯片内部有简单滤波，针对机械抖动较多的信号可以打开；
• 是否需要产生中断通知MCU读取时间戳。

有的工程师会直接把Latch引脚接到MCU的外部中断引脚上，让MCU在事件发生时立即读寄存器。这也是一种做法，但我更推荐让ESC的Latch中断去通知MCU，因为Latch中断本身就表明时间戳已经锁存完成，MCU只要去读取就行，不会遗漏边沿事件。

还有一个容易被忽略的点：Latch时间戳有溢出风险。DC时间是一个很大的计数器，纳秒级计数跑很久才会溢出，但在极端长时间运行下还是可能发生。软件里要对时间戳做连续性判断，比如发现新时间戳比上一次小了一大截，就要考虑溢出并做修正，否则累计误差会变成莫名其妙的跳变。

4.2 读取时间戳并换算成DC时刻

当Latch事件发生后，时间戳保存在ESC的时间戳寄存器中，例如ET1100/AX58100的Latch0时间戳寄存器，可以读出32位的系统时间值。

读取时要注意：建议先屏蔽或者锁存中断，避免在读取过程中新的Latch事件覆盖寄存器值。如果芯片支持，在读取前先清事件标志，一次把低16位和高16位读出来，再重新使能中断。否则可能出现读一半时时间戳更新，导致高位低位来自不同事件，时间戳完全错乱。

换算成DC时刻非常简单，读出来的值本身就是以DC系统时间为基准的纳秒计数。你不需要自己做时区对齐，只需要把这个值和主站的参考时间对比。比如你在SYNC0中断里也记录一个当前DC时间，两者相减就能知道Latch事件发生在同步点之前还是之后，精确到纳秒级。

4.3 典型场景：编码器Z相、IO跳变、故障捕捉

编码器Z相是最常见的Latch应用场景。伺服驱动的编码器每转一圈输出一个Z脉冲，你可以把它接到ESC的Latch0输入上，主站就能在任意时刻知道转轴事件对应的时间。结合SYNC0控制的PWM输出，系统可以把运动控制和位置反馈放到同一时间轴上做分析，省去很多麻烦。

IO跳变捕捉也是很有用的场景。举个例子，多个从站都监测外部急停信号，急停按钮按下时每个从站的Latch时间戳都会被记录。主站收集这些时间戳后，可以算出各从站检测到急停的先后顺序和时间差。这在故障排查时很有价值，不用再靠肉眼对示波器波形。

故障捕捉则可以结合输入电压跌落或过流信号。如果某个信号抖动剧烈，无法用中断可靠处理，Latch的硬件滤波和锁存能力就能派上用场。你可以在故障发生后的下个周期去读取时间戳，仍然能拿到准确的故障发生时间，哪怕MCU当时正在忙别的事情。

我一直觉得Latch是EtherCAT从站里面“性价比”最高的功能，它不需要自己写复杂的时间同步代码，却能把事件时间戳的精度提升好几个量级。如果你的应用涉及到多从站协同测量，务必把Latch用起来。

5. 常见问题与排查套路（踩坑实录）

这部分我把这些年调EtherCAT从站碰过的典型问题做了个汇总，每条都附上排查思路。你可以把它当成速查表，遇到问题先对号入座。

5.1 同步抖动大，示波器一看全是毛刺

这是最常见的问题，出现概率最高。

第一步先排除中断优先级问题。把SYNC0中断设为最高优先级，并且确认系统里没有另一个中断长时间霸占CPU，比如串口中断里做阻塞式发送，或者Flash擦写在中断里执行。这些都会直接拉高中断响应延迟。

第二步检查DC链路是否真的建立了。很多主站的日志里能看到DC补偿数据，如果补偿值一直在乱跳，说明时钟同步没有稳定，问题多半在物理层或者主站配置。检查网线、连接器、从站数量、通信速率等，都有可能导致DC性能下降。

第三步查SYNC信号本身。用示波器量ESC输出到MCU引脚之间的信号，看有没有明显过冲、下冲或振铃。信号质量问题会导致MCU内部触发点随机偏移，看起来就是抖动偏大。这种情况在板子上加RC滤波或合理调整驱动能力，通常能解决。

5.2 Latch不触发，或者时间戳永远是0

先确认Latch的引脚有没有信号进来。很多人把Latch信号接错引脚，或者复用了其他功能，自然一点反应都没有。用示波器量引脚波形，确认边沿存在。

再检查Latch使能配置有没有生效。有些芯片要求使能位和边沿选择一起写，如果只写了一部分，硬件不会真正工作。场景描述里很难踩到具体寄存器值，但思路就是先确认“功能打开”和“边沿有效”两个条件同时满足。

最后检查中断处理。如果Latch中断没开，MCU不会收到通知，人也可能误以为硬件不支持该功能。把中断使能打开，在中断里读取时间戳，确认每次事件都能对应一次读取。

5.3 SPI通信不稳定，偶发通信错误

建议先降速跑。如果SPI时钟降到2MHz就稳定，而拉到10MHz以上就出错，那是信号完整性问题。检查SCLK、MISO走线是不是太长，有没有跨分割，有没有跟电源或大电流走线平行。

再检查片选时序。很多MCU的SPI外设和ESC的SCS要求不完全匹配，尤其在多字节读操作时。建议改用GPIO控制SCS，确保命令、地址、数据都在片选低电平窗口内完成，结束再释放。

最后检查EEPROM里的PDI模式。这个老生常谈了，但确实是第一杀手。你有SPI信号但ESC工作在并行模式，要么引脚不识别，要么行为乱七八糟，看似通信问题，本质是配置问题。

5.4 中断一直在跑，主循环饿死

SYNC0周期太短或者中断处理太长，都会导致主循环根本没机会执行。先把中断处理函数里所有非必须代码全部挪出去，只保留触发硬件、读寄存器、更新缓存这几件事。

如果SYNC0本身就非常快，比如10us以内，就要认真评估到底用不用中断做所有事。可以用DMA方式搬运数据，或者做一个共享环形缓冲区，让高速中断只负责“记录”，主循环负责“消费”，保证两者解耦。

还有一种可能：中断标志没清除或者清除方式不对。某些ESC的中断标志需要通过读事件寄存器来清除，如果你只清了自己定义的变量而硬件标志还在，中断会不断进入，形成死循环。这种问题最终表现和“中断风暴”一样，排查时不要忘记看一眼事件寄存器。

结合我个人经验，EtherCAT从站的同步问题九成以上不在“玄学”，而在硬件信号完整性和软件事件顺序没对齐。别一上来就怀疑芯片不行或者主站有问题，老老实实用示波器把信号量一遍，把中断优先级捋一遍，很多问题都能定位到具体原因。踩坑踩得多了你就会发现，真正高精度的同步并不神秘，无非是每个环节都做得确定、可测量、可重复。