Fixing processing order of EP0 (control) transactions

[ryan-summers]

This PR fixes an issue with the processing order of multiple EP0 events.

Specifically, if both EP0-IN and EP0-OUT events have occurred, we have to process EP0-IN first so that we update the ControlState properly. Otherwise, we inadvertently process the EP0-OUT status phase as a spurious OUT transfer (instead of the STATUS phase as expected).

This only occurs when both EP0-OUT and EP0-IN transactions occur at the same time, which occurs when polling is completed at a lower-than-continuous rate.

After this fix, this crate can be used in debug configuration reliably as well.

[mvirkkunen]

Hmm, yes, I believe processing them in this order will be more reliable because the SETUP is handled second, and that always resets everything back to working order. I wonder if we should also add ep_out.unstall() into ControlPipe when SETUP is received, just in case the IN handling code still ends up stalling it for some reason?

[ryan-summers]

I wonder if we should also add ep_out.unstall() into ControlPipe when SETUP is received, just in case the IN handling code still ends up stalling it for some reason?

That doesn't sound like a bad approach to me - I assume we would only unstall() when we correctly parse a setup packet.
Edit: I've now added this

I think it's also safe to remove the compiler warning when compiling for debug. Edit: I dont think this is still in master.

[mvirkkunen]

Thanks! My tests pass for this so I'll release a new version with these changes. This should make things more reliable in the future.