Pico Serial Bootloader (2021)

The ESP32 requires closed source binary blobs, RP2040 does not. For a lot of projects, it is important to keep these things separate.

RP2040 is a bitbanging monster with 8x PIO cores operating at clock frequency. RP2040 can even bitbang DVI easily. It can output nearly 4 Gbps at the nominal 125 MHz frequency.

While a great chip ESP32 doesn't come close matching RP2040 PIO's power in this aspect.

Other considerations aside, he says the robot is an entry for Pi Wars 2022.

The Pi Wars rules state:

"The core controller of the robot should be a Raspberry Pi. This includes all microcomputer models of the Pi (such as the Pi 3, Pi 4, Pi Zero, Compute Module) and also the Raspberry Pi Pico."

and

"Additional Microcontrollers, such as Arduinos, micro:bits etc may be used on the robot but the Raspberry Pi must be in overall control"

https://piwars.org/2022-competition/general-rules/

Insane internal bandwidth for the price (in theory you can sustain 4 x 32 bit memory transfers per cycle) and good for digital I/O. Its a < $1 chip with enough pins to be useful. If you already have a ESP32 or similar sized MCU it can be cheaper to add a RP2040 (booting of SPI or SWD) than a more specialised chip. While the PIO is sometimes dismissed as a NeoPixel accelerator it can be used to implement most serial and parallel busses with minimal CPU cycles and perfect timing.

The RP2040 is extremely easy to design hardware for, has excellent documentation and toolchain support, and provides a wide variety of peripherals. Meanwhile, most ESP32 variants don't even have USB and depend on a custom proprietary toolchain.

For applications where Bluetooth or WiFi are needed, the ESP32 is obviously a way better chip. But the RP2040 is also a dual core MCU, its speed at 133MHz isn't anything to scoff at either, and it is genuinely a pleasure to work with. I'd take the RP2040 over the ESP32 any day of the week.

It's for a Pi Wars robot. A robot that has to be driven by a Pi chip. AFAIK the ESP32 is made by Espressif, not the Pi Foundation.

Additionally, I've learned that when it comes to part choices, especially microcontrollers, just because another part is "more right" it doesn't make your choice wrong.

1) Significantly better Rust support.

2) Doesn't require dealing with the madness that is ESP-IDF (terrible build system, runtime interrupt allocation, ...)

3) Simpler and cheaper.

I had a project where I needed predictable timing for I/O (reading a microprocessor’s bus at 1 MHz), and the ESP32 I was using just couldn’t do it reliably. Despite having a tight loop on a dedicated core with interrupts disabled, a loop iteration would sometimes take longer than a microsecond, causing it to miss some I/O. I was able to do it much more reliably with RP2040’s PIO.

For another project, the ESP32 family unfortunately doesn’t have a model that has both Bluetooth Classic (only the original ESP32 does) and USB host/device modes (only ESP32-S2 and ESP32-S3 do), so I’m thinking I’ll use the RP2040 as the main processor, with USB, and an ESP32 coprocessor. I really would rather just use a single ESP32, but that isn’t looking like an option here.

This probably comes down to my lack of skill and knowledge, but the RP2040 has been a far more productive platform for me to just get shit done.

I wanted to love the ESP32 because it seemed objectively better, but despite trying, I couldn’t get my tool chain and process to be reliable and productive. Admittedly, part of that is probably due to working on a Mac. That hasn’t been an issue with the RP2040 though, and neither has anything else, really.

I sometimes feel silly using either of them because the stuff I make could work fine with even less power and certainly less IO. We’re spoiled these days. In my case though, I’d be fine with plenty of boards; the nicest development experience just happened to be on the pi.

Use microcontrollers in more advanced way than "load a SDK and bitbang some pins" and you will know.

Having certain peripherals can make some projects go from hard to easy. Power usage can also be huge factor, althought of course if you already have ESP32 on board those aren't exactly great for that.

Like, if you're making motor driver, you probably gonna want some featureful counters with good PWM options, maybe even some floating point instructions if you do something fancy. Probably also good ADCs.

But that needs to be often run realtime or near-realtime so having Wifi/BT stack can add you some headache, both in analog (interference) and digital domain (making sure wifi interrupt wont break timings on rest of your code).

Lastly division of responsibilities is easier to code. ESP32 part for example can focus entirely on wifi/UI/APIs, while the controlled MCU can do just the control and talking with ESP32.