It's got a relative ton of memory for a microcontroller, which can make some things really easy
When you combine that with the powerful PIO, you get something that's really solid for:
* Game / system emulation
(You can easily emulate a mac128k on a pico, for example, without having to add an external SRAM.)
* Programming it in Python
(Less need to worry about the memory overhead)
* Projects involving a display and/or possibly very very very simple camera image acquisition and analytics
The ADC isn't too bad either. It's quite a bit better than the one on the ESP32 though worse than what you'll get with a dedicated ADC or those on a lot of 8-bit micros, but then you have to deal with the limitations of programming an atmega or something.
Your comment about the ADC is interesting. I just threw a good-quality 10-turn pot on my Pi Pico the other day for a quick test and the readings were far noisier than I expected, even for a 12-bit input. My immediate assumption was that it was either a board layout problem, or the 3.3V supply was noisy.
I figured I'd get around to looking at the supply on a scope at some point, but you're saying that the ADC itself isn't very good?
You can probably work around this completely by just cranking up the sample frequency and lowpass filtering the value before you use it (if the error is just noise and not bias).
Four times as many samples => half the noise (given some reasonable assumptions).
Personally, I would have really liked to get higher sampling frequency on the ADC. The raspis are quite limited in that regard compared to more "typical" microcontrollers (would expect 1MSPS or more). Supposedly some people had success overclocking the whole peripheral by a factor of 8, but I'm not so sure that is a good idea...
There was also some errata related to the ADC on the 2040 chips. There are specific input values that cause resonant peaks.
n The RP2040 ADC has a DNL that is mostly flat, and below 1 LSB. However at four values — 512, 1,536, 2,560, and 3,584 — the ADC’s DNL error peaks above this value. The ENOB for the ADC has been reduced from 9-bits (simulated) to 8.7-bits (measured), see Section 4.9.3. The DNL errors will somewhat limit the performance of the ADC dependent on use case.
For the record, I love these chips, despite the problems that came up.
The effective number of bits (ENOB) is only ~8.7. Originally designed to have an ENOB of 9+ bits, but silicon bugs lowered it.
There is also some noise from the Pi Pico power supply which could be a good thing if you're willing to average or filter over a large number of samples.
The rp2040 is fabbed at 40nm. It's _really_ expensive to fab on things closer to the cutting edge, and the volume of rp2040/2350 sales simply isn't enough to justify it. (Also, it's harder to design and ends up binding you more tightly to a fab). At 40nm, adding 1MB of SRAM would literally make the chip more than 2x larger, which would increase the cost by quite a bit -- and probably make the SRAM slower. You can see a die shot / layout here:
Notice how much of the area is already SRAM. That's hefty. It would make the chip more expensive without much of a corresponding return on applications enabled. People who need more SRAM can add an external SRAM if they need it.
I frequently have to interface with custom on-the-wire protocols and the PIO block is fantastic. Situations where I'd used to need a CPLD or full-blown FPGA I can now do with a sub-$1 microcontroller. It significantly reduces development time as well.
You'll be hard pressed to find a MCU with better support for fast bitbanging. Any unusual digital bus for which you don't have a fitting peripheral. Both the RP2040 and RP2350 also have a ridiculous per clock memory bandwidth. Instead of one or two memory banks you have >6 SRAM memory banks. This matters if you need jitter free memory accesses.
From a more subjective point of view the peripherals are also less ugly to program for e.g. all DMA channels are created equal (no fixed mappings between DMA channels and peripherals). DMA channels can also trigger each other allowing both flexible double buffering as well as lists of DMA transfers.
Both the datasheet and the SDK code are also a lot more human readable than what you get from other vendors.
It's cheap and beginner friendly and very easy to learn. There is an overwhelming amount of ESP32 boards, variants and software which is daunting when you're just getting into embedded development.
One use case is developing reference boards for homebrew hardware.
https://santroller.tangentmc.net/ is an open source firmware for plastic instruments (think Rock Band and Guitar Hero). Their primary target is the Raspberry Pi Pico.
Each iteration of the games came with their own bespoke controllers, with different circuits; yet at the end of the day, they're all just bags of buttons attached to a microcontroller. Santroller teaches the RP2040 how to convert those button presses to the format various gaming systems expect. Individuals can buy a Pi Pico and some wires to mod their own controller with Santroller. Or, you can go on Etsy, where people have had boards printed for specific guitars. Instead of soldering to a Pi Pico, you can plug the ribbon from your Guitar Hero World Tour guitar onto a RP2040 board that someone had made to accept the ribbons from that specific guitar.
I find this so confusing - I’m working on a fairly large project using ESP-IDF and find it an absolute joy to use. Far better than any other microcontroller framework.
That's the main problem with it - it's a framework.
I don't want a framework that takes over an entire project and mandates the use of a given build system, configuration system, source code structure, etc. This tends to break apart when you want to have more complex build steps; eg. matrix builds, subsequent build actions on artifacts, integration with codegen like string interning, multiple target platforms which are likely not an ESP32 (like a simulation target running on the host), integration with linters/checkers, integration with test frameworks, etc.
And the technology choices ESP-IDF made are also... controversial (CMake and Kconfig! Plus a whole bunch of Python glue to actually make it work together).
Just give me libraries that I can build/link against and let me bring my own build system - or pick a build system that is actually extensible and will scale to more complex scenarios.
If you find it acceptable to use Docker to develop/build projects then you probably have different standards than I do. But see my reply on another subthread for some of my issues with ESP-IDF.
I've been using esp-idf (both professionally and as a hobby) for almost a decade by now and I have not once used Docker.
They even provide you with a fully offline SDK. Extract it and open a terminal and build things. No dependencies, no docker, no nothing.
Your criticism regarding their usage of cmake and the kconfig language hold a bit more water. I've never had any issue with the kconfig system (at least not since they've reimplemented the menu system in python instead of whatever it was) but I have hit CMake limitations a few times.
The PIO functionality, I think, is a killer feature for interfacing with retro consoles. I've been working on a Sega Dreamcast controller adapter and the PIO made it pretty easy to start interfacing with the console's custom protocol, even for somebody with near-zero experience in this kind of thing.
Zmk has pretty good support for rp2xxx. It’s a lot nicer than QMK where you don’t have to write c to make key map. I made a mistake in my pcb and didn’t hook up my SPI display to a spi peripheral, and all I had to do was set up the device tree to make the display use the SPI driver that is implemented in PIO.
As a hobbyist I use it to drive HUB75 LED matrix. I use the W version so it receives UDP packets of each line to draw a full frame. This equates to about ~5mbps at my desired framerate, and it handles the task like a champ!
It's interesting that so many of the replies (and the general sentiment I've seen) mention PIO. And I'd agree, it is a really nice system. Seems they really hit a home run with that idea!
