11–20 of 21 posts
> 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 t…
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
As an off-topic remark, I've used the qoitech arc power analyzer quite a bit and it's quite nice and easy to use, when your DUT is <5V and low amps. There's also the Nordic PPK2 kit, which is cheaper but I haven't tried it. Both are aiming at the crowd that prefers a simple, handles-most-use-cases, little USB-connected box that runs the client on your computer, rather than a separate bulky thing with screen and whatn…
ESP32 never was good for any powersaving applications.
> 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 t…
> 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 t…
GCC has historically been a bit of a pig about -Os, my favorite example is on x86 where it will emit a runtime divide for a division by a compile time constant power of two because it saves a byte of text!
int fn(int n)
{
return n / 8;
}
0000000000000000 :
0: 89 f8 mov %edi,%eax
2: b9 08 00 00 00 mov $0x8,%ecx
7: 99 cltd
8: f7 f9 idiv %ecx
a: c3 ret
0000000000000000 :
0: 8d 47 07 lea 0x7(%rdi),%eax
3: 85 ff test %edi,%edi
5: 0f 49 c7 cmovns %edi,%eax
8: c1 f8 03 sar $0x3,%eax
b: c3 retI 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
ESP32 never was good for any powersaving applications.
While the ESP32 does have a high inrush current, its ULP coprocessor is quite capable, drawing only 12µA@3.3V during Deep Sleep. I have a fleet of AA-powered ESP32 devices at home that last 6–12 months, plus some solar-powered ones that run indefinitely.
I've not gotten around to trying, but I assume using deep sleep while waking up to batch send data with infrequent updates would be key.
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.