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.
The Pico W also has WiFi and Bluetooth (-LE) on board.
With that in mind, what would make ESP32 a better chip if using WiFi / Bluetooth? (apart from cpu clock)
Any particular features that make ESP32 or Pico W stand out for <insert application here> ?
What I mean to say: with the RP2040 being an excellent chip to design with, and the Pico W flavour adding WiFi + Bluetooth, what reason(s) if any to add ESP32 to that?
(I could understand ESP32 may better suit some applications stand-alone, for ...reasons)
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.
Yes RO2040 is very good in that regard. It is often hard to gauge from processor clock how fast it will toggle its pins. Example PI4 - I do not think I was able to get more than 5MHz from its GPIOs and this is 4x GHz class processor.
The blob is the low-level wireless firmware, and regulatory rules make it obligatory. When you use the ESP32 as a dumb modem in conjunction with a separate MCU, you‘re still running the blob. You have gained nothing.
True, and I‘ll buy that argument if your main firmware is memory safe (Rust, verified C or smth else without an unsafe C runtime underneath). Otherwise its just mine vs someone else’s C, and people have traditionally been overconfident on theirs.
Strong isolation gives fault tolerance not otherwise available, no matter the language. If one part crashes, the other part is not necessarily affected, unlike the situation without good isolation.
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.
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"
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.
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.
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.
> 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.
You should either:
* have a timer triggering interrupt that reads the data
* have a timer triggering DMA from the input port (if it was whole 8/16 bit) directly to memory
* trigger an interrupt with microprocessor's clock bus and read it directly.
Technically the 2nd one should have zero jitter (aside from clock itself).
Busy loop is the worst case on a microprocessor running RTOS to do the other stuff.
Depends what poster above did. If they are just monitoring something at constant rate "just" low jitter" is enough.
No idea if ESP32 DMA engine can do it but common trick to get either constant rate input or output was just setting DMA engine to copy data from/to IO port to/from memory at constant rate.
I remember someone using it to drive some ridiculus number of RGB LEDs by basically using DMA to bitbang multiple chains of them at once
But yeah, using a simpler MCU as basically IO co-processor is usually simpler. I wish there was some kind of low pin bus that allowed to say directly map a part of memory to the chip on other side, akin to what RDMA does.
I needed to detect writes to a bus that could happen at 1MHz, which involved reading the state of the bus multiple times per microsecond (based on the timing of the various signals). The jitter in the worst case was multiple microseconds (causing missed accesses), no matter what I tried.
I wasn’t able to use DMA on the ESP32 to help— perhaps it could have if I had tried to massage the problem a little bit more though.
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.
Don’t get me wrong the RP2040 is a fantastic chip. But the ESP32 is a dual core MCU running at 240MHz!
Edit to add - you can also flash the ESP32 wirelessly with an OTA update.