ESP32-C6 power consumption: Arduino vs Zephyr vs ESP-IDF comparison

Skip to main content

.js-accordion" uk-scrollspy-nav="closest: li; scroll: true;">

Products

View all products

Otii Ace Pro

Otii Arc Pro

Otii Battery Toolbox

Otii Automation Toolbox

Use cases

Resources

Download

Documentation

Support

Tech articles

Book a tech demo

Buy

User

ESP32-C6 power consumption: Arduino vs Zephyr vs ESP-IDF comparison

ESP32-C6 power consumption: Arduino vs Zephyr vs ESP-IDF comparison

Created: July 1, 2026<br>Updated: July 3, 2026

Introduction

The rapid evolution of the Internet of Things has shifted the focus from mere connectivity to energy sustainability. Microcontrollers such as the ESP32-C6 [1], featuring a modern RISC-V architecture and advanced wireless capabilities (Wi-Fi 6, Thread, BLE), are increasingly deployed in edge-computing scenarios where battery replacement is impractical. While hardware efficiency is frequently prioritized during the design phase, the software abstraction layer provided by the SDK plays a critical role in the final energy footprint of a device [2].

A poorly optimized software layer can negate the low-power benefits of modern silicon by keeping peripherals active, mismanaging clock scaling, or introducing unnecessary processor wake-ups. This paper presents the initial ESP32-C6 power consumption analysis of the ESP32-C6 operating under three popular frameworks: Arduino (prioritizing ease of use), Zephyr RTOS (prioritizing industrial portability), and ESP-IDF (prioritizing native hardware access).

Experimental setup and methodology

Hardware and measurement architecture

To ensure a fair and reproducible comparison, a standardized testing pipeline was implemented. The Device Under Test (DUT) is an ESP32-C6 Development Board, powered at a constant 3.6V by the Otii Ace power profiler. Data were captured across four synchronized channels: Main Current, Main Power, Main Voltage, and UART RX.

Fig. 1. Device under test (DUT) connection with Otii Ace and UART synchronization

The testing protocol relies on a tiered baseline approach to isolate SDK overhead from user code:

Empty Scenario: A "blank" firmware (an infinite empty loop) to observe the default SDK background activity and baseline clock state.

Reference Scenario: A minimal firmware that executes only UART STR and END commands to identify the energy cost of UART synchronization.

Active Workloads:  Basic operations representing common edge-computing tasks: External LED Blink (GPIO management), CRC8 Calculation (sensor data validation), and Floating-point Multiplication (sensor calibration and basic analytics).

Note: Wi-Fi and BLE radios were not actively initialized during any of the test scenarios. This information is important for understanding the background current draw, especially in the Empty Scenario results explained below.

Automated measurement engine

To eliminate human error in measurement timing, a custom automation framework was developed in Python utilizing the Otii TCP API [3]. Each active workload was executed for 5 independent iterations. Each iteration lasted 60 seconds to provide a statistically significant sample size, followed by a 20-second power-off cool-down to prevent thermal drift.

The engine performs real-time margin cropping using Steady-State isolation to discard boot-up current spikes. The valid dataset timeline is calculated as:

𝑇𝑣𝑎𝑙𝑖𝑑=[𝑇𝑠𝑡𝑎𝑟𝑡+𝑡𝑏𝑒𝑓𝑜𝑟𝑒,𝑇𝑒𝑛𝑑−𝑡𝑎𝑓𝑡𝑒𝑟]Tvalid=[Tstart+tbefore,Tend−tafter]

High-resolution samples are exported as NumPy Binary Files (.npy) to preserve floating-point precision, while logs are timestamp-synchronized to the power domain for event correlation.

Zero-optimization policy and toolchains

A strict "Out-of-The-Box" (OOTB) policy was enforced. No manual changes were made to compiler flags, linker scripts, or power management configurations beyond the standard templates. This methodology reflects the default vendor-supplied experience.

It is important to note that this OOTB policy means that light-sleep, deep-sleep, and RTC-only wake modes were not enabled during testing. The reported current values reflect each SDK’s default awake/idle behavior, not the ESP32-C6’s lowest power state. To reach microampere-level power consumption, you need to enable power-saving modes. This comparison did not include that extra optimization step.

Reviewing the compilation artifacts revealed critical differences in the default toolchains utilized by each environment:

ESP-IDF (v5.5 Master): Utilizes GCC 14.2.0 with -O3 (Optimize for Performance).

Arduino (Core v3.3.5): Utilizes GCC 12.2.0 with -Os (Optimize for Size).

Zephyr RTOS (v4.3.99): Utilizes GCC 12.2.0 via West with the -Os flag.

Results: Common workloads and ESP32-C6 power consumption

The following table and subsequent chart summarize the average current consumption across all tested scenarios.

Comparative Current Consumption (Average mA)

Scenario ESP-IDF Arduino Zephyr...