←back to thread

I got almost all of my wishes granted with RP2350

(dmitry.gr)
700 points elipsitz | 1 comments | 08 Aug 24 13:03 UTC | HN request time: 0.238s | source
Show context
ryukoposting ◴[08 Aug 24 19:06 UTC] No.41195070[source]▶
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.

replies(13): >>41195311 #>>41195541 #>>41195612 #>>41195790 #>>41196002 #>>41196768 #>>41197714 #>>41197884 #>>41198538 #>>41199263 #>>41199401 #>>41200014 #>>41200125 #
robomartin ◴[08 Aug 24 21:56 UTC] No.41196768[source]▶
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.
replies(1): >>41196825 #
ebenupton ◴[08 Aug 24 22:04 UTC] No.41196825[source]▶
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.
replies(3): >>41196896 #>>41197713 #>>41198417 #
ryukoposting ◴[09 Aug 24 02:47 UTC] No.41198417[source]▶
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.

replies(2): >>41198829 #>>41199028 #
TickleSteve ◴[09 Aug 24 04:42 UTC] No.41198829[source]▶
520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.
replies(1): >>41203278 #
1. ryukoposting ◴[09 Aug 24 16:25 UTC] No.41203278[source]▶
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.