ESP32-C6 Power Battle: Arduino vs Zephyr vs ESP-IDF
ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
I tested the ESP32-C6 across Arduino, Zephyr, and ESP-IDF to see how software choices impact battery life. Without manual optimization, ESP-IDF delivered the lowest power usage, while Zephyr incurred a performance tax for its portability. Surprisingly, Arduino's idle state consumed significantly more energy than its active tasks, and a simple coding error triggered a system crash detectable via power spikes.
Software bugs are not just functional failures; they are energetic events.
- gsliepen
> execute instructions faster (via -O3)
One problem with -O3 is that it disregards any effects of the cache (and yes, ESP32s have a bit of cache memory). I recommend using -Os as the default optimization level, as it often has the same or almost the same performance benefits as -O3. Less cache pressure is beneficial, especially for bigger applications, and the smaller code size is of course nice on embedded systems that have limited amounts of flash storage. If you know some specific functions or source files are performance sensitive, you can use pragmas to change optimization for those:
#pragma GCC optimize("O3")
See https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-.... Clang has a similar pragma, see https://clang.llvm.org/docs/LanguageExtensions.html#extensio....
- maufl
I did something similar, but less scientific, comparing ESP-IDF and esp-hal (Rust). Unfortunately I learned that the optimizations that are already in ESP-IDF (most of all automatic light sleep between BLE advertisments) are hard to replicate in Rust/esp-hal/embassy and so for battery powered devices you might want to stick to C++/ESP-IDF
- dlcarrier
It highlights that an idle loop in Arduino is energetically detrimental.
That's not particularly uncommon. Many compilers or OSes default to wait loops when there's nothing to do, and they can be pretty power hungry.