gdbstub VS DAPLink

If you just want to transfer data without necessarily using a filesystem on your storage device, check out daplink. It implements a virtual FAT filesystem over USB so you can copy over firmware updates easily.

From what I've found that DAP-Link is actually an ARM Mbed open source project to basically be similar to STM32 ST-Link: https://github.com/ARMmbed/DAPLink

It's used for flashing the BBC micro:bit in both Microsoft MakeCode (makecode.microbit.org) and the micro:bit Python Editor (python.microbit.org). MakeCode uses it for lots of other devices like MakeCode Arcade too https://arcade.makecode.com )

It's amazing for students to be able to quickly get a program they've written in their browser onto a device in their hands that can respond to and interact with the real world.

Also great because with MicroPython and the Python Editor you get a standalone Python environment including REPL that's completely isolated from the PC - schools love it because no matter what the students do they're not going to break the host PCs.

(The firmware that implements web USB on the micro:bit's USB interface chip is open source, DAPLink https://github.com/ARMmbed/DAPLink - poke

https://github.com/ARMmbed/DAPLink/blob/main/source/daplink/...

Note the nested do { do { } while (); if (err) break;} while(); if (err) break;

Should that code be rewritten? Most certainly it should, and it should be given a proper Error type. However, when you are first porting it, you need to match semantics or you get a bunch of off-by-one, missed error, or missed end of stream bugs. And, as you point out, the Rust loop{} equivalents suck.

We've all written suboptimal code, and we all live in a suboptimal world. :)

I checked for DAPLink, but this seems to require keil, based on what I read in the readme.