HN Debrief

ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison

  • Hardware
  • Programming
  • Developer Tools
  • Open Source

The post compares power consumption on an ESP32-C6 across three software stacks: Arduino, Zephyr, and ESP-IDF. It looks at the same basic application and reports that Arduino burns notably more power at idle, while ESP-IDF comes out ahead. The useful read on the results is not that one ecosystem is universally efficient and another is sloppy. It is that default behavior matters a lot on microcontrollers, especially around idle handling and built-in power-saving features.

Do not treat framework-level power benchmarks as portable truth unless they also document sleep states, enabled peripherals, and board-level extras. If you ship battery devices, profile your exact firmware and hardware stack early, because defaults like idle loops, UART, radios, and dev-board LEDs can dominate the budget.

Discussion mood

Cautious and practical. People found the measurements interesting, but most saw them as a defaults benchmark rather than a definitive verdict on the frameworks or the ESP32-C6, and several comments stressed that sleep states, peripherals, and dev-board hardware can outweigh the software stack choice.

Key insights

  1. 01

    Idle power mostly reflects missing sleep

    Idle current here is dominated by the fact that the firmware never entered power-saving modes, so the MCU stayed in active mode and burned nearly the same power as when doing work. That reframes the Arduino result from a deep architectural flaw to an expected consequence of an ease-of-use stack that does not optimize for battery operation by default.

    When you compare firmware stacks, separate “default idle behavior” from “best achievable low power.” Add at least one benchmark that explicitly enables sleep, otherwise you are mostly measuring who spins harder when nothing is happening.

      Attribution:
    • retSava #1
    • dlcarrier #1
    • mbanzi #1
  2. 02

    Peripherals and dev boards can swamp framework differences

    Enabled UARTs, clocks, timers, radio blocks, and board extras like LEDs can easily add milliamp-scale overhead. Once those are left on, the framework comparison stops being about scheduler design or compiler output and starts being about whatever hardware was quietly powered at boot.

    Build a power checklist for every board bring-up. Audit default peripherals, kill unused blocks early in boot, and avoid drawing conclusions from dev-board numbers unless you account for support circuitry.

      Attribution:
    • retSava #1
    • nottorp #1
  3. 03

    Vendor stacks hide hard-won BLE sleep tricks

    ESP-IDF already includes optimizations like automatic light sleep between BLE advertisements, and one commenter said reproducing that behavior in Rust with esp-hal and Embassy is difficult. That is a reminder that the biggest power wins are often buried in mature vendor integrations, not in the language or framework surface that developers see first.

    If wireless battery life is central, test against the vendor stack before committing to an alternative runtime. You may decide the productivity gain is worth it, but you should price in the engineering cost of rebuilding low-power behavior yourself.

      Attribution:
    • maufl #1
  4. 04

    Compiler flags are not a free power knob

    Using -O3 to finish work faster does not automatically reduce energy use on parts with cache, because larger code can increase cache pressure and erase the benefit. A commenter recommended -Os as the safer default for embedded work, with targeted O3 on hot functions, while another warned that GCC’s size optimization can get so aggressive that it emits slower code than LLVM would for the same case.

    Do not assume a global optimization level will minimize energy. Measure with your actual compiler, and mix size and speed settings at the file or function level where it pays off.

      Attribution:
    • gsliepen #1
    • jcalvinowens #1

Against the grain

  1. 01

    ESP32 can still work on batteries

    The blanket claim that ESP32 is bad for power-sensitive devices breaks down once deep sleep and the ULP coprocessor are in play. A commenter cited 12 microamp deep sleep on the ULP path and described AA-powered devices lasting 6 to 12 months, plus solar-powered units that run indefinitely.

    Do not rule out ESP32 from battery products based on active-mode reputation alone. Model the full duty cycle, especially sleep time, wake frequency, and peak current constraints on your power source.

      Attribution:
    • usagisushi #1
    • SuperMouse #1
  2. 02

    Zephyr results raise bigger concerns upstream

    Poor out-of-box power behavior in Zephyr worries some readers because Linux often sits above the same embedded hardware stack. The point is not that Linux and Zephyr are directly comparable on microcontrollers. It is that if a system built for constrained devices still leaves waste on the table, larger stacks may hide even more of it.

    If your product mixes microcontroller firmware with Linux-based subsystems, do not assume the RTOS side is the only place worth auditing. Power regression testing should cover the entire stack, including the supposedly “trimmed down” Linux side.

      Attribution:
    • dsign #1

In plain english

-O3 ↩
A compiler optimization setting that prioritizes execution speed, often by applying more aggressive code transformations.
-Os ↩
A compiler optimization setting that tries to reduce code size while still applying many performance optimizations.
Arduino ↩
A popular embedded development platform and software framework designed to make microcontroller programming easy to start with.
BLE ↩
Bluetooth Low Energy, a low-power version of Bluetooth used for short-range wireless communication.
Embassy ↩
An asynchronous embedded framework for Rust used to build firmware for microcontrollers.
esp-hal ↩
A hardware abstraction layer for ESP chips in Rust that provides low-level access to the microcontroller hardware.
ESP-IDF ↩
Espressif Internet of Things Development Framework, the official software development kit for ESP32 chips.
ESP32-C6 ↩
A Wi-Fi and Bluetooth microcontroller from Espressif, used in embedded and Internet of Things devices.
GCC ↩
GNU Compiler Collection, a widely used set of compilers for languages like C and C++.
LLVM ↩
A major open source compiler infrastructure project that includes the Clang C and C++ compiler.
UART ↩
Universal Asynchronous Receiver-Transmitter, a common hardware interface for serial communication between devices.
ULP coprocessor ↩
Ultra Low Power coprocessor, a small auxiliary processor that can run limited tasks while the main chip stays in deep sleep.
Zephyr ↩
An open source real-time operating system for embedded devices and microcontrollers.

Reference links

Compiler optimization references