MAX3421E NAK retry handling next frame

[IngHK]

This PR is intended to fix the problem as discussed in #2510 / issue #2541
The change means that in the case of a NAK, the transfer will only be repeated in the next frame (triggered by frame IRQ).
The 1st commit of PR is a first draft (not for merging) as a basis for further discussion and testing.

[IngHK]

I finished work now and It's ready for review and merge.
It can handle up to 10 retries per frame adjustable by CFG_TUH_MAX3421_MAX_ATTEMPS_PER_FRAME.
With value zero it's compatible with endless retries as before.

[hathach]

Perfect, thank you very much of the PR. Though I made some changes to

• always en-force max NAK with default = 1. IMO, this should work best for most people. We can increase to 2,3 should it has issue with throughput in the future
• add tuh_configure() cfgid to allow changing this behavior. This can only be used to change other max3421 behavior such as interrupt level polarity, edge in the future.
• add ep's hxfr

tested and confirmed it only send 1 token per frame, previously it would send around 6 IN token for the bulkd endpoint

[IngHK]

@hathach It doesn't work if cfg->max3421.max_nak is the maximum value.
Then it's running endless, because ep->state remains EP_STATE_ATTEMPT_MAX and that flags pending.
We really need an additional state "suspend", if the last attempt is NAKed.
I'll fix it soon...

[hathach]

That is ok max attempt can also be inferred as no nak limit as well. To be honest a usb frame will probably hold less than 10 retries due to back and forth spi transactions

PS: though we could add a check in the tuh_configure() to limit it to EP_STATE_ATTEMPT_MAX-EP_STATE_ATTEMPT_1

[IngHK]

@hathach I think, it's a little bit confusing, when last "attempt" is not a real attempt but instead used as suspend state.
On assembler level is it the same, but it's not easy to understand the code.
If you like I would create a commit with TU_VERIFY

[hathach]

thanks, I already made an PR to limit it #2565 #2566