pico_stdio_usb should (optionally) support a mechanism to reboot the RP2040 device

[kilograham]

@MichaelBell has a fork which supports reboot when baud rate is set to 1200.

This is not ideal for picotool, because the OS is understandably not keen on you trying to talk CDC commands directly to a serial device it has claimed, and mapping from VID/PID to serial device is brittle/at-least-needing-of-an-external-library-for-cross-platform-support.

I suggest therefore, that we additionally define an additional interface for controlling the RP2040 (a sort of runtime companion to PICOBOOT but much simpler). picotool already needs a driver on windows anyways, so hopefully this isn't a huge issue for the user (although they may need to do this now for two interfaces?)

We can support both methods by #define in pico_stdio_usb, but we should document the extra interface so MicroPython, CircuitPython etc can support it in their REPL if they want

[hathach]

Maybe it is worth looking at dfu runtime, it uses control transfer and doesn’t take any extra endpoint and work with dfu-util commanddfu-util -e

https://github.com/hathach/tinyusb/blob/09868434cd9f53394350cce682333ada97f796c3/examples/device/dfu_runtime/src/main.c#L115

[swetland]

This is probably a whole separate issue, but along the idea of "hands free" development just with picotool and debug over usb, it might be worth defining a default fault handler and protocol for passing minimal fault info (PC, FaultAddr, etc) across a soft reboot (and if sram can survive that, possibly park in picoboot or a postmortem interface where one could pull a ram dump, backtrace, etc)....

[kilograham]

This is probably a whole separate issue, but along the idea of "hands free" development just with picotool and debug over usb, it might be worth defining a default fault handler and protocol for passing minimal fault info (PC, FaultAddr, etc) across a soft reboot (and if sram can survive that, possibly park in picoboot or a postmortem interface where one could pull a ram dump, backtrace, etc)....

can you please open this as a separate issue; as the main issue is fixed