Vadim Kaushan

Maybe these deserve to be in the panic-section too: * [`no-panic`](https://crates.io/crates/no-panic) * [`dont_panic`](https://crates.io/crates/dont_panic) + [`dont_panic_slice`](https://crates.io/crates/dont_panic_slice)

To support GD32V flashing we need three things: * JTAG support for CMSIS-DAP. This one needs (preferably common for different probe types) a JTAG machinery that exists only for FTDI...

@Tiwalun I tried running cli with `cargo run --features ftdi debug --chip riscv`, but no success: https://pastebin.com/90bYeuQq This `Target supports 0 breakpoints` looks suspicious, because I believe this chip does...

I believe probe-rs supports this chip, at least debugging worked through an FTDI probe.

As an alternative solution, one can set a `runner` parameter in `.cargo/config` to point it to a custom script which runs objcopy and dfu-util to program the chip. This runner...

I think that all errors should be additionally cleared before a transaction begins.

That's true, `synopsys-usb-otg` should work with this chip, but I haven't tried this pair yet.

The same thing happens with register bit `set()` and `clear()`: they are called as separate functions. I don't think that it's ok, because several bit-sets can be merged into one...

@agalakhov Yes, but I am talking about situation like this: https://github.com/mvirkkunen/stm32f103xx-usb/blob/57d23751367461bec5f39322727bdd65e5c2aa30/src/bus.rs#L162-L169

@david-sawatzke in general you can't have a write-only SPI. Imagine that you have some weird SPI controller that generates an interrupt on every RX FIFO overflow. You still need to...