MIDI host interrupt issues

[cberger498]

Hi,

I am trying to interface a MIDI keyboard to an stm32f411-discovery board. I tried integrating the MIDI host example into my project only to find that it was making other tasks in my main program sluggish (e.g. drawing to a display).

I found that the USB_OTG_FS_IRQHandler() is occupying a majority of the CPU time (by toggling a GPIO and viewing the output on a logic analyzer). I tried running the midi_rx example on my board to rule out any issues with my program, but got the same results:

`void OTG_FS_IRQHandler(void) {
GPIOD->BSRR = GPIO_PIN_13; // set GPIO high
tusb_int_handler(0, true);
GPIOD->BSRR = GPIO_PIN_13 << 16; // set GPIO low

}`

Is this expected behavior? I suppose I could work around the issue by setting the IRQ to a low priority so that it doesn't dominate other interrupt-driven tasks, but it seems like the IRQHandler shouldn't be eating up this much of our CPU time.

[203Null]

Interestingly, the MIDI host is not listed under the project README.md. Is the MIDI host stack ready to be used, or are there still some works needed to be done? @hathach

[HiFiPhile]

Interestingly, the MIDI host is not listed under the project README.md

Nice catch ! I think we need a review of README.md.

I found that the USB_OTG_FS_IRQHandler() is occupying a majority of the CPU time

Currently there is no NAK retry limit in HCD DWC2, which leads to high CPU load. For OTG_HS enabling DMA can make the situation a lot better, for OTG_FS there is no chance but adding max_nak handling like in fsdev:

tinyusb/src/portable/st/stm32_fsdev/hcd_stm32_fsdev.c

Line 212 in dc00f35

_tuh_cfg.max_nak = tu_min8(cfg->fsdev.max_nak, HCD_XFER_NAK_MAX);