2026年电赛FPGA控制题，队伍用高云GW2A做多路电机闭环，为什么评委总说我们「像在跑例程」？

你们这个情况我大概能想象：三路闭环跑通了，PID 也在跑，但评委一问「和学长那套有什么区别」就卡住，说明作品里缺的是决策记录，不是功能。功能能跑通只证明你会用工具链，证明不了你设计过系统。我个人建议从三个地方补痕迹。第一是模块划分的依据：为什么三路电机共用一个 PID 状态机而不是三份并行逻辑，是资源不够还是为了采样同步？为什么编码器测速放在这个时钟域、上位机通信放另一个？这些在报告里要有一两句话的因果，不是只贴框图。第二是参数取舍：采样周期定多少、环路带宽留多少裕量，定点运算的位宽怎么定的、量化误差算过没有，哪怕只是估算也要写出来。第三是异常路径：堵转、丢步、编码器断线、串口帧错，你们的保护状态机是怎么进怎么出的，测过哪些边界工况。这里有个常见误区，很多队伍把「测过」写成「能跑」，但评委想看的是你测过哪些坏情况。举个具体做法：在报告里放一张表，列出你们试过的采样周期和对应的超调量，哪怕数据不漂亮也比没有强。另外提醒一句，别为了显得有设计感去堆花活，评委更认「为什么没选另一个方案」。你们现在三路电机的采样是同步触发还是各自独立跑的？这个点很可能被追问。

我换个角度说，这个问题本质上是「工程痕迹」和「功能演示」的区别，而大多数队伍在电赛里时间紧，天然会滑向后者。你们用高云GW2A做三路步进闭环，从零搭起来其实不轻松，但答辩现场评委只有几分钟翻代码和报告，他判断「是不是自己设计的」靠的是几个很具体的信号：模块边界是不是有理由、参数是不是有推导、异常是不是有预案。这三样东西恰好是例程里没有的，例程只会给你一个能跑的PID和一个能转的电机。所以我的建议不是让你们重写架构，而是在现有代码上把决策补记下来。比如模块划分，你们可以回头问自己：三路电机为什么共用一套测速逻辑，是因为GW2A的乘法器资源紧张，还是为了让三路采样在同一时刻对齐？不管是哪个原因，写出来就是设计依据。再比如采样周期，很多人是照着例程抄的1ms，你们如果试过500us和2ms，发现2ms时低速段测速抖动明显变大，这个观察本身就是很好的报告素材，因为它体现了你对环路带宽和量化误差的直觉。定点位宽也是同理，PID输出截断到多少位、积分项会不会饱和、饱和后怎么退饱和，这些在报告里画个小表就很有说服力。异常保护状态机是最容易被忽略但评委最爱问的：堵转检测的阈值怎么定的，编码器丢脉冲时系统是停机还是降级运行，串口帧错会不会导致参数被写坏。这些东西不需要多复杂，但要有。还有一个风险要提醒：别把报告写成代码注释的搬运，评委想看的是取舍，不是实现细节。你们现在最该补的其实是「测过的边界工况」这一块，因为这是唯一没法临时编的。

你们被说像跑例程，我觉得根子不在代码本身，而在评委看不到你们做过的取舍。例程的特点是每个参数都刚好、每个模块都通用、没有任何异常处理，因为它要保证任何人都能跑起来。而真实的设计一定带着约束的痕迹：资源不够、时序紧、精度要求高、某个器件有坑。所以想让评委觉得是自己设计的，最有效的办法不是加功能，而是把约束和取舍讲出来。

拿你们三路步进闭环来说，最容易被追问的就是采样周期。例程里多半写死1ms，你们如果也是1ms，那就要能回答为什么是1ms而不是500us或2ms。是因为低速段测速需要更长窗口才不抖，还是因为串口上报占用了时间片？这个答案本身对错不重要，重要的是它来自你们试过。试过就有数据：500us时速度环抖动多大、2ms时响应滞后多少、堵转检测晚了多久。这些数据写进报告，评委一眼就知道你们不是抄的。

再往下是定点位宽。FPGA里做PID，很多人直接拿例程的Q格式照搬，但位宽选多少、积分项会不会溢出、量化误差对低速控制影响多大，这些如果不算，一旦被问到「你的积分饱和怎么处理的」就露馅。哪怕只是纸上估算，比如编码器每周期计数值范围、乘加后的最大可能值、留几位保护位，写出来就是设计依据。

还有一个常被忽略的点是模块边界。为什么三路电机共用一套测速逻辑，是为了让三路采样在同一时刻对齐，还是因为GW2A的乘法器资源紧张？为什么上位机通信放另一个时钟域，是串口波特率和控制周期不同步，还是为了隔离？这些理由不需要多高深，但必须有，而且要和你们的实际资源占用对得上。

最后是异常路径。例程永远假设电机正常转、编码器正常回、串口正常收。你们如果做过堵转、丢步、编码器断线、串口帧错的保护状态机，就把状态迁移图和测过的边界工况贴出来。评委问「电机堵转你们怎么发现的」，你能答出是靠速度环误差持续超阈值加电流估计，还是靠编码器脉冲停止，这就够了。

总结一句：工程痕迹不是多写注释，而是每个决定背后都有个「因为」。你们现在缺的不是架构，是把已经做过的判断补记下来。顺便问一句，你们报告里现在有没有写资源占用和时序余量这些数据？