081 STM32Cube.AI的功耗优化案例：从电池焦虑到毫安级自由一个让人抓狂的深夜调试凌晨两点，我盯着示波器上的电流波形，血压和波形一起在跳。客户要求设备用CR2032纽扣电池跑三个月，我手上的STM32L4+AI推理任务，实测待机电流2.3mA——按这个功耗，电池撑不过两周。更讽刺的是，AI模型在PC上跑得飞起，一部署到MCU上，CPU就像打了鸡血一样全速运转，功耗直接起飞。这不是个例。很多工程师把AI模型塞进MCU后，发现功耗比裸跑翻了五倍以上。问题出在哪？不是STM32Cube.AI不行，而是我们没理解“AI推理”和“MCU功耗管理”之间的微妙关系。今天这篇笔记，就聊聊我踩过的坑和最终找到的解决方案。第一个坑：CPU跑满100%的真相STM32Cube.AI生成的代码，默认行为是“尽快完成推理”。这听起来没毛病，但代价是CPU在推理期间以最高频率全速运行。如果你的模型推理需要50ms，CPU就在这50ms内保持80MHz甚至更高频率。对于电池供电设备，这种“短时高功耗”的累积效应非常致命。我最初的做法：在推理前后手动调整时钟频率。比如推理前切到80MHz，推理完立刻降到2MHz。但实测发现，切换时钟本身有延迟，而且频繁切换反而增加了额外功耗。更坑的是，STM32Cube.AI生成的推理函数内部可能调用了硬件加速器（如M4的FPU或M7的SIMD），这些外设在低频率下效率反而下降。正确的思路：不是降频，而是让推理任务“匹配”系统空闲时间。比如你的设备每100m
081 STM32Cube.AI的功耗优化案例：从电池焦虑到毫安级自由一个让人抓狂的深夜调试凌晨两点，我盯着示波器上的电流波形，血压和波形一起在跳。客户要求设备用CR2032纽扣电池跑三个月，我手上的STM32L4+AI推理任务，实测待机电流2.3mA——按这个功耗，电池撑不过两周。更讽刺的是，AI模型在PC上跑得飞起，一部署到MCU上，CPU就像打了鸡血一样全速运转，功耗直接起飞。这不是个例。很多工程师把AI模型塞进MCU后，发现功耗比裸跑翻了五倍以上。问题出在哪？不是STM32Cube.AI不行，而是我们没理解“AI推理”和“MCU功耗管理”之间的微妙关系。今天这篇笔记，就聊聊我踩过的坑和最终找到的解决方案。第一个坑：CPU跑满100%的真相STM32Cube.AI生成的代码，默认行为是“尽快完成推理”。这听起来没毛病，但代价是CPU在推理期间以最高频率全速运行。如果你的模型推理需要50ms，CPU就在这50ms内保持80MHz甚至更高频率。对于电池供电设备，这种“短时高功耗”的累积效应非常致命。我最初的做法：在推理前后手动调整时钟频率。比如推理前切到80MHz，推理完立刻降到2MHz。但实测发现，切换时钟本身有延迟，而且频繁切换反而增加了额外功耗。更坑的是，STM32Cube.AI生成的推理函数内部可能调用了硬件加速器（如M4的FPU或M7的SIMD），这些外设在低频率下效率反而下降。正确的思路：不是降频，而是让推理任务“匹配”系统空闲时间。比如你的设备每100m
