Fixing an issue with windows device enumeration

[ryan-summers]

Fixes #128 by updating the library to ignore ep_in_status on the EP0 control pipe when in the Idle state.

If the device gets a zero-length-packet while transmitting the last portion of an EP0-IN transmission, it will internally transition to the Idle state immediately and essentially "forget" that it just sent an EP0-IN packet, so it was erroring when getting an indication that this packet successfully transmitted.

[thejpster]

This sounds right but ideally someone more familiar with the USB spec can weigh in.

[ryan-summers]

Just to help clarify here because I know this is all really opaque (and I'm no USB-spec expert myself), but this arises as a result of the usb-device API not maintaining the order that IN, OUT, and SETUP tokens arrive on the USB bus, so this doesn't really impact any usage of the USB spec, but rather how we process our internal state.

[thejpster]

Right but the spec will tell you what order you should expect things on the bus, and honestly I couldn't remember what the order was.

[ryan-summers]

Right but the spec will tell you what order you should expect things on the bus, and honestly I couldn't remember what the order was.

Yeah I recognize that :) Just wanted to provide a bit more context.

In general, the spec says that you should get SETUP -> IN/OUT -> OUT packets | Send IN packets -> STATUS: https://www.beyondlogic.org/usbnutshell/usb4.shtml#Control

However, a number of USB stacks will actually not follow the standard method and terminate transfers early etc.

In our case, ep_status_in_complete just means that our last IN packet was transmitted successfully, so we can do the next one (or transition to Status)

[thejpster]

I may be able to think about this in the next few days when I look at the ferrous USB device training course.

[ryan-summers]

Thanks for taking a look! Was on vacation for the last week, but I appreciate the review! :)