Rust on the RP2350 (2024)
27 comments
·March 16, 2025GolDDranks
ricudis
The OpenWRT SDK is quite polished and convenient to use, so I usually use that for custom OpenWRT binaries. But a few days ago I needed to run something custom on my old QNAP NAS (Marvell ARMv5TE based), and I decided to try cross-rs[1] for the first time.
It turned the usual multi-hour expedition of locating and configuring SDKs, toolchains, etc into 3 commands and 5 minutes of downloads and compilation. The resulting executable ran successfully at the first try. I was amazed.
johnisgood
> I became convinced that Rust is the next C for the embedded.
Ada works, too, though, or Forth. :P
drrotmos
Note that this was written 2024-08-08. While I haven't kept up to date with exactly what's been happening in rp-rs, I do know that probe-rs has since been updated with support for the RP2350. Other things may be outdated as well.
jayyhu
The author points out that his changes have already been upstreamed to https://github.com/rp-rs/rp-hal
sph
Can anyone explain how the dual ARM/RISC-V system works, architecturally?
Are there two actual CPUs on the same die? Is it one shared architecture with two different instruction decode stages, one for ARM and the other for RISC-V that can be toggled at boot time? I like the idea conceptually but I'm not sure how much of that is a hack and/or inefficient compared to a pure ARM or RISC-V core.
dcan
To be more precise, four CPUs - two ARM and two RISC. There is just a mux for the instruction and data buses - see chapter 3 of the [datasheet](https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...).
It’s space-inefficient as half of the CPUs are shutdown, but architecturally it’s all on the same bus.
Aurornis
> It’s space-inefficient as half of the CPUs are shutdown
In practice is doesn't matter very much for a design like this. The size is already limited to a certain minimum to provide enough perimeter area to provide wire bonding area for all of the pins, so they can fill up the middle with whatever they want.
Narishma
It may be technically space inefficient but they only added the RISC-V cores because they had area to spare. It didn't cost them much.
enragedcacti
Source for the RISC-V cores being essentially free (Luke Wren is the creator of the RISC-V core design used):
> The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design.
Graziano_M
Funny thing is that it cost them more than you might think. It was the ability to switch to the riscv which made it (much) easier to glitch. See the "Hazardous threes" exploit [1]
[1] https://www.raspberrypi.com/news/security-through-transparen...
petertodd
I wonder if they're using the same die for one or more microprocessor products that are RISC-V-only or ARM-only? They could be binning dies that fail testing on one or the other cores that way. Such a product might be getting sold under an entirely different brand name too.
myrmidon
I find this whole concept remarkable, and somewhat puzzling.
Have seen the same (ARM + RISC-V cores) even at larger scales before (Milk-V Duo @1GHz-ish). But how is this economical? Is die space that cheap? Could you not market the same thing as quadcore with just minor design changes, or would that be too hard because of power budget/bus bandwidth reasons?
imtringued
SRAM is very area intensive. What you're asking for is very greedy. The RISC-V core they are using is absolutely tiny.
bananapub
two things:
1) it needs a certain perimeter to allow all the pins to go from the silicon to the package, which mandates a certain sized square-ish die 2) only the cores are duplicated (and some switching thing is added)
so yes, there is enough space to just add another two cores without any worries, since they don't need more IO or pins or memory or anything.
MisterTea
> Can anyone explain how the dual ARM/RISC-V system works, architecturally?
What I really want to know is why would anyone need or want dual architectures on one chip?
pjc50
This is hedging their bets.
Tapeouts are expensive. It seems that they had spare area, so they decided to add RISC-V as a sort of feature test and market test; that lets them determine what the market preference is between the two and acquire geek coolness points (plus an additional point for using Rust) at relatively low cost, certainly lower cost than doing two tapeouts for two different SKUs.
Here at $MEDIUM_SIZED_CHIP_CO, we also have some products which have a custom DSP for realtime audio processing and an ARM for "other stuff". It's more common than you think. Even the very first Pi was effectively a video-oriented vector processor with a small ARM glued on the side.
password4321
Which of the four RP2350 variants is used in the Raspberry Pi Pico 2 W? I see RP2350A0A2⁰ and (pardon my ignorance) guess that means SKU RP2350A package QFN60, the one with the least features.
⁰ https://datasheets.raspberrypi.com/picow/pico-2-w-schematic....
moefh
As far as I know, any Pico 2 currently sold carry the RP2350A: 30 GPIOs, no internal flash since the board carries an external flash chip.
(BTW two of the variants are called RP2354 and not RP2350, the last digit means the amount of internal flash)
maeln
Most picture I find seem to show the RP2350A variant for the W and non-W version.
teleforce
Previous post on HN:
Raspberry Pi Showcases Rust on the RP2350 Microcontroller (9 comments):
mastax
thejpster, where do I know that username from...
Ah, he wrote most of embedded-sdmmc-rs which I used quite a bit. Jonathan, if you see this, thanks!
moffkalast
See, this is why we use conformal coating ;)
null
I own a home router (TP-Link Archer C7) and I have been running OpenWRT for many years on it, having full control over it via SSH. A few years back, I had an idea for an daemon process/service to improve a certain thing in its functionality. I was delighted to find out that the MIPS chip that powers the thing was supported by Rust, and I coded a "script", cross-compiled it to a binary and SCP't that to the router. It ran beautifully. After that (and running Rust on a few other embedded systems, including an ARM Cortex-R chip) I became convinced that Rust is the next C for the embedded.