上一篇聊了运动控制算法在嵌入式平台上的实现，这篇聊它的搭档——嵌入式控制系统工程师。运动控制工程师负责"设计大脑"（WBC、步态规划），嵌入式控制工程师负责"练好身体"——让EtherCAT通信稳定可靠、让每个电机的FOC控制精准到位、让整个系统在长时间运行中不出故障。众擎这个岗位面试考的是实时系统设计、电机FOC调参和故障诊断的实战经验。
面试官的开场问题很底层："你有一台30自由度的人形机器人，主控制器通过EtherCAT跟30个电机驱动器通信。一个通信周期内数据流是怎样的？"
EtherCAT通信架构：数据怎么在1毫秒内跑完一圈
EtherCAT的通信模式是"一次发送、沿途读写"。主站构建一帧EtherCAT数据报文（EtherCAT frame），这帧报文通过以太网物理层沿着菊花链依次经过每个从站。每个从站在报文经过时"取出"属于自己的输出数据（主站→从站方向），同时"塞入"自己的输入数据（从站→主站方向）。报文在链路上跑一圈回到主站时，已经包含了所有从站的最新反馈数据。
一个完整通信周期的时序如下：主站构建报文（约20微秒）→报文在物理链路上传输（30个从站、每个从站处理延迟约1微秒、链路传播延迟约1微秒/米，总共约50微秒）→主站解析返回报文（约20微秒）→总计约90-150微秒。在1毫秒的控制周期里，通信占150微秒，留给控制计算的时间约850微秒。
面试官追问："如果某个从站的通信偶尔出现CRC错误（数据校验失败），怎么处理？"
CRC错误意味着这一帧数据不可信。处理策略分两级：偶发错误