←back to thread

700 points elipsitz | 1 comments | | HN request time: 0.21s | 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 #
anymouse123456 ◴[] No.41198538[source]
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.)

replies(1): >>41203058 #
1. ryukoposting ◴[] No.41203058[source]
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.