Overrated surely? It's a pretty bog standard MCU, no wireless support, mediocre deep sleep. I don't know why you'd pick it over an ESP32 or nRF5x.
The only standout feature is PIO which is definitely interesting but very niche. It's also patented so say goodbye to any portability or FOSS vibes. (If you want a FOSS version btw, check out https://baochip.com/)
If it didn't have the Raspberry name behind it nobody would even have heard of it.
The PIO are pretty great and not niche. Almost any embedded application needs mixed signal interfaces. You could say embedded applications are niche, but not that embedded applications needing mixed signal interfaces.
A serious warning: read the RP2350 errata carefully. You may be better off buying old 2040 inventory.
RP2350 adds secure boot and encrypted boot. I am working on a little hardware device for a CTF and selected it as my MCU so participants can't just dump the flash to grab the flags.
> Almost any embedded application needs mixed signal interfaces.
For the vast majority of embedded applications you can simply pick an MCU that has the hardware peripherals they need. That's why XMOS was never very successful. (They thought of this idea long ago.) Not saying it isn't cool.
If you want something that can do some dumb buttons and lights handling on a mass consumer device, it's not ideal.
I would say it is still underrated.
PIO combined with DMA and the independent bus SRAM banks allow for immense combinations of capability.
If you want to do something digital and specific beyond a few MHz the the RP2350 raised the ceiling of what you can do before requiring hardware or FPGA.
It still has some areas where it could be improved, but most of thise would not have been apparent until you really stretched the design.
Having extra PIO GPIO without physical pins but the ability to configure connecting pairs together in software would add a lot of capability.
Perhaps an interesting test/benchmark would be to get a microcontroller to pretend to be an SRAM (or better yet two independently accessed SRAMs) while outputting the lyrics to still alive on a serial link.
The virtual SRAM performance characteristics of timing tolerances and latency would be a respectable approximation for arbitrary digital signal handling that any particular MCU might be able to manage.
Are you kidding me? It costs a fraction of the competition and you can use just about any pin for anything you want! It makes designing boards for the RP series so simple and easy!
Contrast that with STM32 where you have to constantly reference the data sheet to make sure you're using the correct pins for say, I2C when you're running in a particular mode. And since you're running in that mode, you now can't use other pins for certain things. Ugh! I hate it!
Then there's the issues with picking the right-size part number and making sure the pins you want are 5V tolerant, checking that you're using the correct ADC, and... Ugh! It's a pain in the ass!
Other chips aren't much better as they all have those same problems.
ESP32 is nice because of the zillions of built-in peripherals but configuring the damned thing can get really complicated really fast. It's so complicated, in fact, that they had to make a Makefile (as in `make menuconfig`) that rivals the Linux kernel in the sheer number of options/submenus.
nRF5x also has completely configurable pins, and if you're worrying about awkward pinouts making PCB design slightly more annoying then you're definitely not in a cost sensitive project.
Everybody agrees that Rust's ecosystem is too fragmented, but I don't think that the solution proposed here will solve anything.
The most promising project to solve this problem is https://github.com/rust-stdx/stdx which is (more or less) re-creating Go's standard library in Rust.
The guy that is making stdx has been doing various shady stuff in his books and code which have resulted in all his stuff being banned on /r/rust. In stdx, he’s been forking good code, violating licenses, completely rewriting stuff with LLMs (including cryptography code, and definitely introducing bugs in the process)… it’s not a good approach.
You're advocating for one solution that has two problems:
* It is precisely what TFA goes in for: a one-stop shop (somewhat application dependent)
* It is antithetical to the "embarassment of riches" approach that Rust tried for when they delegated almost all functionality to crates - the ecosystem has proven fruitful
It seems to me that advocacy, writing good applications, or human-readable guides will do more for convergence on crate bundles than a more technical solution. I reach for the crates I know, not yet-another-framework.
While the consumer market is still years away from widespread RISC-V adoption, if you pay attention to the embedded / MCU market (especially Espressif & co) you will indeed come to the conclusion that RISC-V is inevitable and software maturity will probably come from these early adopters.
x86 only missed the mobile market because of multiple bad business decisions, otherwise ARM (and RISC architectures overall) would have been relegated to more decades as backwater architectures.
There is nothing inevitable about anything as Apple controls its own silicon very tightly, Microsoft hasn't even really transitioned away from x86, and Android probably isn't very keen to transition away from ARM.
Now, embedded markets are different but they've always been different and the number of embedded programmers is dwarfed by non embedded programmers and regular users will for a long time never install an app on RISC-V.
It's an interesting journey, let's see where it takes us in 20 years.
Chinese companies are really into RISC-V and China both builds and uses a lot of smartphones, I'm very sure we won't have to wait 20 years for regular users installing apps on RISC-V hardware.
> Finally the chips have to deliver in performance, to actually provide good mobile devices
There were still, as recently as 2025, new smartphones being released with only Arm A53 cores from 2012. Low end, obviously, but equally obviously there is a market for them.
RISC-V SoCs passed that performance mark in 2021 and shipping SBCs are currently at the Arm A76 RK3588/Pi 5 level. In flagship phones that was the Samsung Galaxy S10 generation, but there are still today a lot of budget phones using A76 as the primary cores (usually with some A55s too).
Cores are available for licensing up to around the Cortex-X3 level. Someone just has to be interested enough to put them in an SoC.
It's a business question now, not a technology one.
> Finally the chips have to deliver in performance, to actually provide good mobile devices.
Or the other way around: the low-end market wants to adopt it due to lower licensing fees, so Android is incentivized to support RISC-V or risk losing that market to a competing platform. Especially in markets with a God App like Wechat something in-between feature phone and smartphone won't be a very hard sell. RISC-V adoption can grow upwards from there.
If the chips aren't fast enough to run a JIT and AOT compiler, a concurrent copying generational GC, along with a modern Vulkan implementation, no one would care, they would be better with feature phones at that point.
They are already. I've got the Spacemit K3 and it is a bit below Sandy Bridge single-core speed - so nothing spectacular - but fast enough for everyday desktop use. And way faster than my old budget smartphone's SoC.
Yes RISC-V has not caught up to modern x86/ARM CPUs like Zen 5, Snapdragon or Apple but still fast enough for modern browsers and most software in general.
Already existing RISC-V CPUs are certainly fast enough to build entry level smartphones. It's probably just a matter of time (3-5 years maybe?) until some Chinese company does it.
Krste wasn't even saying anything controversial. It's obvious that manufacturers will use the cheapest (free) least legally entangled option, and that this adoption will happen first amongst those with the tightest margins. And - Clayton's law[1] - it will eventually extend to the rest of the market (albeit over a very long time).
The good RISC-V designs are not free though and the free ones are not good. MCUs are not a category of computer to draw lessons from for the broader market.
The good ARM designs aren't free either. The big difference is that you'll always be stuck paying Arm (either for whole ARM cores, or a licensing fee for your own design), whereas with RISC-V there can be genuine competition between companies offering performant RISC-V IP.
In the MCU market the compute core is already an off-the-shelf drop-in component. Just look at the RP2350: in addition to its traditional ARM cores they also last-minute dropped in two RISC-V cores because it was so trivial to do - and you can select which set is active via a boot-time firmware flag. I very much doubt we'll see that kind of flexibility with high-end client compute, but with the switch to separate compute chiplets we're not far off already!
iirc Christenson's chief example was IBM not deigning to cannibalize their high-end disk drive business by competing on the new, less capable low-end devices.
reply