←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: 0s | 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 #
dmitrygr ◴[09 Aug 24 05:31 UTC] No.41199028[source]▶
> 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?

replies(2): >>41199215 #>>41203430 #
1. ryukoposting ◴[09 Aug 24 16:44 UTC] No.41203430{4}[source]▶
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.