The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.
Things like battery life will probably improve with experience, I was talking to a silicon guy about the RP2040 and they said it's pretty characteristic of a first generation design. The digital logic that can be validated on an FPGA is fine for the most part, but the analog elements are much more difficult to fine tune, hence the poor power consumption, poor ADCs, and lack of internal DACs or opamps in the RP2040, and why the Pico Ws radio is a separate off-the-shelf part rather than fully integrated like it is on the ESP32.
Though it's a continuing puzzle to me why ESPs have worse ADCs than the rp2040, given their relative maturity. (Neither is particularly good, mind you, but I'm generally ok with the rp for my toy applications.)
The vast majority of real, commercial MCUs do not have WiFi in-package. The ESP32 is unique in this regard and is one of its only redeeming features.
I would rather buy the RP2040 and the NRF7001/NRF7002 for the same or less total cost and have a substantially better wireless solution (5.4GHz WiFi 6).
The most annoying part about the PIO is that there are only two of them (though with 4 sub-units each), they only have space for 32 instructions, and they don't have an external clock input.
They are great for implementing very basic peripherals, but more than once I've started to implement something more complex just to realize it would be unacceptably slow and run out of space. If they were to beef them up just a little, they could easily replace the more trivial FPGA applications.
Availability is the star of the show for me. One IC, long product lifetime, always in stock, after the shitshow that was 2021/2022 I'm not going to bother trying to shave a few cents to compromise this again.
Ditto for robotics. 8 PIO units are enough to read and log four quadrature encoders at practically no interrupt cost, so it's possible to build a perfectly performant closed loop controller in something as slow as Micropython.
You don't even need the 8 :), 4 quadrature inputs will fit on one PIO block.
Some lovely person got a quadrature decoder into 24 instructions, so you can potentially still do something useful on the same PIO block if you only need one or two quadrature encoders.
Many, many cheap MCUs have peripherals that can decode quadrature in hardware. E.g, PCNT on ESP32, timer modes on STM32 etc. Might as well use PIO to implement I2C or UART :)
We've been using the RP2040 in the electronic badges[1] for the RVASec security conference[2] for the past several years, and it's been very nice to write software for. Here's the github repo for this year's badge (there's a software-only badge simulator so you can kind of play around with it even without the hardware, although some of the multi-player things that rely on infrared badge-to-badge communication won't be any fun): https://github.com/HackRVA/badge2024
"(This is the same microcontroller, just two bugfix revisions.)"
It is exactly the same microcontroller! They're just two different packaging options. One is a 7" reel with 500 units the other is a 13" reel with 3400 units. (See "Ordering code" in the datasheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...))
That said they have done a few bugfix revisions, RP2040-B0 is the original, -B1 has some refinements to the ROM code, and -B2 has further ROM changes and also fixes some silicon bugs from the earlier versions. If you're using the official SDK you probably don't need to care too much about which version you have though, because the standard high level libraries detect the hardware revision at runtime and enable or disable workarounds as needed.
RP2040 has single handedly reinvigorated a really niche market: custom controllers. Due to the wonderful work done on gp2040[1] which is open source game pad firmware, people can buy cheap, quality, fightsticks and leverless controllers for a lot cheaper than they can from vendors like Victrix or Razer. Not only that but because its open sourced the hobbyist side of the controller community are building RP2040 pcbs to accommodate all kinds of projects and weird controller ideas.
I do wonder how much of that can be accounted directly to the RP2040. Projects like QMK[0] have been using a technically quite similar codebase for making DIY keyboards for quite a while now.
At first glance I'm not really seeing anything in GP2040 which couldn't have been done with any other somewhat-modern MCU. The RP2040 has undoubtedly been the catalyst leading to GP2040's widespread adoption, but it seems the same could've happened with a Pro Micro instead.
Doesn't this discount things like the Brook boards (e.g., Zero-Pi[1]) that came before? I only take issue with "single handedly" because it seems not quite true to the history here.
It doesn't. Brook boards always added like an extra $100 dollars to any custom or DIY fight stick. The reinvigoration came because sticks that used to be $250 new are now closer to $100 and in some cases less, particularly leverless controllers. If you've heard of the Haute 42 or any of the countless leverless controllers that have been flooding Ali Express, Amazon, and other sites they're possible because of the firmware gp2040. For a lot of these new makers all they have to do is get the pcb printed and build an enclosure.
If you are an electronics hobbyist but don't want to make/design your own surface mount boards (like me) there are lots of very accessible RP2040 boards at very low prices.
I've used it in the Raspbery Pi Pico ($5) which comes on a nice board with lots of IO. There is a W version for a bit more with WiFi.
If you don't mind slightly less IO then you can order an RP-2040 Zero. I got 6 off AliExpress for about $12. These only have 23 IO pins but they have a reset button, USB-C and are tiny (1.5cm x 2.5cm).
The nice thing about all of these is that they use the standard Raspberry Pi dev tools, micropython, C++ just works with convenient USB loading of the firmware.
I like to shout out the pico ice. Most of the $30 price tag is for the UP5K tied at the hip, but for embedded projects where you have some sub-microsecond activities it's a (relatively) inexpensive option with open source tooling.
I also highly recommend shopping around for alternative RP2040-based dev boards. The official Pi Pico is surprisingly bad, and just about every alternative out there is better in one way or another.
I mean, come on: no reset, huge form factor, only 2Mbit flash, micro USB - in 2024? Just about the only pro it has is that it is widely available.
The Pi Pico is not a "huge form factor". It fits better on breadboard than pretty much anything with an ESP32 on it (since it's less wide), and it provides access to most of the RP2040 pins. Since the PIO can drive a lot of pins at once, this lets you really unleash the RP2040's power to do things like DVI output. Having access to more pins is something many people consider a plus not a minus.
As to your other points, I wouldn't mind more flash but I don't think the amount it has is particularly small. The micro USB, though, is a disappointment, though.
Given the incompetence in hardware design with nearly every Pi ever released, I'm not sure why anyone would be surprised that the official Pico board is terrible as well.
I mean come on, how do you fuck up USB-PD that badly? Unless you're doing it on purpose to force people to buy special power supplies sold by your vendors...
I love the tiny RP2040 boards. I’ve got a few little projects based on the adafruit QT Py. I do wish there was a wireless version. There is if you use the ESP32 QT, but not RP2040 as far as I can see.
Unless you're incredibly space constrained I don't really get the point of that 2040 Zero, it just costs more for fewer features. The Pico is already pretty tiny.
The Pico is really good at pin interoperability at least, in the land of ESP, what appears to be lots of IO pins quickly turns into barely enough if you're lucky, with pins connected internally to flash or the bootloader or whatever. I really wonder why they even bother breaking those out. The ESP32-CAM comes with 10 data pins, and only 4 of them are actually generally usable lol.
I switched from ESP32 to the RP2040 because it's a much more reliable and documented device. My only concern right now with the RP2040 is that there are many ESP32 models with SPIRAM but it's not so simple to find a SPIRAM equipped RP2040 board. To be honest, given that the C development environment of the RP2040 is so good, you can make good use of the memory, but when one wants to develop a large MicroPython project, the SPIRAM is really a great asset. Other than that, everything about the RP2040 is just great.
I ended up cutting a section on Rust support from the post, but if you're open to Rust (iirc you were sceptical at some point?), async Rust is really pleasant to use in embedded. Dario Nieuwenhuis, one of the main people behind Embassy, gave a great overview talk at RustNL: https://www.youtube.com/watch?v=H7NtzyP9q8E
I disagree. Rust on embedded is fantastic (I do STM32 programming on rust all the time, and have used the RISC-V ESP chips and nRF-52 as well), but Async Rust on embedded suffers from the same problems of contagion and coloring that non-embedded async rust has.
A bit late to the thread but it is still on the front page. I've got some esp32 risc-v eval boards I've meant to mess with, but I'm nervous about their availability due to political instability and also while the rust support seems pretty great, I don't really know what is going on down in the hal and whatnot. Is rust on the 2040 well supported? Is it too well supported? Is it well enough documented that I could start with no software of any sort and load a pure rust blob and have it do some uart or something? My motivation is to recapture the feel of the c64 or Amiga1k wherebthe only mmu is optional page protection at most and you know what everything in memory is doing.
I heavily disagree. I‘ve been working with the Espressif ecosystem for a couple of months now and it‘s the best documented microcontroller platform out there.
You can use Arduino libs via ESP-IDF. The IDF environment comes with a lot of libraries on its own but it is a development environment first and foremost. The design of IDF is very open and easy to understand throughout the stack. It is very easy to integrate external libraries via CMake as well.
The issue is that its a comparison about apples to peaches. The RPI2040 is JUST the chip whereas the ESP32 come with tons of peripherals for your liking.
From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet whatever, Display or Camera Connector - You choose.
And then we have a multitude of even CPU choices and when running on a coin cell it makes a difference powering a second, unnecessary core or even wifi.
And with the C6 variants, Espressif even switches ISA again, from 8266, to ESP32 to a RISC-V based ISA.
So you are comparing the first of its kind SOC with a decade old Family of SBCs.
> The RPI2040 is JUST the chip whereas the ESP32 come with tons of peripherals for your liking.
I think you're mistaking the ESP32 devkits for the ESP32 itself. The thing that comes with an antenna, battery controller and any kind of connector whatsoever is a devkit or at least a module. The ESP32 itself is a small IC just like the RP2040.
Which is itself based on a module (e.g. ESP32-S3-WROOM-1), which just bundles the ESP32-S3 IC with a few niceties (like wifi antenna or connector).
The equivalent for the RP2040 would be the Raspberry Pi Pico, which does come with some minor niceties (like a wifi variant). There are other products that package it with different peripherals.
> So you are comparing the first of its kind SOC with a decade old Family of SBCs.
Neither the RP2040 nor ESP32 series are SBCs and neither has any SBC lineage. The Raspberry Pi SBCs were all Broadcom based, the RP2040 is a brand new IC developed by Raspberry Pi and afaik has no IP licensed by Broadcom.
You're right about the technicals, but I think its about the use cases. RP2040 is indeed one of its kind and is suddenly a great choice for so many projects, both hobby/educational and proffessional embedded devices. With its price vs possibilities it just covers soooo much when You know it's just one single chip version. To me, this is what tech progress is all about.
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.
FYI. In the embedded space, peripherals refer to the chip's built in capabilities. Typically there is a peripheral that handles SPI, a peripheral that handles I2C, a peripheral that handles USART. There might be a peripheral that handles USB, or I2S, or any number of different abilities. It's either transistors or microcode on more sophisticated MCUs that allows these peripherals, and not every pin is connected to every peripheral, which can make chip selection even trickier. It really sucks to start designing around a chip that looks like it does everything you need with enough pins to only find out that once you start doing pin layouts you can't use both USART2 and I2C because they use the same pins. Worse, is when the datasheet makes this difficult to discern, and you only find out when doing some firmware work on a devboard.
Non Chinese as in not made in China? Pretty hard I believe.
As for near equivalent, I recall about the old (and now possibly hard to find) WiFiMCU modules and the W80x MCUs by Winnermicro.
On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application.
On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine, but once you start looking into the details it's easy to run into limitations. That XIP interface is great - but it doesn't support writing so you can't hook up an FRAM chip and expand your memory. That PIO interface is amazing - but having only 2x32 instructions is quite limiting once you try to implement more complex interfaces. And where are my Timer/Counters? No capacitive touch? Analog on only four pins? No 5V tolerance? No high-speed clock input for the PIO modules? Why can't I run the bootloader off the internal ring oscillator? Hmm, a USB-C PHY sure would've been helpful...
I was also surprised about its poor ESD performance. An Atmega or STM32 can handle the occasional zap just fine - ESD protection is more of a nice-to-have on external-facing ports. The RP2040? If you don't add external protection to every single pin you are basically guaranteed to see a few of them die due to day-to-day use.
To summarize: neat chip, great for hobbyists, wouldn't be my first choice in professional environments.
What do you mean by USB-C PHY? USB-C is the connector, and you can run USB 1.1/2.0/3.0/3.1 through it, but realistically a RP2040 can not feed even a USB 2.0 PHY.
A PHY for the USB PD communication over the CC wires. That makes it possible to negotiate things like Alt Modes for a USB-C connector. DIYing one is surprisingly hard due to the voltages and timing involved.
i'm curious what kinds of applications you've found fram most useful for. it seems like a really cool technology, but the price point is so high that i struggle to understand when you'd use it rather than a combination of sram (or psram) and nand
The main application here would be that the RP2040 only has a single XIP QSPI bus. If you extend its memory by hooking up PSRAM to that bus, you can't boot because the chip loads all its code from QSPI. If you hook flash up to that bus, you don't have any way to add extra memory.
FRAM would allow you to have your cake and write it: your application code survives a reboot, and (if the chip were to gain write support) the remaining space could be treated like PSRAM.
I suspect that the Synopsys DesignWare SSI macro in RP2040 can in fact be used for R/W PSRAM or FRAM, but the abridged documentation of it in RP2040 datasheet is not sufficient for one to configure it that way.
Readit News
I would rather buy the RP2040 and the NRF7001/NRF7002 for the same or less total cost and have a substantially better wireless solution (5.4GHz WiFi 6).
Dead Comment
They are great for implementing very basic peripherals, but more than once I've started to implement something more complex just to realize it would be unacceptably slow and run out of space. If they were to beef them up just a little, they could easily replace the more trivial FPGA applications.
The IC will be unobtainable in the next shortage, too.
I mean, don't you remember the shortage before where even capacitors were only hardly available?
Some lovely person got a quadrature decoder into 24 instructions, so you can potentially still do something useful on the same PIO block if you only need one or two quadrature encoders.
If you need a lot of IO - you're probably not looking at ESP32. It's just cheap and has WiFi builtin.
There are many options for other MCUs, that compare favorably to with RP2040... though majority aren't for the hobbyist market.
That's pretty interesting, could you list some?
Nintendo Switch modchip - PicoFly: https://github.com/rehius/usk. That is the OG source of the firmware behind the already mentioned https://github.com/Ansem-SoD/Picofly
OG XBox Modchip - Modxo: https://github.com/shalxmva/modxo (see initial impressions from ModzvilleUSA at https://www.youtube.com/watch?v=uUsov3i6jL0)
XBox360 NAND reader / writer - Picoflasher: https://github.com/X360Tools/PicoFlasher (used in the RGH3 hack for some versions of the console as described at https://consolemods.org/wiki/Xbox_360:RGH/RGH3)
Gamecube Modchip - Picoboot: https://github.com/webhdx/PicoBoot
Gamecube Optical Drive Emulator - Flippydrive: https://github.com/OffBroadway/flippydrive as described at https://teamoffbroadway.com/
https://github.com/polpo/picogus
Emulates all kinds of sound cards, including the Gravis Ultrasound.
https://github.com/FreddyVRetro/ISA-PicoMEM
Emulates a memory extension, but also so much more stuff.
E.g. see https://github.com/Ansem-SoD/Picofly.
>[FlexIO is a] Highly configurable module providing a wide range of functionality including emulation of a variety of communication protocols
It is extremely capable! I have used it to hack together an octo-SPI... which stretches the definition of the S in SPI ;)
[1] https://www.nxp.com/docs/en/supporting-information/FTF-ACC-F...
[1] Video of the 2023 badge: https://www.youtube.com/watch?v=KWZriUMNpLc [2] https://rvasec.com/
It is exactly the same microcontroller! They're just two different packaging options. One is a 7" reel with 500 units the other is a 13" reel with 3400 units. (See "Ordering code" in the datasheet (https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...))
[1] https://gp2040-ce.info
At first glance I'm not really seeing anything in GP2040 which couldn't have been done with any other somewhat-modern MCU. The RP2040 has undoubtedly been the catalyst leading to GP2040's widespread adoption, but it seems the same could've happened with a Pro Micro instead.
[0]: https://github.com/qmk/qmk_firmware
[1] https://www.brookaccessory.com/detail/53169470/
I've used it in the Raspbery Pi Pico ($5) which comes on a nice board with lots of IO. There is a W version for a bit more with WiFi.
If you don't mind slightly less IO then you can order an RP-2040 Zero. I got 6 off AliExpress for about $12. These only have 23 IO pins but they have a reset button, USB-C and are tiny (1.5cm x 2.5cm).
The nice thing about all of these is that they use the standard Raspberry Pi dev tools, micropython, C++ just works with convenient USB loading of the firmware.
I mean, come on: no reset, huge form factor, only 2Mbit flash, micro USB - in 2024? Just about the only pro it has is that it is widely available.
As to your other points, I wouldn't mind more flash but I don't think the amount it has is particularly small. The micro USB, though, is a disappointment, though.
I mean come on, how do you fuck up USB-PD that badly? Unless you're doing it on purpose to force people to buy special power supplies sold by your vendors...
The Pico is really good at pin interoperability at least, in the land of ESP, what appears to be lots of IO pins quickly turns into barely enough if you're lucky, with pins connected internally to flash or the bootloader or whatever. I really wonder why they even bother breaking those out. The ESP32-CAM comes with 10 data pins, and only 4 of them are actually generally usable lol.
JLC will assemble a RP2040 board for you for <$3/pc at quantities of 5.
From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet whatever, Display or Camera Connector - You choose.
And then we have a multitude of even CPU choices and when running on a coin cell it makes a difference powering a second, unnecessary core or even wifi.
And with the C6 variants, Espressif even switches ISA again, from 8266, to ESP32 to a RISC-V based ISA.
So you are comparing the first of its kind SOC with a decade old Family of SBCs.
I think you're mistaking the ESP32 devkits for the ESP32 itself. The thing that comes with an antenna, battery controller and any kind of connector whatsoever is a devkit or at least a module. The ESP32 itself is a small IC just like the RP2040.
For example you might be thinking of a devkit like this: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s...
Which is itself based on a module (e.g. ESP32-S3-WROOM-1), which just bundles the ESP32-S3 IC with a few niceties (like wifi antenna or connector).
The equivalent for the RP2040 would be the Raspberry Pi Pico, which does come with some minor niceties (like a wifi variant). There are other products that package it with different peripherals.
> So you are comparing the first of its kind SOC with a decade old Family of SBCs.
Neither the RP2040 nor ESP32 series are SBCs and neither has any SBC lineage. The Raspberry Pi SBCs were all Broadcom based, the RP2040 is a brand new IC developed by Raspberry Pi and afaik has no IP licensed by Broadcom.
The silicon chip itself for an ESP has:
bluetooth, ethernet, wifi, SD/EMMC, and a bunch more "peripherals" built into it.
The RP2040 does not.
To make this painfully clear:
For an esp32 to do wifi you wire the esp32 to an antenna.
For an RP2040 to do wifi you wire the 2040 to another chip, and that other chip to an antenna.
Do you see the difference?
http://wifimcu.com/
https://github.com/SmartArduino/WiFiMCU
https://www.aliexpress.com/item/1005003456975478.html
For Wifi, the only competition I'm aware of is the wireless STM32 series from ST Microelectronics: https://www.st.com/en/microcontrollers-microprocessors/stm32...
For BT, Nordic's nRF series is pretty popular. In the DIY world, I mostly know it in the form of the nice!nano, a keyboard controller.
On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application.
On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine, but once you start looking into the details it's easy to run into limitations. That XIP interface is great - but it doesn't support writing so you can't hook up an FRAM chip and expand your memory. That PIO interface is amazing - but having only 2x32 instructions is quite limiting once you try to implement more complex interfaces. And where are my Timer/Counters? No capacitive touch? Analog on only four pins? No 5V tolerance? No high-speed clock input for the PIO modules? Why can't I run the bootloader off the internal ring oscillator? Hmm, a USB-C PHY sure would've been helpful...
I was also surprised about its poor ESD performance. An Atmega or STM32 can handle the occasional zap just fine - ESD protection is more of a nice-to-have on external-facing ports. The RP2040? If you don't add external protection to every single pin you are basically guaranteed to see a few of them die due to day-to-day use.
To summarize: neat chip, great for hobbyists, wouldn't be my first choice in professional environments.
With PIO or the SPI master and DMA you could absolutely make use of a USB HS PHY.
IE: if FRAM comes free with your MCU, might as well use it and take advantage of its benefits. For example: MSP430FR4132, just picking one such MCU off of Digikey (https://www.digikey.com/en/products/detail/texas-instruments...)
------
Most of what I know of FRAM comes from TI's marketing pages. https://www.ti.com/document-viewer/lit/html/SSZTA32
FRAM would allow you to have your cake and write it: your application code survives a reboot, and (if the chip were to gain write support) the remaining space could be treated like PSRAM.