同一段程序省下三分之一电：单片机调压调频的账怎么算

编译自 MDPI Technologies 2025, 13(2), 82　·　开放获取 CC BY 4.0

电池供电的端侧设备大多活在同一个循环里：采一段数据，算一遍，把结果发出去，然后睡到下一个周期。这个循环看起来没什么可优化的空间，因为采样率是传感器定的，处理量是算法定的。但如果把主控的供电电压和时钟频率当成两个可以逐任务调整的参数，同一段程序在不同任务阶段用不同的配置运行，一个工作周期的总能耗会出现三分之一以上的差距。

塞萨洛尼基亚里士多德大学的一篇论文用一颗 RP2040 微控制器把这件事从头测了一遍。作者关心的不是某一种省电技巧，而是把任务按性质分成两类，分别给出配置策略，再用功率分析仪把账算清楚。

能耗跟着电压平方走

数字系统的能耗与供电电压和时钟频率强相关，其中对电压的依赖是平方级的。这意味着降低供电电压带来的收益，会以平方的方式体现在能耗上，代价则是能跑到的最高频率跟着下降。两者之间的取舍，构成了动态电压频率缩放这项技术的全部内容。

论文选择的任务模型很典型：周期性地采集音频、做一次快速傅里叶变换或自相关运算、通过 Wi-Fi 发送一小段结果，最后进入休眠。硬件平台是一颗 RP2040，双核 ARM Cortex-M0+，264 KB 静态存储，带可编程输入输出。外设包括一颗 PDM 数字麦克风，需要 1 至 3 MHz 的时钟并由可编程输入输出配合直接内存访问驱动，以及一个 ESP-01 无线模块，每次发送 19 字节的数据，包含时间戳、浮点数、长整型和一个 16 位整数。

芯片内核电压可以软件动态调整，范围从 0.85 V 到 1.30 V，步进 0.05 V，默认值 1.10 V，板级供电为 3.3 V。论文先把每个电压档位能稳定运行的最高频率测了一遍：0.85 V 对应 150 MHz 的最高频率与 140 MHz 的实测最稳定频率，1.30 V 则能到 436 MHz 与 416 MHz。在这个基础上选出四组配置用于后续对比：高配置 1.30 V 配 416 MHz，中配置 1.05 V 配 260 MHz，低配置 0.85 V 配 140 MHz，以及同样是 0.85 V 但只跑 20 MHz 的慢配置。

图1　RP2040 内核电压与可运行频率的对应关系及四组测试配置（依据原文表 1、表 6 绘制）

两类任务，两套配置

论文把任务按时间约束的来源分成两类。处理型任务需要执行固定数量的时钟周期，完成时间完全由频率决定，比如滤波器与变换运算。这类任务的最优策略是选一个能够满足时序约束的最低电压，并在这个电压下跑它支持的最高频率。论文用 50 阶有限冲激响应滤波器做了验证：高配置下耗时 111.9 ms、平均电流 283.37 mA、能耗 30.8 mJ；中配置耗时 178.9 ms、平均电流降到 48.2 mA、能耗 28.5 mJ；低配置耗时拉长到 349.8 ms，平均电流进一步降到 23.77 mA，能耗降到 27.4 mJ。耗时翻了三倍，能耗却只降了一成左右。

固定时长型任务是另一回事。采样与无线发送的时间由采样率和传输频率等外部因素决定，与主频无关。比如要采集 4000 个样本、采样率 4 kHz，那么采样过程无论主频多高都需要 1 秒。这类任务的能耗主要产生在时钟边沿，所以策略完全反过来：用能支撑功能的最低频率和最低工作电压，把时钟周期数压到最少。实测显示这类任务的能耗随频率近似线性增长。

停机省电还是快跑省电

降频并不是在所有场景下都省电。论文用一颗 ATmega328p 做了边界验证：在同一个电压下把频率降下来，周期时间变长，中间会插入空闲时间，而空闲期间器件仍要消耗漏电功耗，低频运行时甚至能观察到明显的漏电凸起。换句话说，单看一个时钟周期，降频反而增加了能耗。

但看整个工作周期，结论会翻转。如果休眠功耗低于漏电功耗，那么越快完成任务、越早进入休眠就越省电。论文给出了 RP2040 在 0.85 V 下的实测数据：以 4000 点自相关运算为负载，归一化工作周期为 31.314 秒，32 MHz 时活动能耗 686 mJ、漏电功耗 14.3 mW、休眠功耗接近零，总能耗 686 mJ；64 MHz 时活动能耗降到 554 mJ，中间睡了 11.669 秒，总能耗 645 mJ；140 MHz 时活动能耗只有 341 mJ，总能耗降到 366 mJ。速度提升四倍多，总能耗下降近一半。论文还测了 0 到 60 摄氏度范围内的漏电与休眠功耗，漏电功耗始终高于休眠功耗，这个结论在温度波动下依然成立。

图2　四组配置的实测能耗与两个场景下的优化收益（依据原文表 7 至表 13 绘制）

两个场景下的实测收益

测量用的是 Power Profiler Kit 2，采样率 100 ksps，配合 8 路数字通道。为了在电流波形上切出每个任务的边界，论文用 4 个通用输入输出引脚输出 4 位二进制任务标识，比如 0001 代表录音、1111 代表唤醒，数据导出为表格后用脚本计算平均电流、任务时长与整周期能耗。

四组配置跑同一段程序的实测结果差异明显。把各任务能耗单独累加，高配置 4.33 J、中配置 3.55 J、低配置 3.10 J，而慢配置反而升到 4.36 J。把整周期统一拉长到 135 秒并计入休眠之后，高配置 5.490 J、中配置 4.536 J、低配置 3.942 J、慢配置 5.502 J。唤醒本身也有成本，从中配置的 63.34 ms、9.610 mJ 到慢配置的 740.68 ms、22.110 mJ，差距接近两个数量级，这也是慢配置在长周期下并不划算的原因之一。

真正体现策略价值的是两个带时序约束的场景。第一个场景设定工作周期 20 秒，采样约占 1.5 秒、通信约占 4.5 秒，处理必须在 14 秒内完成，因此处理阶段至少需要中配置。把采样、通信与休眠都交给慢配置，处理交给中配置，整周期能耗降到 2.947 J，比不做优化的方案省下 33%，比用高配置做定点优化还低 5%。第二个场景把周期放宽到 30 秒，处理阶段可以用低配置，整周期能耗进一步降到 2.884 J，相比不做优化最多省 36%。

论文的局限写得很明确：研究只做裸机编程，没有涉及操作系统或实时操作系统的调度特性；应用场景限定在本地处理，没有考虑把计算卸载到云端；温度覆盖范围只有 0 到 60 摄氏度。不过对做端侧设备的人来说，这套方法的价值不在于某个具体数字，而在于那个分类视角：先判断任务的时间约束来自哪里，再决定是压电压还是压频率，这一步想清楚了，剩下的工作就只是把配置表填进调度里。