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
Given that PIO's most compelling use case is replacing legacy MCUs, I find it disappointing that they haven't provided PIO boilerplate for the peripherals that keep those archaic architectures relevant. Namely: Ethernet MII and CANbus.
Also, if RP2xxx is ever going to play ball in the wireless space, then they need an out-of-box Bluetooth HCI implementation, and it needs sample code, and integration into Zephyr.
I speak as someone living in this industry: the only reason Nordic has such a firm grip on BLE product dev is because they're the only company providing a bullshit-free Bluetooth stack out of the box. Everything else about nRF sucks. If I could strap a CYW4343 to an RP2350 with some example code as easily as I can get a BT stack up and running on an nRF52840, I'd dump Nordic overnight.
https://github.com/KevinOConnor/can2040
https://github.com/sandeepmistry/pico-rmii-ethernet
My biggest issue with their wireless implementation is that I get my boards made at JLCPCB and Raspberry Pi chose a specialty wireless chip for the Pico W which is not widely available, and is not available at JLCPCB.
RP2350 is about the best I can think of for interfacing with legacy protocols. Well, short of using FPGAs anyways.
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.
PIO is surprisingly flexible, even more so in RP2350.
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.
Also, are there any other approaches that might be better and would offer 100meg or even gigabit links with the RP2350? Thanks!
(Above is with killall -s QUIT ping) As you can see, it eventually hangs, and CMSIS reports: target halted due to breakpoint, current mode: Handler HardFault xPSR: 0x61000003 pc: 0x200001c4 msp: 0x20040f40
Turns out I wasn't passing the RX data properly to LWIP...