昨晚突发奇想，想用 GLM-5.2 把手里积压已久、还能抢救一下的陈年老项目都往前推一推。结果翻到了这个 FOC 项目。
这个项目之前已经被我永久归档了，原因很简单：ESP32-C3 的外设能力实在太弱，根本撑不起我预设的指标。
我的目标是做 10kHz 电流环，也就是说每一轮控制计算必须在 100μs 内完成。但按照当时基于 ESP-IDF 标准 API 的实现，一次 SPI 编码器读取要 30μs ，一次相电流读取要 50μs （步进电机是两相，所以要读两次 ADC ），控制计算本身还要 80μs 。光这些加起来就已经远超预算，完全没法实现。于是这个项目就被我彻底搁置了。
这次我让 GLM-5.2 重新梳理外设部分。第一个目标是优化 SPI 读取时间。
它先自己写了一个打点测试程序，对 SPI 读取流程的每一步分别计时；随后把优化级别改成 O0 ，尽量降低指令重排对单步耗时统计的干扰。分析结果后，它判断主要耗时并不在 SPI 本身，而是在 ESP-IDF 的驱动层：多层封装、大量锁、层层参数校验，带来了很高的调用开销。
接着它自己翻了驱动实现，绕过 IDF 标准驱动，直接用 LL 层寄存器操作完成 SPI 读取。最终，单次读取耗时从 30μs 优化到了 9μs 。
ADC 读取部分也是类似流程：先打点、再定位瓶颈，最后重写成基于 LL 的直接操作。
然后是计算部分。GLM-5.2 把我原来基于 float 的控制计算重写成了定点数。ESP32-C3 没有 FPU ，软浮点开销非常大；改成定点数之后，计算部分的速度提升非常明显，量级上大约能拉开百倍差距。
中间还踩了很多工程上的坑，基本也都被 GLM-5.2 自己处理掉了。
我并不是专业嵌入式开发者，平时使用 ESP-IDF 也基本停留在标准驱动层，从来没有系统研究过 LL 层开发。上面这些优化，从晚上 10 点开始，到凌晨 3 点左右基本完成，期间大概跑掉了 Max 套餐周限的 20%。GLM-5.2 大约每 5 到 10 分钟会让我确认一次它的判断和下一步方案。我没有使用 /goal ，主要是担心项目优化方向跑偏。
最后贴一组电流环跟踪效果：
25976 kp=5.0000 ki=50.0000 theta=+2.1126 rpm=+0.0000 id=+0.0005 iq=+0.1021 us_total=162 lag=1 overrun=0
25977 kp=5.0000 ki=50.0000 theta=+2.1126 rpm=+0.0000 id=+0.0015 iq=+0.1015 us_total=142 lag=1 overrun=0
25978 kp=5.0000 ki=50.0000 theta=+2.1126 rpm=+0.0000 id=-0.0070 iq=+0.0885 us_total=142 lag=1 overrun=0
25979 kp=5.0000 ki=50.0000 theta=+2.1126 rpm=+0.0000 id=+0.0005 iq=+0.1021 us_total=142 lag=1 overrun=0
25980 kp=5.0000 ki=50.0000 theta=+2.1126 rpm=+0.0000 id=+0.0015 iq=+0.1015 us_total=153 lag=1 overrun=0
好像忘了说架构了，驱动芯片用的 DRV8411A ，在开始重写之前也和 GLM5.2 聊了很多 RL 常数，电流环带宽等等的事情，毕竟使用一个 3 欧 3mH 的电机，它的 RL 时间常数到了 ms 量级，要进行控制是很困难的。
Select Language