我之前完成对树莓派Zero 2 W的评测时,提到过后续会测试主板的功耗。花了一段时间测试后,我终于完成了这部分测试。并且我还通过来自 Qoitech 公司的Otii Arc和Otii 软件生成了一些功耗图表,以及一些能源消耗图表。由于树莓派基金会推荐使用 5V/2.5A 的电源,所以我就先尝试用接近 2.5A的电源,然后使用一些小技巧将空闲功耗降低到了 75 mA/375 mW 以下。最后,我再检查在不同CPU核心数和频率下的能耗。
带附件树莓派Zero 2 W的负载功耗
我本次的测试是从最新的树莓派OS Lite“Bullseye”镜像开始的,接着我就将树莓派 Zero 2 W 板连接到了 Qoitech Otii Arc 工具上,如下所示。Qoitech Otii Arc 工具之前的价格500美元左右,但现在更高了,起价是 699 美元。对于开发电池供电设备的人来说,Qoitech Otii Arc 真的是一个很好的工具。虽然它的价格有点过高了,但就篇文章的目的来说,它真的很适合使用。

接下来,我打开树莓派,并使用我刚刚刷入且未经任何修改的镜像来检查空闲功耗的情况。

其功耗大约是 120 mA @ 5V、600 mW。如果你对之前树莓派 Zero 2 W 的评测有印象的话,可能会记得看到过比这还低的功耗值。那其实是因为我使用的是树莓派 OS Bullseye 镜像而不是 Buster 镜像,这一点我在本文后面会给大家详细解释。

我还用了一个树莓派Zero(没有 WiFi),它使用的也是相同镜像,空闲状态下的功耗是108 mA。对了,Otii Arc 还有另一个巧妙的功能,就是将功率测量数据与串行控制台同步。因此,我就连接了杜邦线用来访问 Otii 程序中的串行控制台。

我还在 config.txt 中启用了 UART:
1 |
enable_uart=1 |
接着,我通过SSH在 microSD 卡上创建一个空的/boot/ssh文件。这其实是因为 Otii 中的串口控制台使用起来不是很方便、没有历史记录,而且之后的测试中还需要运行vim 或 raspbi-config 之类的程序,所以我依旧通过 SSH 做很多工作。除非我需要匹配带有 V/A 数据的串行控制台输出,我才会去改变。在这些都修改了之后,功耗就上升到了 125 mA。
我通过连接USB以太网、WiFi、USB 硬盘驱动器和连接 HDMI 线等方式,查看了每个附件是如何影响功耗的。我将这些数值显示与闲置的进行了对比,就可以得出每个项目大约的额外功耗(mA)。
增加值 | 评测 | |
---|---|---|
USB 以太网加密狗 | +104 mA | 没有网络连接,只有一个 USB 以太网加密狗插入 |
USB 以太网加密狗 + link | +180 mA | 插入以太网电缆后 |
USB 以太网加密狗 + iperf | +244 mA | 平均值见下表了解详情 |
2.4 GHz WiFi | +11 mA | 连接到 2.4 GHz 接入点 |
2.4 GHz WiFi + iperf | +187 mA | 平均值,详情见下表 |
用于键盘/鼠标的罗技 RF 加密狗 | +29 mA | |
希捷 USB 硬盘(空闲) | +255 mA | 稳定的电流,在初始插入后达到峰值 1.06。详情见下表 |
希捷 USB 硬盘(iozone) | +554 mA | 平均值,详情见下表 |
HDMI线 | +7 mA | 请注意,这只是在插入电缆之后,而不是启用/禁用 HDMI。详情见下表 |
对比来看,WiFi比以太网更节能,尤其是在空闲时的时候更加的明显。硬盘驱动器在最初连接时会消耗很多电量,不过连接 HDMI 电缆对功耗产生的影响就很小。
Iperf(网络性能测试工具)中以太网图表显示的电压和电流一开始都是稳定的,但大约20秒后莫名其妙地波动了一点,我在想是不是因为一段时间后会发生数据包冲突。过程中,还有一个 516 mA 的短尖峰,这可能是与另一个进程有关的。

不过,WiFi 的“噪音”要大得多,在数据传输期间电流会在 160 到 480 mA 之间快速振荡。总能量略低于以太网,但传输的数据就较少。

连接 USB 硬盘驱动器可以得到一个漂亮的图表,开始时电流消耗高达 1.06A,然后是挂载分区时的峰值。一段时间后,系统平均稳定到 386 mA。

由于iozone(文件系统的benchmark工具)无法在树莓派 OS 上使用 apt 安装,我就使用了之前在树莓派 4 评测中相同的步骤来构建 iozone 3.492。

我也很难查看控制台写入方式的细节,但似乎写入的功耗比读取的更多。为了检查负载下的功率和能耗,我使用了从 Otii 串行控制台启动Tomas Kaiser的SBC Bench 脚本。

我们可以清楚地看到右侧多线程 7-zip 压缩/解压缩的测试,其功耗更高,峰值接近 600 mA。

如果我们在串行控制台中选择“tinybench”和“cpufreq OPP”之间的文本,就可以看到实际基准测试(不包括安装和执行后)使用了 328 mWh 的能量,峰值是 624 mA,运行时间为14 分 17 秒。我们先将这些数值记下来,因为我们稍后会用到。
到目前为止,我们得到的峰值是 1.06 A,距离2.5A 的目标还很远。因此,我要尝试使用一下树莓派 OS Desktop。

得到的结果是:平均值为 124 mA,与 Lite 图像大致相同,但在 300 mA 附近出现了许多尖峰。
如果我连接一个 HDMI 显示器,平均电流会上升到 131 mA。这个想法其实就是通过 USB 集线器来连接 USB 以太网、USB 硬件、键盘、鼠标来对系统进行压力测试,但我的 USB 集线器都不能与树莓派树莓派 Zero 2 W 配合使用:
1 2 3 4 5 6 7 8 |
241458 - [ 67.054308] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? 241465 - [ 67.054406] Indeed it is in host mode hprt0 = 00021501 241470 - [ 67.194343] Indeed it is in host mode hprt0 = 00021501 241475 - [ 67.474308] Indeed it is in host mode hprt0 = 00021501 241480 - [ 67.754293] Indeed it is in host mode hprt0 = 00021501 241485 - [ 68.034321] Indeed it is in host mode hprt0 = 00021501 241491 - [ 68.314287] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? 241497 - [ 68.314344] usb usb1-port1: attempt power cycle |
所以这一部分我就放弃了,只是将 USB 驱动器连接到 USB OTG 端口和 WiFi 上。
1 2 |
sudo apt install stress-ng stress-ng --cpu 0 --cpu-method fft |
我本来还计划做一些播放 YouTube 视频、运行 3D 图形的基准测试,比如 OpenArena,但这对于只有 512MB 的 RAM 来说似乎要求有点太多了。OpenArena 可以启动,我也可以选择“演示”,但是在加载演示时它毫无意外地崩溃了。因此,我改成了运行 es2gears(它似乎可以运行软件渲染器),接着插入了硬盘,运行了 iozone和stress-ng(模拟系统负载升高的压力测试工具)。这就意味着es2gears、iozone 和stress-ng 都在同时运行。

这样操作之后,最大值达到了 1.35A,距离推荐使用的 5V/2.5A 电源仍有足够的余量。虽然我测试时间比上面的截图更长,但我在 1.46A 处至少有一个峰值。如果我先运行stress-ng,然后插入USB 驱动器,我们的峰值可能会更高一些,我估计是1.7 或1.8A。我敢肯定,如果我从硬盘驱动器播放视频、运行 3D 图形演示、且保证stress-ng运行,那么此时电流硬就可以更接近 2.5A 了。不过,因为我没有可用的 USB 集线器,也没有蓝牙键盘,因此完成这个测试还是很有挑战性的。但不管怎么说,这也就意味着在大多数情况下,使用较弱的电源(即使是 5V/1A)对树莓派 Zero 2 W来说足够了。我无法测试 MIPI CSI 摄像头接口,因为我没有。
降低树莓派Zero 2 W功耗
现在我们回到树莓派 OS Lite 镜像,保证只启用 UART 和 SSH,我们可以看到板子空闲且没有运行其他任何东西时功耗为125 mA。我又尝试了一些修改方法来降低功耗,主要是通过 raspi-config 实用程序和编辑 config.txt。我还将树莓派 RP3A0 强制定为 600 MHz。
1 |
arm_freq=600 |
其实,我不指望空闲功耗会有所改进。而事实上,我也通过一些方式测试到了它有 127 mA的功耗。接着,我通过将内存设置为 16 来完全禁用 GPU:
1 |
gpu_mem=16 |
空闲时平均的功耗仍是 127 mA。理论上我们是可以通过在 config.txt 中添加以下几行来禁用 LED 的:
1 2 3 |
# Disable the ACT LED on the Pi Zero. dtparam=act_led_trigger=none dtparam=act_led_activelow=on |
但是,无论我怎么进行第二行设置都不起作用,无论是闭还是打开。但我可以从命令行手动关闭 LED:
1 2 |
$ echo none | sudo tee /sys/class/leds/led0/trigger $ echo 1 | sudo tee /sys/class/leds/led0/brightness |
这项改动会将电流减少1mA,使之达到 126mA,或大约 5mW。还有一点非常奇怪,就是有时我必须运行以下命令才能关闭 LED:
1 |
$ echo 0 | sudo tee /sys/class/leds/led0/brightness |
现在我们在 config.txt 中尝试禁用音频、WiFi 和蓝牙以及摄像头/显示器来自动检测一下,如下所示:
1 2 3 4 5 6 7 8 9 |
# Enable audio (loads snd_bcm2835) dtparam=audio=off dtoverlay=disable-bt dtoverlay=disable-wifi # Automatically load overlays for detected cameras camera_auto_detect=0 # Automatically load overlays for detected DSI displays display_auto_detect=0 |
这时功耗降到了 114 mA,而不是我们第一次在没有修改的情况下运行镜像的 125 mA。也就是默认设置,没有 WiFi,但启用了 SSH 和 UART。这帮助节省了 9 mA 的电流。
另一个技巧是使用以下命令来禁用 HDMI:
1 |
/usr/bin/tvservice -o |
由于树莓派 OS Bullseye 中有用于 3D 图形新标准的 KMS 视频驱动程序,它显然无法正常工作:
1 2 3 4 |
/usr/bin/tvservice -o /usr/bin/tvservice is not supported when using the vc4-kms-v3d driver. Similar features are available with standard linux tools such as modetest from libdrm-tests. |
接下来,我们可以去raspi-config修改,也就是在“ Advanced options->GL driver ”里面安装一些包,然后可以选择“ G1 Legacy ”。

它会将 config.txt 从:
1 2 3 |
# Enable DRM VC4 V3D driver dtoverlay=vc4-kms-v3d max_framebuffers=2 |
到
1 2 3 |
# Enable DRM VC4 V3D driver #dtoverlay=vc4-kms-v3d max_framebuffers=2 |
现在终于有点感觉了!它的功耗下降到了 92.7mA,最低甚至能到 21mA,而且我还没有禁用 HDMI 输出:
1 2 |
/usr/bin/tvservice -o Powering off HDMI |
禁用HDMI之后,功耗下降到了75.5 mA,最低约 17 mA。如果你想在启动时自动禁用 HDMI,请将这一行添加到/etc/rc.local文件中。这也是我最终关闭 LED 的地方(不要问我为什么,我不需要运行该行,所以就将其设置为了 0 或 1),如下所示:
1 2 3 4 5 6 7 8 9 |
# Print the IP address _IP=$(hostname -I) || true if [ "$_IP" ]; then printf "My IP address is %s\n" "$_IP" fi /usr/bin/tvservice -o echo none | sudo tee /sys/class/leds/led0/trigger exit 0 |
对了,我还有一个技巧,虽然可能不会大幅降低空闲功耗,但是 Jeff Geerling 提供了禁用 cores 的说明,所以我们还是尝试一下,修改/boot/cmdline.txt以将内核数限制为 1,maxcpus=1:
1 |
console=serial0,115200 console=tty1 maxcpus=1 root=PARTUUID=9105aa44-02 rootfstype=ext4 fsck.repair=yes rootwait |
事实证明,这项修改是有效的,因为现在我们只能在 /proc/cpuinfo 中看到一个核心:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
2235650 - [?2004hpi@raspberrypi:~$ cat /proc/cpuinfo 2238007 - [?2004l 2238036 - processor: 0 2238037 - model name: ARMv7 Processor rev 4 (v7l) 2238041 - BogoMIPS: 38.40 2238043 - Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 2238051 - CPU implementer: 0x41 2238053 - CPU architecture: 7 2238055 - CPU variant: 0x0 2238057 - CPU part: 0xd03 2238058 - CPU revision: 4 2238058 - 2238060 - Hardware: BCM2835 2238062 - Revision: 902120 2238064 - Serial: 00000000e51cb671 2238066 - Model: Raspberry Pi Zero 2 Rev 1.0 |
那么这时的功耗如何呢?是74.6 mA。因此,在空闲功耗方面,一个核心可能的好处会比较有限。现在我们试试禁用 SSH:
1 |
sudo apt purge openssh-server |
以及 UART,看看我们功耗是否可以达到 70 mA。

遗憾的是,它并没有多大帮助,因为我在空闲时只能达到 74.5 mA。我想可能还有其他一些优化发放,因为我偶尔会看到 100 mA 的尖峰。某些处理器具有一些低功耗模式,其中所有应用程序内核和某些块都可以根据需要关闭/打开各种睡眠模式。但我找不到 Broadcom BCM2837 / BCM2710A 处理器的任何内容。
能耗使用
现在让我们看看是否可以通过调整频率和使用的内核数量来降低能耗。这对电池操作来说还是很有用的。我使用 WiFi、SSH 以及我们启用的一些优化以默认频率 (1.0 GHz) 重新运行带有四个内核的 SBC bench,从而检查它如何影响能耗使用。作为参考,此配置中的空闲功耗略低于 80mA。

完整的结果可以在http://ix.io/3HrM中找到。这其实挺奇怪的,因为 338mWh 使用的能量比我们第一次没有优化状态下运行(328 mWh)的略多,而且测试需要 16 分 49 秒才能完成(对比 14:17),其最大电流消耗是 635 mA。刚开始我以为我没有保存第一个结果,但幸运的是,我保存了功率测量值。而且 Otii 保留了串行输出,因此我可以恢复第一个结果@ http://ix.io/3H54。
快速检查 7-Zip 来比较第一次的运行情况,如下所示:
1 |
Total: 2968,2961,2972 |
第二个:
1 |
Total: 2996,2975,2988 |
该测试展示了一些最小的性能差异。

我比较了 Meld 中的两个输出,除了启用了 KMS 驱动程序之外,我看不出有太大区别。并且第一次运行时空闲百分比较高,第二次运行时 iowait 百分比略高。
无论如何,我们还是尝试切换使用 600 Mhz 的四核,看看我们是否可以在运行相同任务的同时节省能耗并延长电池寿命。

完整的结果:http : //ix.io/3HrU。有趣的是,331mWh 使用的能耗几乎是相同的(仍然少 7 mWh,但与第一次运行 @ 1.0 GHz 相似),测试时间与预期时间相似,即 23 分 18 秒。其最大功耗仅 449 mA,这意味着该板子可以通过具有此工作负载的路由器或计算机的 USB 端口安全地供电。
接下来,我们以 600 MHz 的单核配置来进行最后一次的测试。

完整结果:http : //ix.io/3Hsg。能耗高很多,为483 mWh。也许是因为7-zip在单核系统上处理“多核”压缩/解压的方式不同导致的区别,我暂时还不知道具体原因。不出所料,完成所有测试确实需要更长的时间,时间为 43 分 50 秒。所以,其唯一的潜在优势应该就是最大电流消耗了,消耗仅为 349 mA。不过,由于三个内核被关闭了,该测试结果也是我们能预料到的。
后来,在评论区与读者们进行讨论后,我意识到了由于空闲电流消耗,我应该在相同的测试时间内对能耗进行测量。因此我就利用前两个场景的 80 mA 空闲功耗,并将结果调整为了43分50秒,这样就可以更好地比较差异:
- 4x 内核 @ 1,000 MHz:338 mWh (16:49) + 180 mWh (27:01) = 518 mWh
- 4x 内核 @ 600 MHz:331 mWh (23:18) + 137 mWh (20:32) = 468 mWh
- 1x 内核 @ 600 MHz:483 mWh
这其实就意味着我们在这里模拟了一个工作负载,其中的sbc-bench约每44分钟会在板上运行一次,当然这不包括安装和后续的基准测试活动。所以,实际结果显然还是取决于你特定的应用程序或者工作负载。
我暂时就测试了这些内容,如果你还需要我测试其他东西,可以随时问我。因为我还没把桌子上的试验台收起来,要进行相关的测试是很简单的。

文章翻译者:Jacob,嵌入式系统测试工程师、RAK高级工程师,物联网行业多年工作经验,熟悉嵌入式开发、测试各个环节,对不同产品有自己专业的分析与评估。