Hacker News Reader

Comment by declan_roberts | Hacker News Reader

I've struggled to find a place for the RP2040 and Pico dev boards. ESP32 is just so convenient, cheap, and powerful.

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?

Its known not to have a very good ADC. They did a good job on a lot of the digital aspects but the analogue leaves a lot to be desired.

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.

More details here: https://pico-adc.markomo.me/

Should be noted that this only applies to the rp2040, the ADC silicon bugs were fixed in the rp2350.

That's what I'm using ATM. That ENOB number is ridiculous!

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.

A little more internal RAM would definitely be nice.

Can anyone weigh in on why at least some dozen MB were made available?

*why not more SRAM?

cost and power and latency.

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.

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.

It's like XMOS but actually usable.

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.

Seconded about the datasheets, and thanks for the tips about DMA as double-buffer!

The PIO is very useful. We use the RP2040 in custom devices that encode and decode the "Weigand" protocol, and it wouldn't be easy without the PIO

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.

Not having to deal with the monstrosity that is ESP-IDF is a huge benefit.

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're targeting multiple platforms, you're already in framework territory no? I'd use Zephyr in that case, even more KConfig and CMake!

That's what Big Framework wants you to think so that they can sell you more Framework! :)

Why monstrosity? I've not had any issues and their docker container is quite convenient.

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.

How else do you ensure somewhat consistent CI...? VM images?

A good, hermetic build system. Nix or Bazel or ...

On the contrary, I LOVE using esp-idf via vscode in my hobby project. I was a lifelong Arduino IDE person but I find it clunky after this.

A bunch of my video game controllers are built on RP2040s. Maybe that's just network effects, but it clearly found a niche there.

Same with keyboards, the RP2040 is one of the most popular options for running QMK now.

That said it's not a good fit for wireless keyboards, that niche is served by ZMK running on nRF chips.

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.

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.

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!

Reply on news.ycombinator.com