MAX3421 (host) and NAK handling

[IngHK]

I examined the CPU and USB usage on my host with STM32F401 (ARM M4 CPU 84 MHz) and MAX3421 (SPI 21 MHz).

With a CDC ACM device I saw that the CPU, SPI and USB are mostly busy handling the input stream endpoint.
The endpoint responds with NAK because there is no new data, and handle_xfer_done() in hcd_max3421.c causes the same stream to be repeated immediately (no other stream is pending).

This behavior largely utilizes the CPU with NAK-triggered interrupts.

Wouldn't a delay before a repetition make sense?

[IngHK]

I have now added an artificial delay to the MAX3421 interrupt using an internal HW timer.
The MAX3421 interrupt triggers the timer and the timer interrupt calls tuh_int_handler().
The timer is switched so that the first MAX3421 interrupt immediately calls tuh_int_handler() for a minimum inital latency, but subsequent calls only take place after a minimum time to limit call frequency.
This means that MAX3421 interrupts are processed as quickly as possible with a fast SPI bus and the CPU is blocked as little as possible.

[hathach]

I agree that current implementation retry too often too fast, maybe we should only limit 1 NAK per endpoint per usb frame (1ms). PR is welcome.