USB enumeration order

Allan,

I don't know the answer to your direct question (although I suspect the answer is that, for practical matters, the order of enumeration remains the same if nothing in the system change), but as for what you're trying to accomplish:

...the usual way to make this happen is to just program a unique serial number into each FTDI chip and assign port numbers based on that. This gives you another level of "indirection" that also makes it easy to shuffle which port is which on a per device basis, not have any problems if you need to add another (initially unforeseen) device, etc.

In the Linux world people do this quite routinely, since -- unlike Windows -- Linux makes no attempt whatsoever to remember device serial numbers (if present) and then re-associate them with the port number last used, if possible. :-)

---Joel

The order of enumeration could change since it can depend on the speed of the devices being up and ready after power on. Normally not a big deal, but some devices can be slow if they need to do some extra work before they are ready.

I think the enumeration order is the sequence of which devices appear on the bus. The proper way to find the usb device is to look for the vid & pid, which involves calling the API for the device list. The FTI chips probably all have the same vid and pid, and are enumerated as com 1 to whatever.

Since your looking for 232 devices your periphials should have a mechanism to identify themselves. So for each 232 device you would scan com 1 to whatever to find it.

Cheers

It is entirely dependent on the host software. If you need things to happen in a particular order then you'll have to control, as you say, when your hubs are enabled. It is /likely/, but not certain, that it will always be the same in practice.

If you have a number of identical devices (FTDI) then give each a unique serial number. Alternatively read the port index since your application/driver will know the hardware layout.

Andrew

be

No, it's depending of the power-up conditions of the devices, and the way the system and/or driver(s) will process them.

Q : Why does your app depend on this ? You should be able to identify your devices independantly of their enumeration, don't you ?

In this case, hardware details doesn't matter, it's still USB.

I understand that you've find a way to make life easier, but I'm not quite sure you can do it that way.

Can't you just identify your devices by a unique ID ? You won't be dependant of the system then.

see:

-- Marco UCO Lick Observatory Laboratory for Adaptive Optics

No, it's depending of the power-up conditions of the devices, and the way the system and/or driver(s) will process them.

Q : Why does your app depend on this ? You should be able to identify your devices independantly of their enumeration, don't you ?

In this case, hardware details doesn't matter, it's still USB.

I understand that you've find a way to make life easier, but I'm not quite sure you can do it that way.

Can't you just identify your devices by a unique ID ? You won't be dependant of the system then.

...

No. I'm sorry, I really should have made this explicit: the EEPROM devices that hold the identity information are blank when soldered to the board. There is no way to distinguish the different devices other than by the number of the port on the hub.

Once I have identified the devices by their port number, I can program unique numbers into the EEPROM via USB. But until then, the devices themselves don't know what they are and have no distinct identity.

This is really a problem regarding the manufacturing of the board. Once the EEPROMs are programmed, it should be easy. But when the EEPROMs are blank, it's a lot harder.

There are other approaches, e.g. using a bed of nails to program the parts, but I'd like to avoid the cost.

Regards, Allan

This document describes "Location IDs"

" ... and Location ID 0x00000023 represents host controller 1 port 3."

That would seem to meet my needs.

Thanks to all who replied.

Allan

BTW, I am aware that certain FTDI parts contain unique numbers that are programmed in (by laser?) when the parts are manufactured. But that doesn't help here.

Regards, Allan

If you have access to your operating system's source code for the USB stack, you could add some hooks to remember the port number when it is enumerated. If not, then even in the FTDI driver, if you write it yourself, you may be able to get this information from whatever handle the OS passes to the initialization routine.