basic USB enumeration question

[MattCarp]

I just completed reading Jan's USB Complete book and seem to have missed a basic aspect to how the USB bus enumerates.   I think my question is pretty easy, but let me ask the forum for some clarification:

The step-by-step process in chapter 4 seems to cover how a device is set up, but, let's say you turn on a system.  There could be multiple devices on the system.  If all of the devices are indeed on a bus, how can you enumerate and set the address of one at a time, when, by default, all are set to address 00?

I can speculate that the answer is that when reset all ports are off and that the host controller will enable a port one by one, then enumerating any devices found?   Am I on the right track?

[Jan Axelson]

On detecting an attached device, the port's hub informs the host. The host requests the hub to reset the device's port. When the hub removes the reset, the device is in the Default state and only then is ready to respond to communications sent to address zero. After enumerating the device, the host repeats the process with the next device.

Jan

[MattCarp]

Hi Jan,  thanks for the reply!

AHA!  I Google'd 'usb hub "Get Port Status"' and was able to see a preview of a previous version of the book (I have the fourth edition), which includes a chapter 15 (pp 444-5), that is a little more specific.  Using the fourth edition, your reply, and the content from the prior edition, I think I've pieced it together.

So, when a hub or PC turns on, all ports are in the 'powered' state, but they are not connected to the bus.

The host controller polls each hub with a "Get Hub Status" request.  If there's a change in one of the ports due to a device attachment, the hub will indicate the change in the data stage response.  Then the host will issue a Get Port Status to the hub to learn that a device was attached, then continues with the enumeration process as described in the book (determine low/full speed, reset port, high speed check, set max packet size, set device address, then configure...)

Is that right?

I guess the port is polled with a "Get Hub Status" every xx milliseconds to detect these device attachments / detachments?   Given that there can be a number of hubs, this suggests a fair number of "Get Hub Status" polling requests.

[Jan Axelson]

yes

Jan

[MattCarp]

Perfect.

If I still have a balance in my USB question account  , is there any requirement as to how often a host needs to poll a hub?  i.e., is it in the spec?   After inspecting some Linux source, it appears that Linux just loops, so it polls as fast as it can.

[Jan Axelson]

In a quick search of the spec, I found no requirement for a polling interval for this request.

Jan

[MattCarp]

Thanks again!

Also, in reviewing the book again, I found the content in the fourth edition on page 383 (chapter 15) that covers the host's checking hub status to begin the enumeration process!

[Barry Twycross]

If Linux is doing Get Hub Status requests as a poll, that's a little weird. A hub has a status change interrupt endpoint, which is the normal way of getting notifications. The polling rate of the interrupt endpoint is specified as "FFH (Maximum allowable interval)" (Section 11.23.1) which is wrong as the maximum allowable poll for a high speed device is 16, which works out at around 4 sec I think, though most implementations won't poll an interrupt endpoint that slowly.

[Jan Axelson]

Hi Barry,

You're right of course. I wasn't thinking about the interrupt endpoint for some reason.

Jan

[mdlayt]

I wouldn't bother trying to put specs on the host (unless you are writing the host code, of course--in that case, by all means, meet the spec).

I'm certain I've seen my device suspend at times when the host (Win XP) had no business allowing it to suspend.

I think I can also say that it shouldn't take two or three seconds after you plug in a device (based on the USB spec) before you can connect to it from an app.

I'm curious what the guys doing audio have found.

I think you can plan that hosts will generally do things in a timely fashion, where timely fashion is defined as as:  how your host typically behaves, up to 100% slower.