5 ms·

> 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

> 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 https://github.com/raspberrypi/pico-examples/tree/master/pio

ryukoposting 2y ago
These examples are cute, but this isn't a comprehensive collection. Not even close. 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.
- bboygravity 2y ago
  Just feed the boilerplate templates to Claude and ask it to "write a CANbus driver, use boiler plate as example" and done?
  - TaylorAlexander 2y ago
    I have never had even the slightest luck getting any of the AI services to generate something as specialized as embedded system drivers.
    - defrost 2y ago
      I can't even get them to make me a sandwich :(
- vardump 2y ago
  Just pick whatever fits best in your application. No µC is going to solve everything for everyone. RP2350 is about the best I can think of for interfacing with legacy protocols. Well, short of using FPGAs anyways.
- SequoiaHope 2y ago
  Well open source CAN and MII implementations do exist. Perhaps you can help provide a pull request to the official repo that checks in appropriate versions of that code, or file an issue requesting them to do it. https://github.com/KevinOConnor/can2040 https://github.com/KevinOConnor/can2040 https://github.com/sandeepmistry/pico-rmii-ethernet 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.
- pkaye 2y ago
  How much do those Nordic controllers cost? Are the as affordable as the RP2350?
crote 2y ago
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.
- vardump 2y ago
  Any concrete examples? PIO is surprisingly flexible, even more so in RP2350.
  - crote 2y ago
    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.
    - TaylorAlexander 2y ago
      Just to clarify, and it sounds like the answer is yes, this is a problem even with an external 50MHz clock signal?
      - tomooot 2y ago

ryukoposting 2y ago

These examples are cute, but this isn't a comprehensive collection. Not even close. 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.

bboygravity 2y ago
Just feed the boilerplate templates to Claude and ask it to "write a CANbus driver, use boiler plate as example" and done?
- TaylorAlexander 2y ago
  I have never had even the slightest luck getting any of the AI services to generate something as specialized as embedded system drivers.
  - defrost 2y ago
    I can't even get them to make me a sandwich :(
vardump 2y ago
Just pick whatever fits best in your application. No µC is going to solve everything for everyone. RP2350 is about the best I can think of for interfacing with legacy protocols. Well, short of using FPGAs anyways.
SequoiaHope 2y ago
Well open source CAN and MII implementations do exist. Perhaps you can help provide a pull request to the official repo that checks in appropriate versions of that code, or file an issue requesting them to do it. https://github.com/KevinOConnor/can2040 https://github.com/KevinOConnor/can2040 https://github.com/sandeepmistry/pico-rmii-ethernet 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.
pkaye 2y ago
How much do those Nordic controllers cost? Are the as affordable as the RP2350?

crote 2y ago

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.

vardump 2y ago
Any concrete examples? PIO is surprisingly flexible, even more so in RP2350.
- crote 2y ago
  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.
  - TaylorAlexander 2y ago
    Just to clarify, and it sounds like the answer is yes, this is a problem even with an external 50MHz clock signal?
    - tomooot 2y ago