Interrupt driven transfers

[martinling]

This is an idea for how to make the USB transfer scheduling in RX and TX modes be interrupt-driven, freeing up the main thread for UI update or other functionality.

This requires telling the M0 core about the transfer size, and having it use the SEV instruction to interrupt the M4 whenever the byte count reaches a transfer boundary. This adds 6 cycles to the normal RX path but is still within limits.

This doesn't currently work, probably because usb_transfer_schedule_block isn't safe to call from an interrupt context. Setting an LED in the ISR indicates that it is being called, though.

[schneider42]

usb_transfer_schedule_block() (priority value 6) is now called in an interrupt with a higher priority than the USB0 interrupt (priority value 7). This means it can interrupt an ongoing call to the USB stack inside the USB0 interrupt. Maybe this can cause an issue. Maybe adding some guards around calls into the USB stack from the USB0 interrupt already helps?

[martinling]

usb_transfer_schedule_block() (priority value 6) is now called in an interrupt with a higher priority than the USB0 interrupt (priority value 7). This means it can interrupt an ongoing call to the USB stack inside the USB0 interrupt. Maybe this can cause an issue. Maybe adding some guards around calls into the USB stack from the USB0 interrupt already helps?

I'm calling nvic_set_priority(NVIC_M0CORE_IRQ, 192) in transceiver_startup to set the M0 event handler to the lowest possible priority, so it shouldn't be pre-empting anything except the now-empty while loops in rx_mode and tx_mode.

But I'm guessing something in that call isn't safe to do in an interrupt context at all. I haven't dug into it yet.

[martinling]

We didn't get this working at the time, the branch is now stale, and I'm not too keen on the way it uses up precious remaining cycles in the M0 loop.

I'm going to close this PR for now but it could be revisited.