HyulianGrader

Get meal kits delivered. You still do >80% of the cooking but it takes out all of the planning and shopping.

I was lucky(?) to grow up with a great cook and gardener for a mum, so I'm not even really sure how you exist without doing this at least. Pardon my naivety, but what do you eat...? Is everything unwrapped from plastic or from the local takeaway joint?

I can't be bothered running the datasheet through a translator but there seem to be sleep modes at 2.5uA and 200nA.

Complexity. It's now playing catch up trying to support all of these different chips with all of these different peripherals, capabilities, and errata in quick succession.

As a developer, it's much more difficult to navigate when there are 8 files with the same name, 5 registers with the same name defined in different files, etc. A lot of code is heavily punctuated by ifdefs to selectively include and exclude lines for different targets, making it more difficult to follow. Intellisense struggles, no matter how well it's configured.

I could deal with all that but it's the runtime cost that is the worst. ESP-IDF is constantly getting bigger and slower. All of these abstractions, structs half-full of pointers being handed about at runtime, dead code being linked in for features the chip doesn't even support, it all has a cost.

This is even worse in binary blobs where conditional compilation is more difficult to do. I'm not convinced they're even trying though. A single commit that only mentioned WiFi 6 changes increased my binary size by over 10kB. On a chip that doesn't support WiFi 6.

FYI the RP2040 has peripherals too, a lot of the same ones.

It's very clear that GP has an odd misconception that an ESP32 is some kind of development board complete with "connectors" and possibly a battery charger, while an RP2040 is just the SoC itself.

What part of that contradicts my comment?

To be clear, GP is the one saying the ESP32 is more than just the chip itself, complete with battery controller and camera connector.

No, that's both "just the chip", the chips have different peripherals. They both have the usual SPI, I2C, UART, ADC, etc., and they have their differences too.

I could just as well say "For an RP2040 to do USB you wire the RP2040 to the connector. For an ESP32 to do USB you wire the 32 to another chip, and that other chip to a connector."

It's clear to me GP has the impression that ESP32 is something more (a development board with an ESP32?) than the ESP32 "chip" itself.

It's safe to assume he's talking about the chip in both cases. You can connect either of them to a battery charger, camera, or nuclear reactor but all of those 'peripherals' are completely irrelevant to this comparison.

If you anticipate the need to update the bootloader, you would use a multistage bootloader approach where the first is never altered (as the bootloader should never be altered) and its main function is to select which updatable second stage bootloader to load from multiple options (multiple so that even if one is interrupted mid-update by the application, there is a valid fallback).

My gut says if you're worried about this in the bootloader, it might be doing too much.

Nobody in their right mind is updating a bootloader in the field OTA, let alone one inaccessible on a mountain top.

nit: There are 6 different espressif microcontrollers in that table, not "dozens".

Espressif also went many years with only the ESP8266, then many years more after introducing the ESP32 before this recent binge of releasing a new series every time they blink. ESP-IDF is really suffering for it, so I hope Raspberry avoid this fate or at least find a better way to support them all.

He didn't forget it, he just didn't imagine it could be necessary for any reader but here we are.