USB polling mechanism

Why does USB use a polling mechanism instead of an interrupt to detect the device?

I've read here on Stack Overflow that if the event is

1. Synchronous (i.e., you know when to expect it within a small window)
2. Not Urgent (i.e., a slow polling interval has no ill effects), and
3. Frequent (i.e., majority of your polling cycles create a 'hit')

Then we can use polling. But in the case of USB, device detection is not frequent, so an interru开发者_开发技巧pt mechanism would be better.

There is no way for a USB device to "interrupt" its host controller in the same manner as other hardware interrupts. USB does support an Interrupt transfer method, but this is in fact implemented by polling 1 and the latency one can achieve is about 1 ms, but ultimately limited by the host's performance.

You asked

Why does USB polling mechanism instead of interrupt to detect the device?

Well, one reason would be that the USB protocol simply does not support interrupts at all in the usual hardware sense, most likely to keep the protocol simpler. For example, if a device wanted to interpret a transfer that was in progress, it would have to signal this somehow, either by corrupting an existing transfer, or an extra signal line would have to be added to whole system. Quickly polling the bus in hardware is fast enough for most types of devices.

Note that detecting a new device fails all three of your points where polling is recommended. Indeed, we never know when to expect a new USB device to appear on the bus (#1), it happens rarely (#3) and in the device is not active detecting it immediately is not a priority (#2). Why waste time and energy checking for an event that is unlikely to occur?