I got almost all of my wishes granted with RP2350

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.

> My hope is that they'll eventually provide a library of ready-made "soft peripherals"

Perhaps they could be more ready-made, but there are loads of official PIO examples that are easy to get started with.

https://github.com/raspberrypi/pico-examples/tree/master/pio

I feel like the PIO is just slightly too limited for that. You can already do some absolute magic with it, but it's quite easy to run into scenarios where it becomes really awkward to use due to the limited instruction count, lack of memory, and absence of a direct clock input.

Sure, you can work around it, but that often means making significant sacrifices. Good enough for some hacking, not quite there yet to fully replace hard peripherals.

Any concrete examples?

PIO is surprisingly flexible, even more so in RP2350.

You run into issues if you try to implement something like RMII, which requires an incoming 50MHz clock.

There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of postprocessing.

There's another implementation which oversamples the signal instead. This requires overclocking the Pico to 250MHz. That's nearly double the design speed, and close to some peripherals no longer working.

A third implementation feeds the 50MHz clock into the XIN input, allowing the PLL to generate the right clock. This works, except that you've now completely broken the bootloader as it assumes a 12MHz clock when setting up USB. It's also not complete, as the 10meg half duplex mode is broken due to there not being enough space for the necessary PIO instructions.