昨晚突发奇想,想用 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 量级,要进行控制是很困难的。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.