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
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?
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...
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.
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.
More details here: https://pico-adc.markomo.me/
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:
https://www.raspberrypi.com/products/rp2040/
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.
It's like XMOS but actually usable.
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.
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.
That said it's not a good fit for wireless keyboards, that niche is served by ZMK running on nRF chips.
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.
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.