+EtherCAT 单拍耗时 345µs→124µs：改动原理与验证
+调查日期 2026-09-11 · 台子：i7-14700K + Intel I210（100 Mbps 全双工）+ DCU（GD32E508 + LAN9252）+ 3 台电机 · 源报告 tools/ecat/REPORT_ecat_beat_tail_20260911.md · 本页所有数字已对照源码与实机复测核验（layout=dense、rx p50=92.1µs、wkc 3/3、v1.6.22.0）
+
+345 → 124µs9/11 当天 0.5ms 档整拍 p50 实测（cyc_us.work）
310 → 92µs主站等回包 rx p50 —— 变化都在这一段
124.6µs9/8 同为 win 布局的实测单拍（CSV）—— 345µs 并非 win 固有成本
0.44µs/BPRAM 写单价（DWT 实测）—— 600B≈265µs/拍，两布局共同成本
结论（2026-09-12 修订）
+
+- 实测事实不变：9/11 当天 0.5ms 档整拍从 345µs 变 124µs、rx 从 ~310µs 变 92.1µs（≈纯线路 81.3µs + ~10µs），与板子重启进 1.6.21/22 密排同时发生；1.6.22 稀疏写开关 A/B/A 无可测影响（92.2 / 92.2 / 93.0µs）。
+- 但"345µs 是 win 布局的固有成本、密排省出 220µs"这条归因已被动摇：9/8 的存量扫描在同样 win 布局下实测单拍 124.6µs（0.125ms 档 7780Hz 的硬约束），与 dense 相同——345µs 是 9/10 夜才出现的异常态，不是 win 的常态。详见下方"重大更正"卡。
+- 仍然成立的独立事实：刷写 ≠ 生效（镜像 01:44 刷入、约 10 小时后断电重启才生效，三方计数器锚点）；台账只能证明"写进去了"——
flash_gd32.py 已加生效守卫。
+
重大更正（2026-09-12 复核）：220µs 的归因被动摇，两个变量被混在一起
+
用户质疑"5 个 STATUS 变 3 个，怎么会差 20 倍"——顺着查，发现两件原调查没做的事：
+
+- 机制核对（代码层）：两版 buildInput 逐行对比，纯 CPU 差仅 1~3µs（旧：5×48B + 5×44B 无条件拷贝；新：27 槽选最新 + 影子比对 + 3×48B）。对 ESC 的 PRAM 写两版同为整块 600B（DWT 实测 0.44µs/B → ≈265µs/拍，
ethercat_pdo_size.h），且 A/B/A 证明它对主站往返不可见——"删掉覆盖窗 / 差分填充省出的 CPU"解释不了 229µs。另：差分填充在本台工况下基本不命中（STATUS ~1.25 帧/拍/台，槽 seq 几乎每拍都变，重建路径照样走）。
+- 反例数据（9/8 存量扫描）：
lab/ecat_rate_sweep.csv——win 布局、0.5ms 档 cyc_p50=124.6µs、达成 100%；1ms=126.9µs；0.125ms=119.5µs 且实测 7780Hz（单拍必须 ≤128µs 才可能）。与 dense 的 124µs 同水平。
+
+
混淆的变量（刷板台账 git 史 + 主站 git 史）：9/8 板上镜像 201832b5…（win）→ 9/10 前已刷 4e84a354…（win 期 1.6.15→1.6.20 演进）；主站 9/9 03:05 提交 97fab23（三布局自适应、发现窗基址 {0,7,14,20}→{0,5,10,15,20,22}、覆盖窗按 seq 归一）。345µs 出现在这两个改动之后、9/8 之前——原归因把回归记在 1.6.21 密排头上，但密排也可能只是"绕开"了回归（dense 下主站强制 n_bases=1，不轮转窗口）。
+
钉死实验（一次刷板，未执行）：① 刷回 959e2ae（win 固件）+ build_native/ecat_native.prev.exe（9/6 构建，早于 97fab23；它不认识 dense 布局，必须配 win 板）→ 回 ~124µs 即主站回归实锤；② 同 win 板 + 现主站 → 345µs 复现即双向确认；③ 若 prev.exe 也 345µs ⇒ 回归在从站 win 期固件演进里，对 1.6.15→1.6.20 bisect；④ win 模式读 DWT 剖分计数器 0x2000 sub5/6/9/10（PDI_Isr 全程 / 输出映射 / 输入映射 / 其中写侧）——SDO 走独占路由会停环掉 OP，需专门开窗。
一、一拍的生命周期：210µs 差在哪一环
+主站每一拍做的事：组帧 → pcap_sendpacket 发出 → 等帧从线路绕回来（pcap_next_ex）→ 解码。等回包（rx）的时长 = 线路传输时间 + 从站把这一拍的输入镜像备好的时间——LAN9252 的 SM2 事件触发 PDI 中断，从站要在 ESC 把输入区搬上线路之前把 600B 输入镜像写好，主站就得等这段活干完。
+
+
① 同一 0.5ms 档、同一静默判据下的一拍构成（µs）
+
主站自身（pre+post 合计 0.3µs）发送（组帧 0.2 + pcap_sendpacket ≈28.4）线路传输 81.3µs（两布局相同）从站每拍准备（PDI buildInput）
+
+
数字出处：整拍与 rx 取自同机同档静默窗实测（win 345 / 310；dense 124 / 92.2，1ms 档复测 92.1）；发送 ≈28.6µs 为 0.5ms 档 A 臂 p50（1ms 档 dbg 拆段 26.6~31.3µs，内含组帧 0.2µs）；线路 81.3µs = 1016B×8÷100Mbps；win 从站准备 ≈229 = 310−81.3，与固件自量 buildInput 357µs（更重负载下所测）同量级。三段的逐层组成见下表。
+
+
三段逐层拆解（对应图中蓝 / 粉 / 红三个色块）
+
+| 段 | 0.5ms 实测 p50 | 从外到内的组成 | 出处 / 尚未拆开的部分 |
|---|
+| 发送（蓝） | 28.6µs | 组帧 ≈0.2µs（组 LRW + 填输出区）→ pcap_sendpacket ≈28.4µs：NPF 栈把 1016B 交给 I210 驱动并提交发送 | /api/motor/dbg 拆段（sd_us 列）。驱动/DMA 内部无仪表；B 臂曾见发送 p99 348.9µs 的偶发阻塞（单窗样本，未立论） |
+| 线路（粉） | 81.3µs | 帧 1016B = 过程数据 984B（输出 384 + 输入 600）+ 以太网头 14 + EtherType 2 + 数据报头 10 + WKC 2 + FCS 4；8128bit ÷ 100Mbps；再加前导 8B + 帧间隙 12B ≈ +1.6µs；从站 ESC 硬件转发 µs 级 | 由帧构成计算，两布局逐字节同长——结构上不可能解释 220µs 差 |
+| 从站准备（红）· win | ≈229µs | 1.6.15 每拍在 PDI 里：① 按 win_base 轮转准备 27 槽表 ② 段4 覆盖窗 5×44B 拷贝（fillRxWindow/RxWinSlot）③ MotorState 重读 + 逐槽 48B 拷贝 ④ 600B 经 HBI/PRAM 推入 ESC RAM | 实测差值 310−81.3。但 ①②③ 的纯 CPU 差按代码对比仅 1~3µs，④ 与整块 600B PRAM 写（≈265µs/拍）两布局同在且 A/B/A 证明不影响往返——229µs 的载体机制未闭环，且 9/8 同布局实测 124.6µs 表明"345µs=win 固有成本"的前提不成立（见"重大更正"卡） |
+| 从站准备（红）· dense | ≈10µs | 差分填充命中：节点集合与各 seq 未变 → 整段复用影子，①②③全免；只剩 count 个槽的更新推送 + ESC 取数 | rx 92.1 − 81.3。220µs 的差全部消失在这里 |
+
+口径备注：win 时代插桩拆段亦记录到 pcap_sendpacket 181.1µs、其后续中位 1 次 poll 即得帧（§四表）——该口径下发送调用内部吸收了部分等待，发送/等回包两段的分界随仪表口径浮动；但整拍总量（345）与"扣除线路后的从站侧总延迟"（≈229）不受此影响。另 1ms 档每拍 next_ex 轮询中位 79 次（轮询间隔 ~1.2µs），0.5ms 档为紧轮询。
+原理（按 9/11 当天的观测口径）：SM 长度（600B）与线速两布局完全相同，所以"线路那一截"不变；rx 的差值实测全部落在"等从站"这一段。但这段差值的载体机制存在重大疑点——两版 buildInput 的纯 CPU 差仅 1~3µs，且 9/8 同布局实测 124.6µs 表明 345µs 并非 win 固有成本——见开头"重大更正"卡。图①对比的是 9/11 上午 win 异常态 vs 午后 dense 的实测，不代表两种布局的固有差距。
+
+二、改动原理 A：从站输入映射 1.6.15 滑窗 → 1.6.21 密排整轮
+两种布局的输入区都是 600B（SM 长度、SII 都不变），只靠输入区第 35 字节的魔数 0xA5 区分（ecat_native.c:74-84，固件 ethercat_can_bridge.h:154 同款注释）：
+
+
② 输入 PDO 600B 布局对比（按字节偏移）
+
+
段3 长帧（CONFIG/版本应答）：win 在 320..359，密排前移到 544..583；段5 诊断两者都在 584..599。主站 decode_input 每拍判 magic@35 自适应，两端可任意先后升级。
+
+
1.6.21 的三个子改动，各砍掉什么活
+① 密排整轮：固定 5 槽 + win_base 轮转扫 27 槽 → count 个密排槽
+
旧方案段 2 固定 5 个 STATUS 槽（空槽 node_id=0 也占位），主站按 win_base 轮转窗口才能盖到 9 节点×3 通道=27 槽的表——接 3 台电机却会看到 5 个状态帧。新方案一拍直接带齐总线上全部电机（本台 3 台=3 槽×56B），槽内按 node_id 升序，主站按 count 迭代。砍掉的是主站轮转窗口带来的多拍刷新分频与从站"为凑满 5 槽而做的填充"。
② 删段 4 覆盖窗口（fillRxWindow / RxWinSlot 整套）
+
旧方案每拍要把非 STATUS 帧抄进 5×44B 的历史覆盖窗反复重发——这是纯粹的每拍 CPU 拷贝活。新方案非 STATUS 帧只走段 1/3 的"最近一帧"，覆盖窗整套删除（图中 win 红段在密排侧不复存在）。
③ 差分填充：节点集合与各 seq 未变时整段复用影子
+
注意一个容易误解的点：电机"不动"≠数据不变——STATUS 帧按电机自己的节奏持续上报（本台 3 台合计 ~3750 帧/s，每台 ~1.25 帧/拍），所以大多数拍里槽 seq 都变了、重建路径照样走（实测槽 seq 每 ~1 拍刷新一次）。差分填充真正的收益是"没变的槽不重读不重拷、重建范围从无条件 5 槽缩到实际变化的槽"——量级是 µs 级的，不能用它解释 rx 310→92（见开头"重大更正"卡）。
三、改动原理 B：1.6.22 稀疏写为何对主站往返"无效"
+1.6.22 的思路：PDI 往 ESC RAM 写输入镜像时按 count 只写「段1+段2 有效区」与「段3+段5」，跳过空槽区，省 HW_EscWriteIsr 的 PRAM 字节。方向是对的，但省错了地方——这里有一个关键的不对称：
+不对称原理：差分填充有效、稀疏写无效
+
+- 主站等的关键路径 = SM 交换（ESC 引擎把 600B 输入区搬上线路）+ 交换前从站把镜像备好。
+- 差分填充砍的是"备好镜像"的 CPU 活（MotorState 重读、逐槽拷贝、覆盖窗维护）→ 直接缩短关键路径 ⇒ rx 310→92µs。
+- 稀疏写砍的是"推镜像进 ESC RAM"的字节数，但 ESC 引擎上线搬运量由 SM 长度（600B）决定，不看 PDI 实际写了多少 → 主站等待不变。
+
+| A/B/A 轮次（只改这一个开关） | 板上版本 | 0.5ms 达成 | 长拍% | 发送 p50/p99 µs | 等回包 rx p50/p99 µs | load_perm |
|---|
+| A：稀疏写=1（出厂） | 1.6.22.0 | 99.90% | 0.10 | 28.6 / 45.9 | 92.2 / 190.9 | 489 |
+| B：整包写=0（A/B 基线） | 1.6.22.1 | 99.42% | 0.83 | 29.8 / 348.9 | 92.2 / 210.4 | 441 |
+| A 回归 | 1.6.22.0 | 99.85% | 0.10 | 29.4 / 86.9 | 93.0 / 101.2 | — |
+
+判读：rx p50 三轮 92.2/92.2/93.0µs ⇒ 稀疏写对主站往返无可测影响；load_perm 反而在整包写侧更低（441 vs 489）⇒ 它不能当这项的验收口径（真正该看 ESC 对象 0x2000 sub10，需独占路由停循环才能读，未做）。B 臂发送 p99 348.9µs 与 A 臂不同量级，但单窗样本不足以立论。当前 config.h 已回置出厂 A 臂（CONFIG_ECAT_SPARSE_ESC_WRITE=1）。
+
+四、配套改动：把"看不见的东西"变成仪表
+排查过程暴露了四个观测缺口，对应的改动与各自原理：
+
+| 改动 | 解决什么问题 | 原理 | 验证 |
|---|
+flash_gd32.py 生效守卫 | 台账只能证明"写进去了"，不能证明"板上在跑"（本次 10 小时空窗的根因） | 刷前记 ota.gd32_app 版本 + gd32_adc.uptime_sec；刷完必须"版本变了或 uptime 归零"才写台账，否则非零退出不写 | 两轮真实刷写 1.6.22.0→.1→.0 通过 |
+ecat_native.c cyc_us.late/lost 接真值 | 两字段旧为硬编码 0，超期/跳拍完全不可见 | 最近 STATS_N 拍窗口内统计：late=起跑即超期（k>0）的拍数，lost=这些拍跳过的周期数（累计仍在 skip_total） | 重载窗 late=21/lost=28，健康窗 0/0 |
+/api/motor/dbg 尾部追加两列 | 发送段是黑盒：不知 sendpacket 花多久、轮询了几次 | 第 7/8 列 = 本拍 pcap_sendpacket 净耗时与 pcap_next_ex 次数；旧列序不变，按前 6 列下标读的消费方不受影响 | 0.5ms 档 181µs 调用、每拍中位 1 次 poll |
+soem-src/oshw/win32/nicdrv.c pcap 调用计数 | 主/从栈调用混在一起没法归因 | 只在 stacknumber==0（主栈）累加 QPC 计数，冗余栈不计防双计 | A/B 与旧构建行为一致（中性） |
+watch_beat_tail.py（新） | 跨分钟现象无法回溯（布局翻转恰好发生在两次采样之间） | 每 10s 只读一轮 motor/state+rxraw+app/load，落 27 列 CSV（layout/work/send/rx/late/lost/λ/达成） | --once 跑通 |
+transport-ecat.js 常量适配 | 前端仍按旧 5 槽/6 周期口径显示 | 密排下一拍整轮：MOT_SLOTS_PER_PDO 5→9、MOTOR_SCAN_CYCLES 6→1；能否拿齐电机由后端 decode 决定，常量只影响展示口径 | 电机页原样复用，无回归 |
+lab/spi_test.html 跳拍卡 | 旧版需开逐拍环才有超期数据 | 直接读 cyc_us.late/lost（最近 400 拍窗），并注明旧后端恒报 0 不可当"无超期" | 真机复跑成功，node --check 通过 |
+
+
+五、证据：dense 是真的，以及为什么今天才生效
+
+
③ 判据：槽 seq 距当前 gseq 的滞后分布（111 次连续采样 ×3 槽=333 样本）
+
+
三台电机落在槽 2/5/8：滑窗方案盖住它们需 ≥2 个基址轮转 → 每槽每 ≥2 拍才刷新、滞后应集中在 4~8 帧。实测 1/3 样本滞后为 0、全部 ≤4 帧 ⇒ 只能是"每拍带齐整轮"的密排语义。seq 与 gseq 都是 GD32 自己盖的号，滞后能对上同时证明解码偏移没错。（原报告曾把"gseq≡rx_count"当最强证据，复核发现两种布局 gseq 同在偏移 36，该条不能区分布局，已撤换为本判据。）
+
+
④ 时间线：刷写 ≠ 生效
+
+
主站在 02:3x 直接读到 layout="win" len=232 配 345µs——刷入后 10 小时仍是老代码在跑。台账 _last_gd32_sha.txt 当时就与 Release hex 展平一致，即"写进去了"为真，"在跑了"为假。（A/B/A 之后台账现为 dda92d11…，对应 12:46 刷回 A 臂的产物，本次复核独立展平重算一致。）
+
+
同机同日前后对照（观察性证据）
+
+| 从站布局 | rx 往返 | 整拍 p50 | 达成 | 长拍>1.4× | 跳拍 k>0 | gap p99 |
|---|
+win（1.6.15 滑窗） | ~310µs | 345µs | 93.9%（1879Hz） | 7.9% | 8.6% | 1144µs |
+dense（1.6.21/22 密排） | 92.2µs | 123µs | 99.9%（1998Hz） | 0.10% | ~0.6% | =周期本身 |
+
+0.5ms 档余量从 155µs 变为 377µs：旧方案任何调度抖动都会成片跳拍，新方案长拍基本消失。另 1ms 档现网 late/lost（k>0 口径，连 1µs 超期都算）为个位数/400 拍窗，与"长拍>1.4×≈0%"不矛盾——两套阈值灵敏度不同，并列引用时必须标注口径。
+
+六、被实测排除的原因（别再重测）
+
+| 候选解释 | 排除依据 |
|---|
+| 线路变快 / 帧变小 | 两种布局 Ibytes 同为 600B（ecat_native.c:74 与固件头文件双侧注释），帧长 ~1016B 不变，线速仍 100Mbps 全双工 |
+| 收帧超时（EC_TIMEOUTRET） | 预算 2000µs（µs 单位），11,264 拍里仅 1 拍 EC_NOFRAME；win 时代 rx p50 7~9µs 起步，预算从不消耗——收紧它是自证式"变好" |
+| 主站构建差异 / 双实例 | 插桩版与旧构建 A/B 一致；单进程单端口；旧 exe 留档 build_native/ecat_native.pre-instr.exe |
+| 观察者负载 | 面板全量 10Hz×3、单 dbg 10Hz（≈1.5MB/s JSON）、零请求静默窗，三者结果在噪声内相同 |
+| CPU 抢占 | 另开 4 / 12 个纯算线程压机，send/rx/work 一动不动 |
+| "PRAM 逐 DWORD 轮数 150→45" | 被 A/B/A 否：整包写 600B 的 B 臂同样 92µs——写侧省字节数不进入主站关键路径（§三不对称原理） |
+
+
+七、复核更正（本次排查自己错过又改掉的判断）
+证据层的两处撤换
+
+- "gseq≡rx_count，差恒 0"是同义反复：
MOTW_OFF_GLOBAL_SEQ 与 MOTW_OFF_GSEQ_DENSE 都是偏移 36（ecat_native.c:69,82），两种布局读同一字节，分不开 dense 与 win。已撤换为 §五-③ 的槽滞后判据。
+- 魔数 0xA5 无法从主机侧直接读：
/api/motor/rxraw 返回的是批量接收区缓冲快照，不是 PDO 输入镜像；路由表中没有任何路由吐输入镜像。故"直接验魔数"这条路不存在，dense 判定只能靠上述间接判据 + 60s×30 与 111 次采样稳定性（layout 恒 dense、len 恒 176、count 恒 3、win_bases 恒 None）。
+
限制声明的一处更正（本次复核新增）
+
+- "DCU_APP 不在任何 git 仓库、布局无法 A/B"不成立：
DCU_APP 是独立 git 仓库（38 个提交）——959e2ae = 1.6.14~1.6.20 滑窗覆盖窗源码、1742d9a = 1.6.21 密排；命令行构建链（cbuild + AC6）现成。因此"win→dense 换来 220µs"这一环可以做受控实验钉死：checkout 959e2ae 重编刷板 → 预期 rx 回到 ~310µs → 再刷回 1.6.22（flash_gd32.py 生效守卫会留台账）。属刷板操作，未执行。
+- 遗留：重刷同一版本无法证明生效——
gd32_adc.uptime_sec 实测不随 GD32 换镜像归零，守卫的"uptime 归零"分支不可靠，目前只能靠版本号变化。根治要 BOOT 上报复位计数/复位原因，或 OTA 完成后强制 APP 复位回读。
+
归因的置信度边界（2026-09-12 修订）
+
+- 已受控验证：稀疏写开关（A/B/A，单臂 2048 拍静默窗，效应上界 ≲1µs/拍）；排除项（§六）；"刷写≠生效"时间锚点（§五）。
+- 已动摇：win→dense 与 220µs 的因果归因——9/8 同布局实测 124.6µs 的反例 + 两版 buildInput 纯 CPU 差仅 1~3µs。原"三条独立吻合"里"旧值≈357µs"一条存疑：357µs 是 1.6.11 时代（496B 输入 + 环形批量区）的测量，与滑窗 600B 版不同代。
+- 待做：开头"重大更正"卡的刷板 A/B（959e2ae + prev.exe 双轮）是当前唯一能闭合因果的实验。
+
八、遗留与下一步
+按优先级
+
+- 布局 A/B 钉死归因（方案已更新）：刷回
959e2ae（win 固件）后做两轮——配 ecat_native.prev.exe（旧主站，≤78fe6cf）与现主站各测一轮 0.5ms：124µs / 345µs 的分野即判定回归在主站还是从站 win 期固件；再用 0x2000 sub5/6/9/10 定位。刷板会中断 OP 会话，需专门安排。
+- 0.25ms 档第一次有理论余量（124/250=50%），值得按同一静默判据实测——但注意此前结论：从站 SSC 的 SM2 事件路径在快档有自己的墙，别只看主站达成率。
+- 重刷同版本的生效证明：BOOT 上报复位计数，或 OTA 后强制 APP 复位回读版本。
+0x2000 sub10（EscWrite 周期）精确验收需独占路由（停循环、从站掉 OP），要专门开一窗。- ms 级离群未清零：dense 时代仍见 work max 2153µs / rx max 1658µs（p90 仅 ~110µs），量级无害但没定位。
+- 本次全部改动未提交（tools/ecat 3 文件+报告、tools/ESP32 7 文件、DCU_APP 4 文件），旧主站 exe 留档在
build_native/ecat_native.pre-instr.exe。
+
上限已实测：≈8.2kHz，墙是单拍 ≈121µs 的硬耗时
证据链：无 CAN 设定 0.25 → 0.0625ms 五档，实测循环率在 ≤0.125ms （8kHz）前跟随设定，再快就被钉死在 8196–8238Hz；与此同时主站单拍耗时 cyc p50 在所有档位（含 2ms 慢档）恒为 117–126µs，1/121µs ≈ 8.2kHz，与顶墙实测严丝合缝。即：每拍有一段不可压缩的「发送→从站处理→回读+主站处理」往返时间，周期设定小于它时就堵在这里。
排除项：不是主机 CPU 不够 —— 顶墙档主机 CPU 只有 ~85%（自旋等待占比变小）；不是从站拒答 —— wkc 全程 3/3。load_perm 在 ≥4kHz 全饱和 99.x%，既定位不了拐点也喂不准模型，早先「两项模型 load=F/T+R → 2.7/3.5kHz」的外推已被满速补测证伪，仅留档。
未闭合的一处：121µs 里主站协议栈与从站 ESC/固件各占多少，本轮数据分不开 —— 需给固件 fillRxWindow 加直接计时（固件改动，需批准）或抓总线帧时序才能归因。
-
-
LAN9252 通断测试
-
通过 ESP32 /spi/send → SPI 0xA2 → GD32 驱动 EXMC 引脚,万用表测 LAN9252 端电压
-
-
- ⚠️
- 不点按钮时 GD32 引脚为高阻输入态(安全)。点击模式后先预览引脚图,点"确认应用"才实际驱动引脚。测量完毕请点"停止/恢复"释放。
-
-
-
-
-
- 设备 IP
- 读取中...
- 共用主页"设备连接"配置的 IP
-
-
-
-
-
-
LAN9252 64-QFN 引脚图
-
俯视,Pin1 右上角。点击下方模式按钮预览引脚电压,点"确认应用"发送命令。绿色=3.3V,红色=0V,橙色=控制线测试中。
-
-
-
-
- HIGH 3.3V
- LOW 0V
- 控制线测试
- 数据线空闲
- 控制线空闲
- 电源/其他
- Pin1
-
-
-
-
-
-
模式选择
-
点击预览引脚图,再点"确认应用"发送命令
-
-
数据线 pattern · D0-D15
-
-
-
-
-
-
-
-
控制线测试
-
-
-
-
-
-
-
-
-
读周期保持 · 判定芯片是否驱动总线
-
-
-
-
- 数据线切为高阻输入、CS#+RD# 持续拉低(读 IDX_0)。用万用表在 LAN9252 芯片引脚 上量数据线:
- 芯片活着 → D2(Pin12)、D4(Pin49)、D5(Pin50)、D9(Pin19)、D12(Pin21) ≈ 3.3V,其余数据脚 ≈ 0V(全部确定电平,即 0x1234);
- 全部中电平/漂移 → 芯片未驱动总线。图上预览色 = 芯片应答的期望值。
-
-
-
-
-
-
操作
-
-
-
-
-
-
- 确认应用 · 发送当前选中的模式到 GD32
- 循环切换 · 每5s在 0x0000 ↔ 当前选中模式 之间切换(需先选数据线 pattern)
- 停止 / 恢复 · 恢复 EXMC 正常模式
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
🌙 进入低功耗档
+
+
+
+
+
+
+
+ D1 系统时钟关、晶振+PLL 保持（有自动唤醒路径）。
+ D2 PLL 请求关（两 PHY 已掉电才真关）。
+ D3 晶振/PLL 全关，最省电、只能手动唤醒（二次确认）。
+ 休眠期间 EtherCAT 中断、主站 wkc 报错属预期；ESC 寄存器配置全保留，唤醒后自清睡眠位。
+ D3 进入前固件自动掉电两 PHY，唤醒后自动恢复（自协商需数秒）。
+
+
+
+
+
+
🛟 恢复链 —— 为什么睡不死
+
+
+ - action 34 软唤醒（正常路径，≤2ms）
+ - NRST 硬复位：PB10 拉低 60ms 释放，等效上电复位，覆盖 D3 睡死/HBI 假死等一切软件状态
+ - GD32 断电重启：复位期间 PB10 浮空由 R44 上拉维持，重启后固件 hardwareReset() 自动重走受控复位
+
+
+
+
+
+ 可靠性：ESP32↔GD32 的 SPI 链路与 LAN9252 完全解耦（独立外设/中断），芯片睡得再深
+ 0xA2 照样送达 GD32——恢复失败的唯一前提是 ESP32 和 GD32 同时失能，那已不是休眠问题。
+ NRST 复位会清掉 SSC 已配置的芯片状态，EtherCAT 需主站重新走状态机。
+
+
+
+
+
+
📋 status 字节判读（recv 首字节）
+
+
+ | 位/值 | 含义 |
|---|
+ bit0 | READY：1=D0 且 PLL 稳定 |
+ bit1 | PM_SLEEP_EN：1=低功耗档 |
+ bit3:2 | PM_MODE 寄存器位（仅 SLEEP_EN=1 时有效；未睡眠可能残留旧档） |
+ 0xEE | 无效 action |
+ 0xE1 | HBI 未就绪（勿操作电源） |
+ 唤醒 1/0 | 成功 / 10ms 超时 |
+
+
+
+
+
+
+
+
+
+
+
🔋 芯片电源状态 2s 自动刷新
+
+
🌙 芯片处于低功耗档 —— EtherCAT 通信已中断，点「手动唤醒」恢复
+
+
READY--
+
SLEEP_EN--
+
电源档--
+
原始字节--
+
+
+
+
+
+
唤醒轮询上限 10ms（手册标称 ≤2ms）。超时多半是芯片不在睡眠或 HBI 异常——以「读状态」为准。
+
+
+
+
+
+
+
+
+
+
+
+ 真源 ethercat_can_bridge.h
+ 尺寸 ethercat_pdo_size.h
+ PRAM 0.441 µs/B
+ 魔数 @35=0xA5
+ 电机槽 ≤9 × 56 B
+ 稀疏写 CONFIG=1
+
+
+
+
布局 1.6.21 · 固件 1.6.24 · 写侧 1.6.22 起稀疏
+
+ - 字节布局仍是 1.6.21：段 2 密排、删段 4、魔数
@35=0xA5；out 384 + in 600 不变，SII/EEPROM 无需重刷。
+ - 1.6.22 稀疏写 ESC（
CONFIG_ECAT_SPARSE_ESC_WRITE=1）：按 count 只写「段1+段2有效区」与「段3+段5」，跳过空槽区。主站解码不变，仍只按 count 迭代。
+ - 1.6.23/1.6.24 为 LAN9252 电源管理诊断（pmDrive D1/D2/D3），不影响 PDO 布局。
+ - 回退整包 600B 的条件：开关置 0 / magic≠0xA5 / count 越界 / count 撑满（9 电机两段相接）。
+
+
+
+
+ 桥状态 / 快照
+ 段头 / 元数据
+ 电机密排槽
+ 批量发送区
+ 诊断
+ 保留 / 填充
+
+
+
+
+
+ 1
+
输入 PDO · 600 B · 从站 → 主站
+ 稀疏写 96–600 B · 整包 ≈265 µs · 3 电机 ≈116 µs
+
+
+
+
+
段总览
+ SM3 · 0x1880–0x1F67 · 3-buffer · 写侧稀疏
+
+
+
+
+
段内字段
+ 每段独占全宽 · 宽度 ∝ 字节数
+
+
+
+
字段明细
+
+
+
+ | 段 / 字段 | 偏移 | 宽 |
+ 类型 | 内容 | 属性 |
+
+
+
+
+
+ | 合计 |
+ 600 |
+ |
+ 逻辑总长；写侧按 count 稀疏（见下） |
+ 96–600 B |
+
+
+
+
+
+
+
+
+ 2
+
输出 PDO · 384 B · 主站 → 从站
+ pramRead(384) · 96 DWORD · ≈169 µs 折算
+
+
+
+
+
段总览
+ SM2 · 0x1400–0x187F · WIN@8 忽略
+
+
+
+
+
段内字段
+ 每段独占全宽 · 宽度 ∝ 字节数
+
+
+
+
字段明细
+
+
+
+ | 段 / 字段 | 偏移 | 宽 |
+ 类型 | 内容 | 属性 |
+
+
+
+
+
+ | 合计 |
+ 384 |
+ |
+ 每拍一次 pramRead(384)（未实测） |
+ ≈169 µs |
+
+
+
+
+
+
+
+
+ 3
+
电机槽内部 · 56 B × ≤9
+ PDO 地址 = 40 + i×56 · node_id 升序
+
+
+
+
+
密排槽区 @40..543
+ 空节点不占位 · count 决定有效槽数
+
+
+
+
主站解码
+
+
count = in[32]; // 0..9
+magic = in[35]; // 必须 0xA5
+for (i = 0; i < count; i++) {
+ p = in + 40 + i*56;
+ node = p[0]; ch = p[1]; online = p[2];
+ seq = le32(p+4);
+ status = p+8; // 48 B
+}
+
+ 同号多通道取 seq 最新的一条；写侧 seqlock 奇数（写入中）的槽本拍省略、下拍自愈。
+ 节点集合与各 seq/online 未变时整段复用影子区（CPU 差分），PRAM 写侧仍按 count 决定字节数。
+ 1.6.22+ 稀疏写：ESC 中 40+count×56 .. 543 为上次残留，
+ 主站只许按 count 迭代，不得读空洞区。
+
+
+
+
单槽字段明细
+
+
+ | 字段 | 槽内偏移 | 宽 | 类型 | 内容 |
|---|
+
+
+
+
+ | 单槽合计 | 56 |
+ 8 B 头 + 48 B STATUS |
+
+
+
+
+
+
+
+
+ 4
+
每拍成本与 SM 预算
+ PRAM ≈0.441 µs/B · 稀疏写 1.6.22+
+
+
+
+
+
输入写侧 · 3 电机稀疏
+
116
+
µs/拍 · 264 B×0.441 · 11.6% @1ms
+
+
+
+
输入写侧 · 整包基线
+
265
+
µs/拍 · 600×0.441 · 26.5% @1ms
+
+
+
+
输出读侧 · 探针命中
+
12
+
B 探针 · 无沿时跳过 384B 全量读
+
+
+
+
1.6.22 稀疏写 ESC · 写侧字节随 count 缩
+
CONFIG_ECAT_SPARSE_ESC_WRITE=1（默认开）。HW_EscWriteIsr 只写两段：
+
段A = [0 .. 40+count×56) // 段1 桥状态 + 段2 头 + 有效密排槽
+段B = [544 .. 600) // 段3 长帧 + 段5 诊断 + 保留
+跳过 = [40+count×56 .. 544) // 空槽区（ESC 中为 SM 缓冲上次残留）
+
+count=0 → 96 B ≈ 42 µs
+count=3 → 264 B ≈ 116 µs
+count=8 → 544 B ≈ 240 µs
+count=9 → 整包 600 B（两段相接，回退）
+
+ APPL 仍整填 aPdInputData（对齐 SDO 0x6000）；省的是 PRAM 搬运时间，不是 RAM 拷贝。
+ 主站必须继续只按 count 迭代——空洞区内容是上次残留，不可读。
+
+
+
实测锚点：从站自报负载
+
1 ms 档 49.2% → 0.5 ms 档 81.4% → 0.25 ms 档 98.7%，同时 λ 从 6000 帧/s 塌到 317 帧/s —— 饱和发生在从站，不在主站的 Npcap 或钉核上。
+
+ 上表为 1.6.21 整包基线。1.6.22 稀疏写开启后写侧字节随 count 缩，同工况 load_perm 应显著下降；
+ 验收看 0x2000 sub10（EscWrite 周期）与 load_perm，同工况开关各测一轮。
+
+
+
+
DPRAM 预算 · out + in ≤ 1024 B
+ LAN9252 · 过程区 0x1400–0x1FFF · 3-buffer
+
+
+
+
+ 邮箱 SM0/SM1 各 256 B 固定占 0x1000–0x13FF；SM2/SM3 均为 3-buffer（control 0x64/0x20，bit1=0），实占 (out+in)×3。
+ 要再大只有两条路：邮箱压小（上限约 1280 B，代价 SDO/FoE 变慢）或改 1-buffer（上限 3072 B，代价失去三缓冲并发保护）。
+
+
+
+
+
+
+
+ 5
+
段 4 历史覆盖窗口 · 已删除
+ 1.6.15 引入 → 1.6.21 删除
+
+
+
为什么删
+
1.6.15 曾把批量接收区做成「定长覆盖窗口」：5 个固定格子（每格 44 B = 12 B 头 + 32 B 数据）+ 写游标绕圈。它是「最近 5 帧」而不是队列 —— 第 6 帧盖掉第 1 帧，未取走的计入 OVF。
+
+ - 覆盖窗口反复重发最近几条非 STATUS 帧，属于「历史帧 / 重复帧」，对电机状态视图是噪声；
+ - 用户实测病理：接 3 个电机，网页却看到 5 个状态帧 —— 旧段 2 固定 5 槽里空槽
node_id=0 也占位，主站不滤空槽就多报。
+
+
本版语义：每一拍只携带「总线上已识别电机的完整一轮状态」。版本/CONFIG 仍走段 1/段 3「最近一帧」快照。对象字典 sub21 恒 0；596..599 保留空洞。
+
+
+
+
+
单帧分段平均（固件五段拆解，占总往返比例）
跑一次测速后出现
@@ -333,18 +332,18 @@
刷新率 实测 = Δcycles/Δt；名义 = 1000/period_ms 仅作对照，两者差值就是软件调度开销
-
-
-
-
-
单电机状态刷新
—Hz
slot_period_ms —
-
CAN 到帧率 λ
—/s
Δglobal_seq (u32)
-
真丢帧
—帧/拍
主站 seq 空洞 · 从站 OVF（抽样单拍值）
-
-
从站 CPU 负载
—
load_perm · age —
-
-
撕裂 / 重入
—
rx_torn / pdo_reentry
-
本页请求耗时
—ms
本页→代理→native 最慢一个请求的往返（≠节拍耗时）
+
+
+
+
+
单电机状态刷新
—Hz
slot_period_ms —
+
CAN 到帧率 λ
—/s
Δglobal_seq (u32)
+
真丢帧
—帧/拍
主站 seq 空洞 · GD32 OVF（抽样单拍值）
+
+
从站 CPU 负载
—
load_perm · age —
+
+
撕裂 / 重入
—
rx_torn / pdo_reentry
+
本页请求耗时
—ms
本页→代理→native 最慢一个请求的往返（≠节拍耗时）
判读：达成率 < 100% = 节拍被软件拖住；λ ÷ 实测Hz = 每拍到达几帧 CAN（当前 1ms 档实测 6 帧/拍）。
@@ -356,7 +355,7 @@
真丢帧逐层看：① CAN 控制器 err/TEC/REC；② CAN 软件 RX 队列满（深度 16）的
rx_drop_count —— 只在 ESP32 /can/feedback 有，过程数据里没有；
③ 段 4 覆盖窗口 主站侧按 seq 空洞算的 rx_batch.lost（step/2−1，
- 发布值恒为偶数，按 step−1 会把每帧虚报成丢 1 个）；④ 段 4 从站侧未取先覆
+ 发布值恒为偶数，按 step−1 会把每帧虚报成丢 1 个）；④ 段 4 GD32 侧未取先覆
rx_batch.pending（= OVF，与 ③ 是两个独立仪表，正常应当同步增长）；
⑤ CAN 取帧撕裂 rx_torn。③④ 是本页 10Hz 抽样看到的单拍值，只能当下界。
撕裂 / 重入是饱和计数（到 65535 停），封顶时只能报下界。
@@ -405,9 +404,9 @@
B32-35 —— 补 0 会把"无数据"显示成"初始化正常"。
-
收到的东西 ② 批量接收区 rxraw.parsed（与下面槽表同一拍快照）· 段 4 覆盖窗口去重后的事件流
+
收到的东西 ② 密排整轮 + 长帧事件 rxraw.parsed · 1.6.21 密排：段2整轮槽 + 段3长帧变更
- 本拍新帧 / seq 空洞 / 从站 OVF —
+ 本拍新帧 / seq 空洞 / GD32 OVF —
本页帧样本 —
@@ -417,13 +416,12 @@
-
- 覆盖窗口 5 槽原样（从站每拍整块拷出，写游标绕圈覆盖 —— 槽下标 ≠ 到达顺序，seq 才是顺序）。
- 末列「本拍新上报」：是 = 这一拍第一次见到这帧，主站把它交给上层；否 = 它是上一拍就交过的旧帧
- （窗口只留"最近 5 帧"，一帧会连续几拍都躺在里面，但不会被重复上报）。
+
+ 密排整轮槽（GD32 每拍原样拷出 count×56B：node ch online dlc seq + 48B STATUS）。
+ 末列「本拍新数据」：是 = seq 比上一拍大（差分命中，状态真变了）；否 = seq 未变，固件本拍跳过填充。
@@ -433,18 +431,14 @@
- 同一 ID + 同一载荷出现两次不是重复显示：主站已按每槽 seq 去重，同一帧不会报第二次。
- 实测 120 个窗口快照里「同 ID 且 seq 相同」0 次、「同 ID 但 seq 不同」240 次 —— 那是两帧真的各到达一次，
- 只是电机空闲时 CONFIG 回报的 24B 逐字节相同，肉眼看一模一样。看下面槽表的 seq 列即可分辨。
-
"前面像少了一帧"也不是丢帧：① 主站每拍只把 seq 比上次大的槽交给上层，上一拍已经交过的帧
- 仍躺在窗口里（就是末列的"否"），但不会再进上面的表；② 页面 10Hz 采样、PDO 1kHz，两次采样之间约
- 100 拍的窗口内容已被覆盖，看不见（所以"样本数"只占全量约 0.8%，全量看 λ 那张卡）。
- 本表能看到的丢帧判据只有两个：seq 空洞（主站侧）与 OVF（从站侧），
- 上面 pill 里实时显示，实测同为 0；本表看不到的还有三层 —— CAN 控制器 err/TEC/REC、
- GD32 软件 RX 队列满丢（深度 16，只在 ESP32 /can/feedback 有）、CAN 取帧撕裂
- rx_torn。逐层对账跑 scripts/can_bridge_reconcile.py。
-
长帧（CONFIG 24B / 版本应答）在 8B 短快照里会被截断，所以后端另开 state.xrx 长帧槽，
- 逐字节的真凭实据在下面第 ③ 区的原始窗口里。
+
密排整轮（1.6.21）：接 N 个电机本拍就发 N 个状态，空槽不发送。
+ STATUS 全在上方状态槽解码；本表是同一拍的
线级原样（seq / online / 前 8B 载荷），
+ 用来核对"差分是否真的跳过了未变电机"。
+
长帧（CONFIG 24B / 版本应答）：段 3「最近一帧」，内容变了才进上面的事件表
+ （主站按 ch/dlc/id/data 逐字节比对，相同不重复上报）。逐字节的真凭实据在下面第 ③ 区。
+ 本表看不到的还有三层 —— CAN 控制器 err/TEC/REC、GD32 软件 RX 队列满丢（深度 16，
+ 只在 ESP32
/can/feedback 有）、CAN 取帧撕裂
rx_torn。
+ 逐层对账跑
scripts/can_bridge_reconcile.py。
@@ -453,8 +447,8 @@
- layout：win=1.6.15 定长覆盖窗口 / slim=变长 / old=旧布局，解析器必须按 layout 选，
- 否则拿变长游标解定长窗口会整片错位。
+
layout：dense=1.6.21 密排整轮 / win=1.6.15 定长覆盖窗口 / slim=变长 / old=旧布局，
+ 解析器必须按 layout 选，否则拿变长游标解定长窗口会整片错位。
xrx 长帧完整载荷（kv 里那行是截断的，这里不截）
—
@@ -469,7 +463,7 @@
-
覆盖窗口原始字节 —— 按 44B/槽分组：头 12B（ch dlc flags pad ‖ id LE ‖ seq LE）+ 数据 32B（两行）
+
接收区原始字节 —— dense：8B 整轮头 + count×56B 槽；win：44B/槽 覆盖窗口
—
连接设备后读取节点 ID
- SET_NODE_ID (0x000N0400 DLC2) / GET_NODE_ID (0x000N0401 DLC2)。写入后 CAN ID 前缀变为 0x000Nxxxx。
+ SET_NODE_ID (0x000N0400 DLC2) / GET_NODE_ID (0x000N0401 DLC2，选择器 0x0000)。写入后 CAN ID 前缀变为 0x000Nxxxx。
+
+
+
+
+ 反馈刷新率 Hz · 0=停发 · 写入掉电保存
+
+
+
+ STATUS 帧 默认 1000 Hz
+
+
+
+
+
+
+ CONFIG 帧 默认 250 Hz
+
+
+
+
+
连接设备后读取当前刷新率
+
+ 输入为频率（Hz），协议按 周期(ms) = 1000 ÷ Hz 换算下发：0x000N0400 DLC4 [选择器][周期] /
+ 0x000N0401 DLC2 [选择器]（选择器 0x0100=STATUS · 0x0101=CONFIG）。当前值以「读取」回读为准。
+ 停发 STATUS 后状态面板会显示离线，电机仍可控可刷写。
@@ -402,7 +430,7 @@
-
+