6 ms·

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

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.

alex-robbins 2y ago
> A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. Are you saying DFU is not useful without an MMU/MPU? Why would that be?
- ryukoposting 2y ago
  It's certainly useful, but having it embedded within the hardware with no way to properly secure it makes the RP2040 a non-starter for any product I've ever written firmware for.
  - TickleSteve 2y ago
    it has secure boot and TrustZone.
    - crest 2y ago
      Not the RP2040. That chip has no boot security from anyone with physical access to the QSPI or SWD pins.
petra 2y ago
For high volume products, given the low cost of this chip, it would make sense to bother with the PIO or it's open-source libraries.
deleted 2y ago
[deleted]
TaylorAlexander 2y ago
> 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 :(
my123 2y ago
> no hardware integer division It did have it, but as an out-of-ISA extension
- GeorgeTirebiter 2y ago
  Not only that, the single FP and double FP were provided as optimized subroutines. I was never hampered by inadequate FP performance for simple control tasks.
wrs 2y ago
I haven’t dug into the RP2xxx but I presumed there would be a library of PIO implementations of the standard protocols from RP themselves. There really isn’t? Edit: I see, there are “examples”. I’d rather have those be first-class supported things.
robomartin 2y ago
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.
- ebenupton 2y ago
  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.
  - XMPPwocky 2y ago
    What stops an attacker from uploading their own firmware that dumps out everything in OTP?
    - ebenupton 2y ago
      Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
      - phire 2y ago
        Do you have any protection against power/clock glitching attacks?
        geerlingguy 2y ago
        I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
        ebenupton 2y ago
        Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462 https://x.com/ghidraninja/status/1821570157933912462
__s 2y ago
RP2040 shows up in a lot of qmk keyboards, for real product use
- Eduard 2y ago
  > RP2040 shows up in a lot of qmk keyboards as niche as it gets
  - tssva 2y ago
    But real products.
anymouse123456 2y ago
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.)
- ryukoposting 2y ago
  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.
nrp 2y ago
We ship a large quantity of RP2040’s in real products, and agreed that the RP2350 looks great too! Part of the reason we went with RP2040 was the design philosophy, but a lot of it was just easy availability coming out of the chip crunch.
tliltocatl 2y ago
>>> extremely limited in third-party SDKs like Zephyr So is almost any non-trivial peripheral feature. Autonomous peripheral operation, op-amps, comparators, capture/compare timers… Zephyr tries to provide a common interface like desktop OSes do and this doesn't really work. On desktop having just the least common denominator is often enough. On embedded you choose your platform because you want the uncommon features.
crest 2y ago
> no hardware integer division The RP2040 SIO block contains one hardware divider per CPU core.
valdiorn 2y ago
> I can't imagine someone using an RP2040 in a real product Why not? It's a great chip, even if it has some limitations. I use it in several of my pro audio products (a midi controller, a Eurorack module, and a series of guitar pedals). they are absolutely perfect as utility chips, the USB stack is good, the USB bootloader makes it incredibly easy for customers to update the firmware without me having to write a custom bootloader. I've shipped at least a thousand "real" products with an RP2040 in them.
- helpfulContrib 2y ago
  [dead]
- ryukoposting 2y ago
  Given the way the RP2040 is set up, I cannot conceive of a proper secure boot chain for it. So, for basically everything I work on professionally, it's a non-starter. I think the key in your use case is that "hackability" is a feature, not a potentially life-threatening risk.

alex-robbins 2y ago

> A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. Are you saying DFU is not useful without an MMU/MPU? Why would that be?

ryukoposting 2y ago
It's certainly useful, but having it embedded within the hardware with no way to properly secure it makes the RP2040 a non-starter for any product I've ever written firmware for.
- TickleSteve 2y ago
  it has secure boot and TrustZone.
  - crest 2y ago
    Not the RP2040. That chip has no boot security from anyone with physical access to the QSPI or SWD pins.

petra 2y ago

For high volume products, given the low cost of this chip, it would make sense to bother with the PIO or it's open-source libraries.

deleted 2y ago

[deleted]

TaylorAlexander 2y ago

> 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 :(

my123 2y ago

> no hardware integer division It did have it, but as an out-of-ISA extension

GeorgeTirebiter 2y ago
Not only that, the single FP and double FP were provided as optimized subroutines. I was never hampered by inadequate FP performance for simple control tasks.

wrs 2y ago

I haven’t dug into the RP2xxx but I presumed there would be a library of PIO implementations of the standard protocols from RP themselves. There really isn’t? Edit: I see, there are “examples”. I’d rather have those be first-class supported things.

robomartin 2y ago

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.

ebenupton 2y ago
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.
- XMPPwocky 2y ago
  What stops an attacker from uploading their own firmware that dumps out everything in OTP?
  - ebenupton 2y ago
    Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
    - phire 2y ago
      Do you have any protection against power/clock glitching attacks?
      - geerlingguy 2y ago
        I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
      - ebenupton 2y ago
        Yes, several approaches. More here: https://x.com/ghidraninja/status/1821570157933912462 https://x.com/ghidraninja/status/1821570157933912462

__s 2y ago

RP2040 shows up in a lot of qmk keyboards, for real product use

Eduard 2y ago
> RP2040 shows up in a lot of qmk keyboards as niche as it gets
- tssva 2y ago
  But real products.

anymouse123456 2y ago

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.)

ryukoposting 2y ago
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.

nrp 2y ago

We ship a large quantity of RP2040’s in real products, and agreed that the RP2350 looks great too! Part of the reason we went with RP2040 was the design philosophy, but a lot of it was just easy availability coming out of the chip crunch.

tliltocatl 2y ago

>>> extremely limited in third-party SDKs like Zephyr So is almost any non-trivial peripheral feature. Autonomous peripheral operation, op-amps, comparators, capture/compare timers… Zephyr tries to provide a common interface like desktop OSes do and this doesn't really work. On desktop having just the least common denominator is often enough. On embedded you choose your platform because you want the uncommon features.

crest 2y ago

> no hardware integer division The RP2040 SIO block contains one hardware divider per CPU core.

valdiorn 2y ago

> I can't imagine someone using an RP2040 in a real product Why not? It's a great chip, even if it has some limitations. I use it in several of my pro audio products (a midi controller, a Eurorack module, and a series of guitar pedals). they are absolutely perfect as utility chips, the USB stack is good, the USB bootloader makes it incredibly easy for customers to update the firmware without me having to write a custom bootloader. I've shipped at least a thousand "real" products with an RP2040 in them.

helpfulContrib 2y ago
[dead]
ryukoposting 2y ago
Given the way the RP2040 is set up, I cannot conceive of a proper secure boot chain for it. So, for basically everything I work on professionally, it's a non-starter. I think the key in your use case is that "hackability" is a feature, not a potentially life-threatening risk.