ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
1–10 of 21 posts
Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#2 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.Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#3It 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.
Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#4Unsurprisingly, the old, non-standard, encumbered architecture is not missed.
Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#5One 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....Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#6Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#7Re: ESP32-C6 Power Consumption: Arduino vs. Zephyr vs. ESP-IDF Comparison
#8It 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.
But one thing the article didn't point out is what hardware peripherals each firmware activated by default. Eg, activating UART might use default pins and activate an UART RX on a pin, which might incur a mA-order penalty. Hence, a useful first step in optimizing power is to identify what functionality you need and ensure all else is always powered down (eg uart rx, clocks and timers, radio peripherals.