I spent the latest three or four months doing embedded programming. After using extensively the ESP8266 and ESP32, now I'm quite certain I prefer big times the RP2040 (that is, the Raspberry Pico processor, but you can find it in different non-Raspberry produced development boards). The reasons are easy to summarize:
1. Vastly superior C SDK, and even the MicroPython support appears to have an edge.
2. Fantastic documentation, even if in PDF form, which makes a bit less accessible for us and especially for LLMs training data crawlers. In general LLMs know a great deal more about ESP stuff than the RP2040.
3. Almost every RP2040 can be overclocked to 400Mhz and work stable, and I could say basically every RP2040 can be stable at 350Mhz, so when comparing performances, account for this.
4. Very smart hardware capabilities: state machines for programmable pins (PIOs), great DMA support, hardware interpolators.
5. High quality hardware, and if you don't need the version with wireless, the cost is still quite reasonable. 3/4 euros/dollars per piece.
6. When you need the "W" one, the wireless chip the Pico uses has its own ARM processor, so you continue to have the two RP2040 cores spare for your application.
7. Memory mapped flash with execute in place. You can read from 0x1000000+offset just deferencing a pointer and that's it, you access your flash.
8. More GPIOs available.
The big disadvantage of the RP2040:
No SPI RAM support. At this point many ESP32 boards have built-in SPI and this makes memory a lot less a scarse resource.
To familiarize with the ESP family is useful since they are everywhere and are extremely cheap for what they offer. But still, I would start basically any new project where I have choice with the RP2040.
> Almost every RP2040 can be overclocked to 400Mhz and work stable
If you're playing with overclocking the RP2040 it's good to know that the flash chip might not be able to keep up with those higher clocks though, which leads to inscrutable crashes, and of course the official documentation doesn't endorse overclocking so they don't tell you how to work around that. The flash runs on a configurable clock divider defaulting to 4, so if you're running the CPU at double the nominal clock you can raise the divider to 8 to keep the flash running at its original speed.
What I do here (https://github.com/antirez/zx2040/) is: stay overclocked when not accessing the flash, downclock when accessing the flash via memory map, return back to the higher clock. Works without issues. I find this method to work more reliably than dividing the clock in practice. Maybe I did something wrong dividing the clock so it was not stable, but the system I described really works flawlessy.
Never said that it's a good thing that LLMs know less. It's a negative thing and I suspect it's like that because of good documentation in PDF format. So you usually need a lot less help in forums, and the doc itself is less discoverable.
The Pico has 2MB to 16MB on board flash with XIP in all the configurations AFAIK.
Fantastic documentation, even if in PDF form, which makes a bit less accessible for us and especially for LLMs training data crawlers. In general LLMs know a great deal more about ESP stuff than the RP2040.
came across to me, as if the entire item was a reason why you prefer the RP2040-based systems.
And I meant that the microcontroller itself (the RP2040 chip) lacks built-in flash. I realize it's on the boards instead, that is the thing I personally don't like since you can never have a single-chip solution.
You can downclock the Pico as you can overclock it in order to reduce power usage. By default AFAIK it already more or less matches the ESP32 power usage, and downclocking it should be able to reach the one of the ESP8266, likely, but I'm not sure.
The RP2040 doesn't have a good low power sleep mode. It uses several hundred uA in sleep and dormant mode versus the ESP8266 which uses only 20uA in deep sleep.
This makes a huge difference for sensor systems etc. A pico/RP2040 cannot be powered by a battery for very long.
I never tried to explore the Pico deep sleep indeed. I used it with esp32 with great results even if the wake time of 200 ms does not make certain applications viable. Thanks for the point.
Personally I'd like the option to give up a core for wifi/bluetooth. The pico boards are a little ungainly, and having an rp2040 plus radio in a single package would be nice.
1. Vastly superior C SDK, and even the MicroPython support appears to have an edge.
2. Fantastic documentation, even if in PDF form, which makes a bit less accessible for us and especially for LLMs training data crawlers. In general LLMs know a great deal more about ESP stuff than the RP2040.
3. Almost every RP2040 can be overclocked to 400Mhz and work stable, and I could say basically every RP2040 can be stable at 350Mhz, so when comparing performances, account for this.
4. Very smart hardware capabilities: state machines for programmable pins (PIOs), great DMA support, hardware interpolators.
5. High quality hardware, and if you don't need the version with wireless, the cost is still quite reasonable. 3/4 euros/dollars per piece.
6. When you need the "W" one, the wireless chip the Pico uses has its own ARM processor, so you continue to have the two RP2040 cores spare for your application.
7. Memory mapped flash with execute in place. You can read from 0x1000000+offset just deferencing a pointer and that's it, you access your flash.
8. More GPIOs available.
The big disadvantage of the RP2040:
No SPI RAM support. At this point many ESP32 boards have built-in SPI and this makes memory a lot less a scarse resource.
To familiarize with the ESP family is useful since they are everywhere and are extremely cheap for what they offer. But still, I would start basically any new project where I have choice with the RP2040.