Hacker News Reader

Comment by dgacmu | Hacker News Reader

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.

View on HN

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.

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!

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.

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.

Reply on news.ycombinator.com