←back to thread

700 points elipsitz | 2 comments | | HN request time: 0s | source
Show context
ryukoposting ◴[] 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 ◴[] 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 ◴[] 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 #
XMPPwocky ◴[] No.41196896[source]
What stops an attacker from uploading their own firmware that dumps out everything in OTP?
replies(1): >>41196960 #
ebenupton ◴[] No.41196960[source]
Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
replies(1): >>41198170 #
phire ◴[] No.41198170[source]
Do you have any protection against power/clock glitching attacks?
replies(2): >>41198355 #>>41199421 #
1. ebenupton ◴[] No.41199421{4}[source]
Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462
replies(1): >>41200657 #
2. colejohnson66 ◴[] No.41200657[source]
Unrolled for those without accounts: https://threadreaderapp.com/thread/1821570157933912462.html