The CH32V003 is a 10-cent RISC-V microcontroller with a proprietary single-wire debug interface and a corresponding proprietary debug dongle + modified version of OpenOCD.
My tool replaces the dongle and OpenOCD with a Pico-based GDB remote host. You can debug and flash a CH32V003 with just a Pico, one pull-up resistor, and gdb-multiarch.
Basic testing on the included example app seems to work, and the code should be stable enough to handle a few testers. If you're interested in the CH32V003 and have a Pico on hand, give it a try.
Very cool! For now, I'm using the PY32F002A for my low-cost MCU needs, but if this project was around a few months ago, I would have had to think harder about it.
I like that you've included a GDB server directly in the project, I've had way too much trouble getting a version of openocd that works properly for my pico projects, and now that's just cut out of the picture :)
That cool CH32V307VCT6 chip have 1GBPS ethernet MAC interface, yes 1 gigabit. For me is very interesting what is real benchmark numbers. anybody have any numbers?
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.
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.
> 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).
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.
Given the project needs more than just the MCU (or FPGA) chip itself, best to compare finished forms. The project OP posted uses a Pi Pico (aka ~$4) and a comparable form factor for an iCE40 is about $35-40ish.
Did the Pico steal your lunch money as a kid? Run over your dog? Otherwise why the extreme desire to use something ~10x more expensive and significantly higher power draw, for ZERO practical benefit? Don’t get me wrong, I love FPGAs and literally own dozens from $$ to $$$$ and have built many projects with them, but right tool for the job always should be considered.
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.
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.
My tool replaces the dongle and OpenOCD with a Pico-based GDB remote host. You can debug and flash a CH32V003 with just a Pico, one pull-up resistor, and gdb-multiarch.
Basic testing on the included example app seems to work, and the code should be stable enough to handle a few testers. If you're interested in the CH32V003 and have a Pico on hand, give it a try.
-Austin