I can't imagine someone using an RP2040 in a real product, but the RP2350 fixes enough of my complaints that I'd be really excited to give it a shot.
There's a lot going for the 2040, don't get me wrong. TBMAN is a really cool concept. It overclocks like crazy. PIO is truly innovative, and it's super valuable for boatloads of companies looking to replace their 8051s/whatever with a daughterboard-adapted ARM core.
But, for every cool thing about the RP2040, there was a bad thing. DSP-level clock speeds but no FPU, and no hardware integer division. A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. PIO support is extremely limited in third-party SDKs like Zephyr, which puts a low ceiling on its usefulness in large-scale projects.
The RP2350 fixes nearly all of my complaints, and that's really exciting.
PIO is a really cool concept, but relying on it to implement garden-variety peripherals like CAN or SDMMC immediately puts RP2350 at a disadvantage. The flexibility is very cool, but if I need to get a product up and running, the last thing I want to do is fiddle around with a special-purpose assembly language. My hope is that they'll eventually provide a library of ready-made "soft peripherals" for common things like SD/MMC, MII, Bluetooth HCI, etc. That would make integration into Zephyr (and friends) easier, and it would massively expand the potential use cases for the chip.
For my work, the lack of flash memory integration on the 2040 is a deal breaker. You cannot secure your code. Not sure that has changed with the new device.
It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.
You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine.
Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.
what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?
There are plenty of embedded applications that require megabytes or even gigabytes.
For example medical imaging.
As well as plenty that require 16 bytes of RAM and a few hundred bytes of program memory. And everything in between.
If it's in the gigabyte range it's just not an MCU by any stretch. And if it has a proper (LP)DDR controller it's not one either really
Yes and no. Plenty of such applications that use a µC + an FPGA. FPGA interfaces with some DDR memory and CMOS/CCD/whatever.
Up to you what you call it.
So you make hardware costing dozens of thousands of dollars and brag about memory on 5$ chip? That explains a lot why so many medical and industrial (I haven’t touch military hardware) are so badly designed, with some sad proprietary protocols and dead few months after warranty passes. Today I’ve learned!
I'm smoking multiprotocol wireless systems for industrial, medical, and military applications. To my recollection, the very smallest of those was around 280K in .text, and 180K in .data. Others have been 2-3x larger in both areas.
I would sure hope a decstation3100 emulator is small. After all, it's worthless unless you actually run something within the emulator, and that will inevitably be much larger than the emulator itself. I wouldn't know, though. Believe it or not, nobody pays me to emulate computers from 1978.
520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.
Define "typical."
To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading.
If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340.
So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.
What stops an attacker from uploading their own firmware that dumps out everything in OTP?
Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
Do you have any protection against power/clock glitching attacks?
Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462
Unrolled for those without accounts: https://threadreaderapp.com/thread/1821570157933912462.html
I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
Nice! Thanks for the direct communication BTW.
I guess you are very serious about competing with industrial MCU’s.
We had to use a 2040 shortly after it came out because it was impossible to get STM32’s. Our customer accepted the compromise provided we replaced all the boards (nearly 1000) with STM32 boards as soon as the supply chain normalized.
I hope to also learn that you now have proper support for development under Windows. Back then your support engineers were somewhat hostile towards Windows-based development (just learn Linux, etc.). The problem I don’t think they understood was that it wasn’t a case of not knowing Linux (using Unix before Linux existed). A product isn’t just the code inside a small embedded MCU. The other elements that comprise the full product design are just as important, if not more. Because of this and other reasons, it can make sense to unify development under a single platform. I can’t store and maintain VM’s for 10 years because one of the 200 chips in the design does not have good support for Windows, where all the other tools live.
Anyhow, I explained this to your engineers a few years ago. Not sure they understood.
I have a project that I could fit these new chips into, so long as we don’t have to turn our workflow upside down to do it.
Thanks again.
It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.
I will when I get a break. I'll bring-up our old RP2040 project and see what has changed.
I remember we had to use either VSC or PyCharm (can't remember which) in conjunction with Thonny to get a workable process. Again, it has been a few years and we switched the product to STM32, forgive me if I don't recall details. I think the issue was that debug communications did not work unless we used Thonny (which nobody was interested in touching for anything other than a downloader).
BTW, that project used MicroPython. That did not go very well. We had to replace portions of the code with ARM assembler for performance reasons, we simply could not get efficient communications with MicroPython.
Thanks again. Very much a fan. I mentored our local FRC robotics high school team for a few years. Lots of learning by the kids using your products. Incredibly valuable.
Perhaps they could be more ready-made, but there are loads of official PIO examples that are easy to get started with.
https://github.com/raspberrypi/pico-examples/tree/master/pio
These examples are cute, but this isn't a comprehensive collection. Not even close.
Given that PIO's most compelling use case is replacing legacy MCUs, I find it disappointing that they haven't provided PIO boilerplate for the peripherals that keep those archaic architectures relevant. Namely: Ethernet MII and CANbus.
Also, if RP2xxx is ever going to play ball in the wireless space, then they need an out-of-box Bluetooth HCI implementation, and it needs sample code, and integration into Zephyr.
I speak as someone living in this industry: the only reason Nordic has such a firm grip on BLE product dev is because they're the only company providing a bullshit-free Bluetooth stack out of the box. Everything else about nRF sucks. If I could strap a CYW4343 to an RP2350 with some example code as easily as I can get a BT stack up and running on an nRF52840, I'd dump Nordic overnight.
Just feed the boilerplate templates to Claude and ask it to "write a CANbus driver, use boiler plate as example" and done?
I have never had even the slightest luck getting any of the AI services to generate something as specialized as embedded system drivers.
I can't even get them to make me a sandwich :(
Just pick whatever fits best in your application. No µC is going to solve everything for everyone.
RP2350 is about the best I can think of for interfacing with legacy protocols. Well, short of using FPGAs anyways.
Well open source CAN and MII implementations do exist. Perhaps you can help provide a pull request to the official repo that checks in appropriate versions of that code, or file an issue requesting them to do it.
https://github.com/KevinOConnor/can2040
https://github.com/sandeepmistry/pico-rmii-ethernet
My biggest issue with their wireless implementation is that I get my boards made at JLCPCB and Raspberry Pi chose a specialty wireless chip for the Pico W which is not widely available, and is not available at JLCPCB.
I feel like the PIO is just slightly too limited for that. You can already do some absolute magic with it, but it's quite easy to run into scenarios where it becomes really awkward to use due to the limited instruction count, lack of memory, and absence of a direct clock input.
Sure, you can work around it, but that often means making significant sacrifices. Good enough for some hacking, not quite there yet to fully replace hard peripherals.
Any concrete examples?
PIO is surprisingly flexible, even more so in RP2350.
You run into issues if you try to implement something like RMII, which requires an incoming 50MHz clock.
There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of postprocessing.
There's another implementation which oversamples the signal instead. This requires overclocking the Pico to 250MHz. That's nearly double the design speed, and close to some peripherals no longer working.
A third implementation feeds the 50MHz clock into the XIN input, allowing the PLL to generate the right clock. This works, except that you've now completely broken the bootloader as it assumes a 12MHz clock when setting up USB. It's also not complete, as the 10meg half duplex mode is broken due to there not being enough space for the necessary PIO instructions.
Just to clarify, and it sounds like the answer is yes, this is a problem even with an external 50MHz clock signal?
As far as I understood the explanation, the incoming ("external") 50Mhz clock signal is a core requirement of the spec: all of those workarounds are just what is required to meet that spec, and be able to TX/RX using the protocol at all.
Almost correct - the third implementation does generate the clock, but it isn't necessary to drive the clock directly from the system clock, as there are m/n clock dividers available. I use a 300 MHz system clock, and divide down to 50 MHz which works well. (I've also addressed a few other shortcomings of this library, but am not done yet...) Haven't looked at the 10 MHz half duplex mode, though.
Are you saying DFU is not useful without an MMU/MPU? Why would that be?
It's certainly useful, but having it embedded within the hardware with no way to properly secure it makes the RP2040 a non-starter for any product I've ever written firmware for.
it has secure boot and TrustZone.
Not the RP2040. That chip has no boot security from anyone with physical access to the QSPI or SWD pins.
RP2040 shows up in a lot of qmk keyboards, for real product use
as niche as it gets
But real products.
It did have it, but as an out-of-ISA extension
Not only that, the single FP and double FP were provided as optimized subroutines. I was never hampered by inadequate FP performance for simple control tasks.
We're using 2040's in a variety of "real" products for an industrial application.
PIO is a huge selling point for me and I'm thrilled to see them leaning into it with this new version.
It's already as you hoped. Folks are developing PIO drivers for various peripherals (i.e., CAN and WS2812, etc.)
Oh, I'm sure it's great for industrial, as long as you can live with the hardware security issues. In college, my first serious task as an intern was to take a Cortex-M0+ and make it pretend to be an 8051 MCU that was being obsoleted. Unsurprisingly, this was for an industrial automation firm.
I mimicked the 16-bit data bus using hand-written assembly to make sure the timings were as close as possible to the real chip. It was a pain in the ass. It would have been amazing to have a chip that was designed specifically to mimic peripherals like that.
It's great that there's a community growing around the RPi microcontrollers! That's a really good sign for the long-term health of the ecosystem they're trying to build.
What I'm looking for is a comprehensive library of PIO drivers that are maintained by RPi themselves. There would be a lot of benefits to that as a firmware developer: I would know the drivers have gone through some kind of QA. If I'm having issues, I could shoot a message to my vendor/RPi and they'll be able to provide support. If I find a bug, I could file that bug and know that someone is going to receive it and fix it.
I haven’t dug into the RP2xxx but I presumed there would be a library of PIO implementations of the standard protocols from RP themselves. There really isn’t?
Edit: I see, there are “examples”. I’d rather have those be first-class supported things.
Why not? It's a great chip, even if it has some limitations. I use it in several of my pro audio products (a midi controller, a Eurorack module, and a series of guitar pedals). they are absolutely perfect as utility chips, the USB stack is good, the USB bootloader makes it incredibly easy for customers to update the firmware without me having to write a custom bootloader.
I've shipped at least a thousand "real" products with an RP2040 in them.
So is almost any non-trivial peripheral feature. Autonomous peripheral operation, op-amps, comparators, capture/compare timers…
Zephyr tries to provide a common interface like desktop OSes do and this doesn't really work. On desktop having just the least common denominator is often enough. On embedded you choose your platform because you want the uncommon features.
For high volume products, given the low cost of this chip, it would make sense to bother with the PIO or it's open-source libraries.
We ship a large quantity of RP2040’s in real products, and agreed that the RP2350 looks great too!
Part of the reason we went with RP2040 was the design philosophy, but a lot of it was just easy availability coming out of the chip crunch.
The RP2040 SIO block contains one hardware divider per CPU core.