←back to thread

I got almost all of my wishes granted with RP2350

(dmitry.gr)
700 points elipsitz | 3 comments | 08 Aug 24 13:03 UTC | HN request time: 0.721s | 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 #
1. robomartin ◴[09 Aug 24 00:16 UTC] No.41197713[source]▶
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.

replies(1): >>41199432 #
2. ebenupton ◴[09 Aug 24 07:03 UTC] No.41199432[source]▶
It's a fair comment. Give our VSCode extension a go: the aspiration is to provide uniform developer experience across Linux, Windows, and MacOS.
replies(1): >>41201662 #
3. robomartin ◴[09 Aug 24 13:33 UTC] No.41201662[source]▶
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.