3 ms·

I understand pico is cheap, versatile and overall convenient. But is there anything (besides time) stopping you from implementing this on top of e.g. linux gpi

by snvzz 4y ago

I understand pico is cheap, versatile and overall convenient. But is there anything (besides time) stopping you from implementing this on top of e.g. linux gpio?

aappleby 4y ago
The timing on the SWIO interface needs to be within a few hundred nanoseconds if you want decent bandwidth, but I suppose there's nothing stopping you from running it on a slower and less real-time GPIO pin. You'd just need to swap out the implementation of the PicoSWIO class, the rest would be identical.
- zamnos 4y ago
  The RaspberryPi has a SMI mode that should be able to handle 62 MhZ on a single pin usefully, did you investigate using that at all?
  - aappleby 4y ago
    I'm not familiar with that interface, but I suspect it would have similar issues with timing tolerances as just bit-banging gpios.
    - zamnos 4y ago
      It's a programmable, parallel data bus, like you'd get on an old school micro to access external rom and ram. It'll DMA to/from the Pi's RAM, and has programmable timings for read and write signaling, so it's not at all like bit-banging GPIOs. The only question is if it's usable for your debugger project, as it's not meant for that.
- vardump 4y ago
  Pico is more than capable of handling timing within a few hundred nanoseconds with it's PIO (programmable IO) functionality. You don't usually ever need to bitbang with RP2040.
aappleby 4y ago
Actually, on second thought I'm not sure that would work. If you had an interrupt fire in the middle of a bit and held the line low for more than 8 microseconds (I think, would have to check the spec) you'd reset the debug interface and have to start everything over.
- snvzz 4y ago
  >8 microseconds Jesus christ. Nevermind what I said, then. Hardware (HDL for cheap FPGA like iCE40) might be helpful. A port to other microcontrollers should also be possible. Ideally you'd use a CH32V003 to assist in debugging/programming a second one. But Linux is out of the question. That's way too tight even for linux-rt. Keeping scheduling latency in the two digit microseconds is hard enough, and about as good as it gets. ... it might still be possible with Linux, but only by dedicating a core to the purpose, and making it otherwise unavailable to Linux. I believe that's how PiStorm works. In any event, how much effort any of these would involve is worth considering for determining whether or not it is worth doing, vs spending the time improving the rest of the project.
  - bschwindHN 4y ago
    > Hardware (HDL for cheap FPGA like iCE40) might be helpful. I'm a bit confused, isn't the pi pico the "hardware" in this instance? An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists (which is what the OP is using).
    - snvzz 4y ago
      >An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists Extreme overkill is good, particularly if it doesn't cost more money or use more power. That specific family of FPGAs is optimized for low cost and low power.
      - bschwindHN 4y ago
        Took a quick look at digikey: RP2040 - 1x unit price = $0.70 iCE40 - 1x unit price = $2.50 I'm not sure if low power is necessarily a priority for a debug probe that's always hooked up to a computer, but the RP2040 seems competitive with power consumption. From what I can see in the datasheets, they're both on a 40nm process node. I've never used the iCE40, is it easy to get a toolchain up and running for it? I haven't done any FPGA programming before but setting up the tooling always seemed more intimidating than using a standard C or Rust toolchain for a microcontroller. I'd still opt for the RP2040 in this case. RP2040 Datasheet - https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... iCE40 Datasheet - https://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/iCE/iCE40LPHXFamilyDataSheet.pdf https://www.latticesemi.com/~/media/LatticeSemi/Documents/Da...

by snvzz 4y ago

I understand pico is cheap, versatile and overall convenient. But is there anything (besides time) stopping you from implementing this on top of e.g. linux gpio?

aappleby 4y ago

The timing on the SWIO interface needs to be within a few hundred nanoseconds if you want decent bandwidth, but I suppose there's nothing stopping you from running it on a slower and less real-time GPIO pin. You'd just need to swap out the implementation of the PicoSWIO class, the rest would be identical.

zamnos 4y ago
The RaspberryPi has a SMI mode that should be able to handle 62 MhZ on a single pin usefully, did you investigate using that at all?
- aappleby 4y ago
  I'm not familiar with that interface, but I suspect it would have similar issues with timing tolerances as just bit-banging gpios.
  - zamnos 4y ago
    It's a programmable, parallel data bus, like you'd get on an old school micro to access external rom and ram. It'll DMA to/from the Pi's RAM, and has programmable timings for read and write signaling, so it's not at all like bit-banging GPIOs. The only question is if it's usable for your debugger project, as it's not meant for that.
vardump 4y ago
Pico is more than capable of handling timing within a few hundred nanoseconds with it's PIO (programmable IO) functionality. You don't usually ever need to bitbang with RP2040.

aappleby 4y ago

Actually, on second thought I'm not sure that would work. If you had an interrupt fire in the middle of a bit and held the line low for more than 8 microseconds (I think, would have to check the spec) you'd reset the debug interface and have to start everything over.

snvzz 4y ago
>8 microseconds Jesus christ. Nevermind what I said, then. Hardware (HDL for cheap FPGA like iCE40) might be helpful. A port to other microcontrollers should also be possible. Ideally you'd use a CH32V003 to assist in debugging/programming a second one. But Linux is out of the question. That's way too tight even for linux-rt. Keeping scheduling latency in the two digit microseconds is hard enough, and about as good as it gets. ... it might still be possible with Linux, but only by dedicating a core to the purpose, and making it otherwise unavailable to Linux. I believe that's how PiStorm works. In any event, how much effort any of these would involve is worth considering for determining whether or not it is worth doing, vs spending the time improving the rest of the project.
- bschwindHN 4y ago
  > Hardware (HDL for cheap FPGA like iCE40) might be helpful. I'm a bit confused, isn't the pi pico the "hardware" in this instance? An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists (which is what the OP is using).
  - snvzz 4y ago
    >An FPGA seems like extreme overkill for this when the Pico's PIO peripheral exists Extreme overkill is good, particularly if it doesn't cost more money or use more power. That specific family of FPGAs is optimized for low cost and low power.
    - bschwindHN 4y ago
      Took a quick look at digikey: RP2040 - 1x unit price = $0.70 iCE40 - 1x unit price = $2.50 I'm not sure if low power is necessarily a priority for a debug probe that's always hooked up to a computer, but the RP2040 seems competitive with power consumption. From what I can see in the datasheets, they're both on a 40nm process node. I've never used the iCE40, is it easy to get a toolchain up and running for it? I haven't done any FPGA programming before but setting up the tooling always seemed more intimidating than using a standard C or Rust toolchain for a microcontroller. I'd still opt for the RP2040 in this case. RP2040 Datasheet - https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... iCE40 Datasheet - https://www.latticesemi.com/~/media/LatticeSemi/Documents/DataSheets/iCE/iCE40LPHXFamilyDataSheet.pdf https://www.latticesemi.com/~/media/LatticeSemi/Documents/Da...