Note: these seem to be still the 'A2' silicon stepping, notable for having a number of silicon bugs [1], most notable of which is GPIO-E9 which affects the use of built-in pull-down resistors on inputs.
It's still an excellent chip and I'm looking forward to using it in my designs, but beware of these limitations.
The E9 errata has evolved since the early days when the built-in pull-downs were implicated. The issue is related to the input pad macro sourcing excess (120uA) current when the external voltage is between Vil and Vih. This causes the pad to float at 2.2V, whether the built-in pulldown is activated or not. The internal pulldowns don't sink enough current to force the voltage outside of the undefined range.
I really, really want to like the RP2350. The PIO machines punch so far above their weight that they could turn the chip into a killer solution in a lot of circumstances.
This single erratum breaks my intuition enough that I'm "scared" to pull the chip into a design. I understand that they don't automatically break most use cases and that there are software workarounds. But they violate a core "Hi-Z is Hi-Z" understanding that I design around, and I'd really hate to respin a board over something so dumb. On an STM32 this would have been a silicon stepping and that's what bugs me about it.
My take is that devastating errata is just normal. Most of it is fixed silently and the end users never hear about it, but sometimes you're the customer that gets to find them. Right before I joined an embedded device team at Google, they brought up a new chip. Turns out... branch prediction was broken. It would mispredict a branch and execute the misprediction anyway. I imagine that was no fun to debug. But a workaround was fine and I'm sure subsequent customers never heard about it, and the devices worked fine for many years.
One time I lived in an apartment that suffered from a variety of pests coming in. I expanding-foamed everything that looked like an entry point, the problem went away, and I stopped caring. However, I could still hear mice crawling around inside the walls late at night and decided just not to be bothered. This experience prepares one for embedded systems / microcontroller work ;)
I mean, it's normal for like half of the peripheral functionality on STM micros to outright not work. But usually that’s something relatively niche like the CAN transceiver or the DMA controller targeting a particular MMIO range or some specific mode of the external memory interface. Having an erratum affecting literally all GPIO pins is unusually scary.
The RP2350B is the exact same chip just in a larger package with all GPIOs exposed (from 30 to 48 GPIOs). It's the same silicon though with the same E9 errata.
I'm sad these seem to not have the fix for the E9 errata, making them entirely unsuitable for a lot of projects. I'll keep using the RP2040 instead, but the extra oomph of the M33's over the M0+'s would've been very welcome in a few places.
I have 0 experience in ASIC design, but it's not clear to me that this is fixable at all with just metal layer changes (which are around $50K a pop) like the fixes to previous errata's of the rp2040.
And a complete set of new masks at 40nm would probably cost them around $1M which I can't imagine would make financial sense for them, unless their contract with the pad designer includes compensation for that kind of issue.
So sadly I don't think this is likely to get fixed.
$1m is peanuts if your making chips. They should have done a respin for such a fundamental issue. This errata will be one of the first things you see when you research the part even if they later fix it. You can see even here it's half the discussion so far.
The RP2350 is 2.65x the die size of the RP2040, so about 8000 chips per 3000$ TSMC 40nm wafer gives you $~0.35 per die. Say 10 cents per die for singulation and testing, and another 10 cents for packaging and processing into reels. I have no idea what the M33 per-unit license is, but something like 5-10 cents seems reasonable, so let's assume 5.
So that's a cost of $0.60 with a reel price of $0.80 for a $0.20 gross profit per chip. So the break even point for full respin of the masks is around 5 million sold chips, 10 million chips when we're including the original masks. For comparison, according to Eben Upton, 10 million RP2040s have been made (but not necessarily sold) from 2021 to 2023.
Would a fix result in 5 million additional chips being sold? Maybe, and for all we know they could be working on doing that just now. Maybe their contract with the pad design provider even pays for a new mask set and it actually costs them nothing. Maybe all of this can be fixed with a cheaper metal layer fix.
But either way this isn't 'peanuts' and it's not a clear cut if doing it is economically viable.
I can't really even understand what the defect is - what kind of projects does it affect? I'm only interested in fairly basic applications of the rpi but I don't have the technical chops to know if I'm setting myself up for failure...
So normally when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in'). The bug is that if the external voltage is between 1V and 2.5V (I don't remember the exact voltages, don't quote me on that) the pin will SOURCE current, acting almost as if you'd set it to be an output pin. It's not a lot of current, but it's enough to hold the pin at 2.2V.
This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
For some circuits that's fine, for others it's more problematic.
> This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
Many microcontrollers provide an internal, selectable pull-up or pull-down resistor (or neither). For example, on the STM32, it's a 30-50k, and individually selectable on a per-pin basis:
It's normal for pins to float, it's not normal for them to both lack an internal bias option and to float to a condition where they source significant current. You don't typically put a very low impedance external pull-down resistor on every single input pin.
> when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in').
That's not how it works; input does not mean sink current. An OUTPUT low sinks current, and an output high sources current.
In a "normal" microcontroller (with no silicon bugs), an input pin is in a high-impedance state ("Hi-Z"), meaning it doesn't sink or source current -- but it can be configured to have an internal pull-up or pull-down resistor, in which case it will (respectively) source or sink a little bit of current, enough to keep it at high or low voltage (i.e., enough for a logical high or low) unless there's something else driving it.
The problem with the RP2350 is that (under some circumstances) there's a current leakage between the pin and the voltage rail, so when a pin is configured as input with a pull-down resistor, the voltage will not go down to the low level it needs to read a logical low as expected: it will be at around 2.2V, which is in the "undefined" region.
You are, of course, 100% correct. In my haste to explain the 'sourcing' behaviour of the errata I accidentally jumped to the sinking verbiage. Input pins are "pressure gauges", not "flow meters".
Simplifed when used as digital input a GPIO pin has three voltage ranges: 0V up to the logical low threshold, VCC down to the logical high threshold, and an and undefined range in the middle. The RP2350 burns a lot of power while in this middle range when any proper MCU shouldn't, because its quite common for this to happen. The "cure" is almost as bad as the problem because to stay out of this range you have to apply a strong external pull-up/pull-down resistor. This too wastes power, just not quite as much.
I haven't completely thought through this, but I can see issues with porting PIO-USB [0] for example. USB relies on a few different pulls to Vcc and Gnd with pre-defined values. On the host side you have to pull your signal lines to ground with 15k resistors. Those aren't strong enough to overcome the current leakage. The tricks where you enabled pad inputs only when you're reading the pin don't work here either as you can't do that in PIO.
Things like logic analyzers are going to have similar issues where their inputs will have to be buffered to provide a suitably low impedance path.
It's not insurmountable but it's enough for me to just fall back on the RP2040 in situations where I don't want to spend the effort to validate the RP2350.
It's not an issue for PIO-USB, since the pullup/pulldowns in USB are just used for device and speed detection. And for the pulldowns to do anything the pins have to be high impedance which you can't do in PIO code anyway. So just making sure to drive the pins low for 1 cycle before putting them in high impedance mode is sufficient as a workaround.
Could be an issue for logic analyzers, though usually you'd have a voltage translator in front of that anyway.
In situations where the power wasted by such a strong external pull-down or pull-up is inacceptable e.g. everything running of a small battery for more than a few hours. The resistors can easily burn more power than the whole chip.
Not only that, they can also run heterogenously, with one core ARM and the other RISC-V (and atomic instructions continue to work!). Not sure why anyone would do this, but I do appreciate that it's possible.
I've been playing with the HSTX (High Speed Serial Transmit) peripheral lately and it's craziness too.
They have a DDR (Double Data Rate) system that allows you to generate signals from bitstream shift registers that are twice the speed of the system clock.
This means one can generate ~300-400MHz signals from these ~$1 ICs.
Run this with the PIO subsystem, dual core 150MHz, Floating Point hardware, 512K (of expandable) SRAM and massive storage options.
Absolutely wild device and unlike most chips that are half-as-capable, cheap enough to stock up on in case of future supply chain disruptions...
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!
What bugs me is I ordered two PI recently (Canada) and both got fried by the power adapter that came with it. It’ll be a while until I buy another one. That was a real bummer.
Note: these seem to be still the 'A2' silicon stepping, notable for having a number of silicon bugs [1], most notable of which is GPIO-E9 which affects the use of built-in pull-down resistors on inputs.
It's still an excellent chip and I'm looking forward to using it in my designs, but beware of these limitations.
[1] - https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p... p. 1350
The E9 errata has evolved since the early days when the built-in pull-downs were implicated. The issue is related to the input pad macro sourcing excess (120uA) current when the external voltage is between Vil and Vih. This causes the pad to float at 2.2V, whether the built-in pulldown is activated or not. The internal pulldowns don't sink enough current to force the voltage outside of the undefined range.
I really, really want to like the RP2350. The PIO machines punch so far above their weight that they could turn the chip into a killer solution in a lot of circumstances.
This single erratum breaks my intuition enough that I'm "scared" to pull the chip into a design. I understand that they don't automatically break most use cases and that there are software workarounds. But they violate a core "Hi-Z is Hi-Z" understanding that I design around, and I'd really hate to respin a board over something so dumb. On an STM32 this would have been a silicon stepping and that's what bugs me about it.
My take is that devastating errata is just normal. Most of it is fixed silently and the end users never hear about it, but sometimes you're the customer that gets to find them. Right before I joined an embedded device team at Google, they brought up a new chip. Turns out... branch prediction was broken. It would mispredict a branch and execute the misprediction anyway. I imagine that was no fun to debug. But a workaround was fine and I'm sure subsequent customers never heard about it, and the devices worked fine for many years.
One time I lived in an apartment that suffered from a variety of pests coming in. I expanding-foamed everything that looked like an entry point, the problem went away, and I stopped caring. However, I could still hear mice crawling around inside the walls late at night and decided just not to be bothered. This experience prepares one for embedded systems / microcontroller work ;)
I mean, it's normal for like half of the peripheral functionality on STM micros to outright not work. But usually that’s something relatively niche like the CAN transceiver or the DMA controller targeting a particular MMIO range or some specific mode of the external memory interface. Having an erratum affecting literally all GPIO pins is unusually scary.
Am I hallucinating the B variant mentioned, or does it also include this problem?
The RP2350B is the exact same chip just in a larger package with all GPIOs exposed (from 30 to 48 GPIOs). It's the same silicon though with the same E9 errata.
Thank you.
I'm sad these seem to not have the fix for the E9 errata, making them entirely unsuitable for a lot of projects. I'll keep using the RP2040 instead, but the extra oomph of the M33's over the M0+'s would've been very welcome in a few places.
The errata from the datasheet: "Increased leakage current on Bank 0 GPIO when pad input is enabled" which affects RP2350 A2.
Previous discussion: https://news.ycombinator.com/item?id=41479261
I have 0 experience in ASIC design, but it's not clear to me that this is fixable at all with just metal layer changes (which are around $50K a pop) like the fixes to previous errata's of the rp2040.
And a complete set of new masks at 40nm would probably cost them around $1M which I can't imagine would make financial sense for them, unless their contract with the pad designer includes compensation for that kind of issue.
So sadly I don't think this is likely to get fixed.
$1m is peanuts if your making chips. They should have done a respin for such a fundamental issue. This errata will be one of the first things you see when you research the part even if they later fix it. You can see even here it's half the discussion so far.
I don't see how it would be 'peanuts'.
The RP2350 is 2.65x the die size of the RP2040, so about 8000 chips per 3000$ TSMC 40nm wafer gives you $~0.35 per die. Say 10 cents per die for singulation and testing, and another 10 cents for packaging and processing into reels. I have no idea what the M33 per-unit license is, but something like 5-10 cents seems reasonable, so let's assume 5.
So that's a cost of $0.60 with a reel price of $0.80 for a $0.20 gross profit per chip. So the break even point for full respin of the masks is around 5 million sold chips, 10 million chips when we're including the original masks. For comparison, according to Eben Upton, 10 million RP2040s have been made (but not necessarily sold) from 2021 to 2023.
Would a fix result in 5 million additional chips being sold? Maybe, and for all we know they could be working on doing that just now. Maybe their contract with the pad design provider even pays for a new mask set and it actually costs them nothing. Maybe all of this can be fixed with a cheaper metal layer fix.
But either way this isn't 'peanuts' and it's not a clear cut if doing it is economically viable.
> $1m is peanuts if your making chips
Having customers use an external pull-down is free (to the foundation) and costs nano-peanuts to each customer (i.e. cents per unit)
I can't really even understand what the defect is - what kind of projects does it affect? I'm only interested in fairly basic applications of the rpi but I don't have the technical chops to know if I'm setting myself up for failure...
So normally when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in'). The bug is that if the external voltage is between 1V and 2.5V (I don't remember the exact voltages, don't quote me on that) the pin will SOURCE current, acting almost as if you'd set it to be an output pin. It's not a lot of current, but it's enough to hold the pin at 2.2V.
This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
For some circuits that's fine, for others it's more problematic.
> This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
Many microcontrollers provide an internal, selectable pull-up or pull-down resistor (or neither). For example, on the STM32, it's a 30-50k, and individually selectable on a per-pin basis:
https://www.keil.com/dd/docs/datashts/st/stm32f10xxx.pdf#G11...
It's normal for pins to float, it's not normal for them to both lack an internal bias option and to float to a condition where they source significant current. You don't typically put a very low impedance external pull-down resistor on every single input pin.
> when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in').
That's not how it works; input does not mean sink current. An OUTPUT low sinks current, and an output high sources current.
In a "normal" microcontroller (with no silicon bugs), an input pin is in a high-impedance state ("Hi-Z"), meaning it doesn't sink or source current -- but it can be configured to have an internal pull-up or pull-down resistor, in which case it will (respectively) source or sink a little bit of current, enough to keep it at high or low voltage (i.e., enough for a logical high or low) unless there's something else driving it.
The problem with the RP2350 is that (under some circumstances) there's a current leakage between the pin and the voltage rail, so when a pin is configured as input with a pull-down resistor, the voltage will not go down to the low level it needs to read a logical low as expected: it will be at around 2.2V, which is in the "undefined" region.
You are, of course, 100% correct. In my haste to explain the 'sourcing' behaviour of the errata I accidentally jumped to the sinking verbiage. Input pins are "pressure gauges", not "flow meters".
Simplifed when used as digital input a GPIO pin has three voltage ranges: 0V up to the logical low threshold, VCC down to the logical high threshold, and an and undefined range in the middle. The RP2350 burns a lot of power while in this middle range when any proper MCU shouldn't, because its quite common for this to happen. The "cure" is almost as bad as the problem because to stay out of this range you have to apply a strong external pull-up/pull-down resistor. This too wastes power, just not quite as much.
In what situations is including an external pull-down resistor not a good enough 'fix'?
I haven't completely thought through this, but I can see issues with porting PIO-USB [0] for example. USB relies on a few different pulls to Vcc and Gnd with pre-defined values. On the host side you have to pull your signal lines to ground with 15k resistors. Those aren't strong enough to overcome the current leakage. The tricks where you enabled pad inputs only when you're reading the pin don't work here either as you can't do that in PIO.
Things like logic analyzers are going to have similar issues where their inputs will have to be buffered to provide a suitably low impedance path.
It's not insurmountable but it's enough for me to just fall back on the RP2040 in situations where I don't want to spend the effort to validate the RP2350.
0: https://github.com/sekigon-gonnoc/Pico-PIO-USB
It's not an issue for PIO-USB, since the pullup/pulldowns in USB are just used for device and speed detection. And for the pulldowns to do anything the pins have to be high impedance which you can't do in PIO code anyway. So just making sure to drive the pins low for 1 cycle before putting them in high impedance mode is sufficient as a workaround.
Could be an issue for logic analyzers, though usually you'd have a voltage translator in front of that anyway.
In situations where the power wasted by such a strong external pull-down or pull-up is inacceptable e.g. everything running of a small battery for more than a few hours. The resistors can easily burn more power than the whole chip.
These can apparently run as RISC-V dualcore too; it's selected at boot-time (!!). I did not realize that this is a thing.
Was hoping for big improvements for the ADC, but its still limited to 500k/s (they did give it 4 more channels, though, which is nice).
Not only that, they can also run heterogenously, with one core ARM and the other RISC-V (and atomic instructions continue to work!). Not sure why anyone would do this, but I do appreciate that it's possible.
I've been playing with the HSTX (High Speed Serial Transmit) peripheral lately and it's craziness too.
They have a DDR (Double Data Rate) system that allows you to generate signals from bitstream shift registers that are twice the speed of the system clock.
This means one can generate ~300-400MHz signals from these ~$1 ICs.
Run this with the PIO subsystem, dual core 150MHz, Floating Point hardware, 512K (of expandable) SRAM and massive storage options.
Absolutely wild device and unlike most chips that are half-as-capable, cheap enough to stock up on in case of future supply chain disruptions...
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:
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.
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.
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! :)
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.
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 ...
A bunch of my video game controllers are built on RP2040s. Maybe that's just network effects, but it clearly found a niche there.
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.
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.
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!
Official post: https://www.raspberrypi.com/news/rp2350-now-available-to-buy... (https://news.ycombinator.com/item?id=43388904)
Is there a non-paywall version of this article?
[dead]
What bugs me is I ordered two PI recently (Canada) and both got fried by the power adapter that came with it. It’ll be a while until I buy another one. That was a real bummer.
These have nothing to do with the subject at hand (RP2350 microcontroller, not the Pi single board computers).