Raspberry Pi Pico 2 lands with RISC-V cores(theregister.com)
theregister.com
Raspberry Pi Pico 2 lands with RISC-V cores
https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
18 comments
Discussion (250 points, 13 hours ago, 115 comments) https://news.ycombinator.com/item?id=41192341
Remember AMD's Skybridge project? They wanted to put ARM and x86 together on one chip, but they cancelled it. I don't know why, because it seemed like a cool way to bridge the gap. Maybe they were worried it'd become a reverse trojan horse like the Apple Macintosh clones that came about shortly before Steve returned in the 90s.
Seeing as Raspberry Pi has no dog in the game, and simply wants to offer the best product possible, I wouldn't be surprised if this is their intentional way of giving people RISC-V with the intent to allow them time to port their code to it so they can eventually pull the ARM stack. I say this because Jeff Geerling has a video about the Pico 2 where he explicitly says you can only use RISC-V or ARM cores. Not both sets at the same time.
I think it's probably because a full migration to RISC-V would allow them to innovate a bit more and cut prices, although I don't know what the restrictions really are with ARM's IP control and pricing. At $5, every penny counts though.
Seeing as Raspberry Pi has no dog in the game, and simply wants to offer the best product possible, I wouldn't be surprised if this is their intentional way of giving people RISC-V with the intent to allow them time to port their code to it so they can eventually pull the ARM stack. I say this because Jeff Geerling has a video about the Pico 2 where he explicitly says you can only use RISC-V or ARM cores. Not both sets at the same time.
I think it's probably because a full migration to RISC-V would allow them to innovate a bit more and cut prices, although I don't know what the restrictions really are with ARM's IP control and pricing. At $5, every penny counts though.
AMD also had a project to make ARM CPUs that would work with its AM4 x86 socket for Amazon (Project Seattle, replace by Amazon's in-house Graviton). I see the Pico2 in a similar light. If customers want ARM or RISC-V Raspberry Pi has them covered. if the market moves away from ARM, they'll be well positioned.
You can use both at the same time, but you can only use two cores. eg 2xARM, 2xRV, or one of each.
It's incredibly refreshing to see them pricing these at volume costs for non-volume buyers.
The insane component prices that we pay in the US for lower volume electronics manufacturing are killing innovation and driving manufacturing to countries with actual price competition.
Looking on Digikey/Mouser, you'll find that other MCUs with a similar spec are selling for at least $4-5 at qty 3000+.
The RP2350 price is a lot closer to what a large volume buyer would pay for MCUs like this, and still appears to have a healthy margin on top of the cost of dies, packaging, test, etc.
The insane component prices that we pay in the US for lower volume electronics manufacturing are killing innovation and driving manufacturing to countries with actual price competition.
Looking on Digikey/Mouser, you'll find that other MCUs with a similar spec are selling for at least $4-5 at qty 3000+.
The RP2350 price is a lot closer to what a large volume buyer would pay for MCUs like this, and still appears to have a healthy margin on top of the cost of dies, packaging, test, etc.
I disagree.
Small uC is almost entirely about peripherals and RP2040 and RP2350 barely have any peripherals worth talking about.
It's always a weird strategy to me. Rasp. Pi foundation makes a bare bones no-frills chip (most models missing even Flash, fortunately RP2354 has Flash finally) in a field where processing power is not the focus.
MPUs like SAMA5D27 are sub $10 and Linux capable and are still a bad Processing Power per $$$ point because Rasp Pi 5 exists which is bad because AMD Epic exists. If we go down the processing power chain, we simply end up in Server Land.
The traditional use of uCs is to simplify circuit design by having one chip do 90% of any given project. Running BLDC motors? STM32 has BLDC motor uC that handles the 250V or 600V needed. (EDIT: STSPIN32F0602)
You don't need much more than a Cortex-M0+ to drive BLDC either, so all the extra processing power of RP2350 is wasted.
---------
RP2350 is very MPU-ish to me. It requires additional components and reviewers who love it praise features like PSRAM compatibility and talk about how Flash is cheap anyway.
But that ignores that your typical uC doesn't need any external anything aside from maybe Xtals for communication.
Small uC is almost entirely about peripherals and RP2040 and RP2350 barely have any peripherals worth talking about.
It's always a weird strategy to me. Rasp. Pi foundation makes a bare bones no-frills chip (most models missing even Flash, fortunately RP2354 has Flash finally) in a field where processing power is not the focus.
MPUs like SAMA5D27 are sub $10 and Linux capable and are still a bad Processing Power per $$$ point because Rasp Pi 5 exists which is bad because AMD Epic exists. If we go down the processing power chain, we simply end up in Server Land.
The traditional use of uCs is to simplify circuit design by having one chip do 90% of any given project. Running BLDC motors? STM32 has BLDC motor uC that handles the 250V or 600V needed. (EDIT: STSPIN32F0602)
You don't need much more than a Cortex-M0+ to drive BLDC either, so all the extra processing power of RP2350 is wasted.
---------
RP2350 is very MPU-ish to me. It requires additional components and reviewers who love it praise features like PSRAM compatibility and talk about how Flash is cheap anyway.
But that ignores that your typical uC doesn't need any external anything aside from maybe Xtals for communication.
I don't think the Raspberry Pi foundation needs to focus on direct IGBT drive, and there are a lot more tasks in the world than driving BLDC motors.
And yes, there are plenty of highly-specialized microcontrollers that serve a variety of industry niches quite well.
But look at the competitors from ST in RP2354A price bracket of ~$1:
RP2354A, $1 at whatever quantity: Dual 150 MHz CM33, 2MB flash, 520KB SRAM
STM32F103, $0.99 at Qty 1K from LCSC: 72 MHz CM3, 128KB flash, 20KB SRAM.
STM32L431, $0.98 at Qty 1K from LCSC: 80 MHz CM4, 256KB flash, 64KB SRAM.
There are several ST clones from China that are offering a bit more SRAM, a bit higher clock speeds or slightly more flash, like 512KB, but nothing even comes close to the RP2350.
PIO more than makes up for the lack of any digital-specific interface that you think you're missing, not to mention you have an entire extra core just sitting around that you could use to bit-bang whatever crazy interface you decide that you need.
The main area where they are significantly lagging their price-matched competitors is the ADC, and analog in general. I suspect that they are prioritizing limited die area for compute over large analog blocks that are hard to characterize and design on whatever process Sony is giving them.
And if you really need certain specific peripherals (and low-power doesn't matter to you) - capacitive/inductive sensing, DACs, etc., you're almost better off buying a low-spec ultra cheap MCU with the features you need, and then running it as a peripheral to the RP2350. I honestly don't think there's a better price/performance chip out there right now.
And yes, there are plenty of highly-specialized microcontrollers that serve a variety of industry niches quite well.
But look at the competitors from ST in RP2354A price bracket of ~$1:
RP2354A, $1 at whatever quantity: Dual 150 MHz CM33, 2MB flash, 520KB SRAM
STM32F103, $0.99 at Qty 1K from LCSC: 72 MHz CM3, 128KB flash, 20KB SRAM.
STM32L431, $0.98 at Qty 1K from LCSC: 80 MHz CM4, 256KB flash, 64KB SRAM.
There are several ST clones from China that are offering a bit more SRAM, a bit higher clock speeds or slightly more flash, like 512KB, but nothing even comes close to the RP2350.
PIO more than makes up for the lack of any digital-specific interface that you think you're missing, not to mention you have an entire extra core just sitting around that you could use to bit-bang whatever crazy interface you decide that you need.
The main area where they are significantly lagging their price-matched competitors is the ADC, and analog in general. I suspect that they are prioritizing limited die area for compute over large analog blocks that are hard to characterize and design on whatever process Sony is giving them.
And if you really need certain specific peripherals (and low-power doesn't matter to you) - capacitive/inductive sensing, DACs, etc., you're almost better off buying a low-spec ultra cheap MCU with the features you need, and then running it as a peripheral to the RP2350. I honestly don't think there's a better price/performance chip out there right now.
> And if you really need certain specific peripherals (and low-power doesn't matter to you) - capacitive/inductive sensing, DACs, etc., you're almost better off buying a low-spec ultra cheap MCU with the features you need, and then running it as a peripheral to the RP2350. I honestly don't think there's a better price/performance chip out there right now.
Price performance? You're not going to beat DDR2 RAM with microcontrollers..., which I'm seeing at 128MB for $3 or less these days, in terms of price/performance. Once we start talking about price/performance of compute, we very, very quickly rise up the escalation scale all the way to servers.
My point is that uCs exist almost purely because of their analog features. Take the STM32L431: its got 1x OpAmp, 2x DACs, and 5Msps 12-bit ADC at less than $1.
The only other devices that offer as much analog components are other microcontrollers (AVR, PIC, MSP430, MSPM0, etc. etc.). And in most cases, these other microcontrollers have "some niche" that tries to differentiate itself. That's why there's also so many of them, some of them are explicitly designed to be motor-controllers as one example.
--------
What real-world analog task are you looking at that requires 520KB of SRAM? Things are the opposite. Real-world analog-sensing tasks are like temperature-sensors (which take many seconds to change), or at fastest... things like rotation-sensors on a motor (10,000 RPM is 166Hz, even a 1MHz 8051 is sufficient to keep up with 10,000 RPM or 166Hz motors).
In these cases, the most important thing is... having a 2nd DAC. Or having Analog Comparators. Remember that Analog Comparators are 1-bit ADCs really, so those 2x ACs in the STM32L431 kinda-sorta act as an additional independently-running ADC in practice.
If you're using the 12-bit ADC on some important measurement task, its usually nice to have a 2nd AC and a 3rd AC measuring other attributes. Take for example a Buck converter: you might use the ADC to measure current (after the x16 multiplier from the OpAmp to help minimize the resistance of the shunt-current sense resistor), but then use Analog Comparator#1 as the feedback-sense to set the output voltage and then Analog Comparator#2 goes to your temperature-sensor for emergency thermal shutdown.
And AC#1 (aka: Output voltage) quite possibly needs to change depending on current, so you'd like that to be programmable. So the STM32L431 solves that by configuring DAC#1 to AC#1-, and now you got a controller that reacts instantly.
> capacitive/inductive sensing,
I'm not 100% sure, but I feel like the PIOs probably can implement capacitive sensing. Its actually just a timer and PIOs look like _very_ advanced timers to me.
------------
Or lets take the 4-20mA protocol as another example. How would you use the RP2354 to make a 4-20mA compatible product? Your one ADC is on the sensor, and you don't have any Analog Comparators (or other analog components...), so you're already out of analog components to implement the protocol.
You can of course use I2C sensors (which opens up the ADC off of sensing duty and onto current-sense duty needed to implement 4-20mA transmit), but how many I2C sensors out there are cheaper than these microcontrollers?
Even then: RP2350 / RP2040 is a single-ended ADC, is it not? That makes current-sensing low-side only which limits the applicability. Its not even a good solution.
I know that AVR / Atmel chips offer differential ADCs (aka: sense the voltage of (A-B)), which is instrumental in high-side current sensing. Its not sufficient to assume B is ground in 4-20mA protocol.
The STM32L431 has an OpAmp, so it wouldn't be too hard to implement (A-B) across two points using the OpAmp (aka: Differential Amplifier mode) and then report it to the single-ended ADC. So its different, but ultimately the STM32L431 chip solves the problem.
Price performance? You're not going to beat DDR2 RAM with microcontrollers..., which I'm seeing at 128MB for $3 or less these days, in terms of price/performance. Once we start talking about price/performance of compute, we very, very quickly rise up the escalation scale all the way to servers.
My point is that uCs exist almost purely because of their analog features. Take the STM32L431: its got 1x OpAmp, 2x DACs, and 5Msps 12-bit ADC at less than $1.
The only other devices that offer as much analog components are other microcontrollers (AVR, PIC, MSP430, MSPM0, etc. etc.). And in most cases, these other microcontrollers have "some niche" that tries to differentiate itself. That's why there's also so many of them, some of them are explicitly designed to be motor-controllers as one example.
--------
What real-world analog task are you looking at that requires 520KB of SRAM? Things are the opposite. Real-world analog-sensing tasks are like temperature-sensors (which take many seconds to change), or at fastest... things like rotation-sensors on a motor (10,000 RPM is 166Hz, even a 1MHz 8051 is sufficient to keep up with 10,000 RPM or 166Hz motors).
In these cases, the most important thing is... having a 2nd DAC. Or having Analog Comparators. Remember that Analog Comparators are 1-bit ADCs really, so those 2x ACs in the STM32L431 kinda-sorta act as an additional independently-running ADC in practice.
If you're using the 12-bit ADC on some important measurement task, its usually nice to have a 2nd AC and a 3rd AC measuring other attributes. Take for example a Buck converter: you might use the ADC to measure current (after the x16 multiplier from the OpAmp to help minimize the resistance of the shunt-current sense resistor), but then use Analog Comparator#1 as the feedback-sense to set the output voltage and then Analog Comparator#2 goes to your temperature-sensor for emergency thermal shutdown.
And AC#1 (aka: Output voltage) quite possibly needs to change depending on current, so you'd like that to be programmable. So the STM32L431 solves that by configuring DAC#1 to AC#1-, and now you got a controller that reacts instantly.
> capacitive/inductive sensing,
I'm not 100% sure, but I feel like the PIOs probably can implement capacitive sensing. Its actually just a timer and PIOs look like _very_ advanced timers to me.
------------
Or lets take the 4-20mA protocol as another example. How would you use the RP2354 to make a 4-20mA compatible product? Your one ADC is on the sensor, and you don't have any Analog Comparators (or other analog components...), so you're already out of analog components to implement the protocol.
You can of course use I2C sensors (which opens up the ADC off of sensing duty and onto current-sense duty needed to implement 4-20mA transmit), but how many I2C sensors out there are cheaper than these microcontrollers?
Even then: RP2350 / RP2040 is a single-ended ADC, is it not? That makes current-sensing low-side only which limits the applicability. Its not even a good solution.
I know that AVR / Atmel chips offer differential ADCs (aka: sense the voltage of (A-B)), which is instrumental in high-side current sensing. Its not sufficient to assume B is ground in 4-20mA protocol.
The STM32L431 has an OpAmp, so it wouldn't be too hard to implement (A-B) across two points using the OpAmp (aka: Differential Amplifier mode) and then report it to the single-ended ADC. So its different, but ultimately the STM32L431 chip solves the problem.
Adding to my earlier post....
I think RP2xxx is best for screens and GUIs. So a game console and similar.
PIO looks like it's good for a lot of digital interfaces as well. I know DVI and VGA have been proven on PIO for example and there's probably all kinds of 80s and 90s chips that need emulators or replacements that RP2xxx would be good for.
So there is definitely a niche for RP2xxx chips. But it's not in power control, motor control or the like. And since it's not quite strong enough for Linux, it's a hassle to run Web Communications (wget/curl) off of it either.
------
But traditionally, game consoles were an MPU market not a microcontroller market. And if I were making a modern hobby game console, Linux capabilities would be on the top of my list to make everything more convenient. And it's really not that expensive these days to reach into proper Linux / DDR2 / NAND Flash.
I think RP2xxx is best for screens and GUIs. So a game console and similar.
PIO looks like it's good for a lot of digital interfaces as well. I know DVI and VGA have been proven on PIO for example and there's probably all kinds of 80s and 90s chips that need emulators or replacements that RP2xxx would be good for.
So there is definitely a niche for RP2xxx chips. But it's not in power control, motor control or the like. And since it's not quite strong enough for Linux, it's a hassle to run Web Communications (wget/curl) off of it either.
------
But traditionally, game consoles were an MPU market not a microcontroller market. And if I were making a modern hobby game console, Linux capabilities would be on the top of my list to make everything more convenient. And it's really not that expensive these days to reach into proper Linux / DDR2 / NAND Flash.
> RP2354 has Flash finally
The flash is QSPI, so its not really on die flash with a real flash controller. There is some QSPI cache but it’s really a band-aid solution to not having the real thing. People around the net don't seem to understand the difference and it can be very misleading.
The flash is QSPI, so its not really on die flash with a real flash controller. There is some QSPI cache but it’s really a band-aid solution to not having the real thing. People around the net don't seem to understand the difference and it can be very misleading.
Hmmm, could you elaborate?
So I know that RP2xxx doesn't execute out of flash ever. I'm pretty sure the architecture of this is all execute out of SRAM.
Im pretty sure RP2040 copies out of QSPI and then executes in SRAM, but I'm not entirely sure what the downsides of this could be.
I'm guessing there might be security implications?
So I know that RP2xxx doesn't execute out of flash ever. I'm pretty sure the architecture of this is all execute out of SRAM.
Im pretty sure RP2040 copies out of QSPI and then executes in SRAM, but I'm not entirely sure what the downsides of this could be.
I'm guessing there might be security implications?
Nothing refreshing about this. Their mid range Raspberry Pi Zero used to be $5, now they are giving you an underpowered microcontroller for the same price. You can get Pico 2 sized individual boards for less than $2 in Asia.
The MCU is $0.80 - $1.10.
$1.10 for a dual core Cortex-M33 with 2MB flash and 512KB is a bargain in 2024 compared to other MCUs available at this time, at least in terms of prices that you'll be able to get as a regular consumer in the US. The only other chip that even comes close is the ESP32.
$1.10 for a dual core Cortex-M33 with 2MB flash and 512KB is a bargain in 2024 compared to other MCUs available at this time, at least in terms of prices that you'll be able to get as a regular consumer in the US. The only other chip that even comes close is the ESP32.
I think the mods reposted this thread. This is really neat, I wonder if they'll offer their normal Pis in a RISC-V flavor. I will likely pick up one of these as soon as I can.
[deleted]
I'm mostly interested how the software stack for this compares to something like STM32.
Its actually really nice and well supported. I personally prefer the sdk style that PICO does it over the cubemx stuff.
https://github.com/raspberrypi/pico-sdk
https://github.com/raspberrypi/pico-sdk
[deleted]