About EP address and enumeration

[turboscrew]

As a total newbie in the USB-world, I couldn't figure out how a device with multiple interfaces is enumerated.

The thing is, what are the scopes where EP number and EP address are unique?

Are the EPs device specific, interface specific or bus (controller) specific?
And how about the EP addresses?

I'm trying to put together a Remote NDIS host, and I wonder if the port numbering (and addresses) are continuing from
the control interface to data interface, or do both interfaces have EP zero and/or EP address zero?

How about if there's a HUB?
If each device has an address zero, does that mean that a physical bus (if HUB is considered to connect physical buses into a logical one) there can only be one device, or how does the host tell to a device (for descriptor request) that it is the one being addressed?

[Barry Twycross]

Each device has a set of endpoint addresses. Endpoints are addressed by number *AND* direction. (That "and" catches a lot of people out.) So every device can have the endpoints:

0-15 IN

and

0-15 OUT

Control endpoints are special cases. They take a pair of endpoints of the same number, so control endpoint 13 uses both 13-IN and 13-OUT. The default end point is control endpoint zero. (So uses zero-IN and zero-OUT.) There is one default endpoint per device. This endpoint can be used by the device and by all interfaces in the device. Control requests are addressed to the particular part of the device by the bmRequestType field of the SETUP packet. In effect each interface also includes endpoint zero.

Those are the physical endpoints a device can have. It doesn't have to have any except the default endpoint. It may implement any number of them up to the maximum. The device organizes the endpoints into interfaces via the configuration descriptor set. Any endpoint (except zero) can be assigned to any interface. An endpoint can not be assigned to more than one interface. An interface does not have to have any specific endpoints assigned to it, so can have zero endpoints (plus endpoint zero). See DFU for an interface which just uses the default endpoint.

After rereading your question, I'm not sure if you are confusing endpoints and device addresses. Endpoints (EPs) are specific to a device. Addresses are unique among devices on a bus. Each physical bus controller has its own set of device addresses 0-127. As traffic is broadcast, to just the bus the controller controls, a different controller can have another set of addresses as its traffic does not go to the devices controlled by the other controller.

Address zero is a special case, its only used for enumeration. The first thing the controller does is assign an address to a device which is addressed at device zero. A device gets address zero when it enters the default state after being reset. A reset also enables the port the device is attached to. So devices before reset do not see traffic to address zero, devices after reset see all traffic including traffic to address zero and respond to it. They are then addressed and no longer respond to it.

It is the controller's responsibility to ensure that only one device is addressed at device zero at one time. If it does not manage this the bus will no be able to enumerate a device reliably. Some OSs serialize enumeration to ensure this, my stack just had a mutex lock on the address zero. The controller can ensure this in the case of a device which does not respond correctly by disabling the port it is attached to.

Hubs do not change this behavior, all traffic is broadcast to all enabled ports. As I said, resetting a device (which is equivalent to resetting its port), enables the port it is attached to. So unrest devices do not see any traffic.

Device addresses and device endpoints (and device endpoint addresses), are separate concepts. You question does not seem clear on the distinction. To send data to a device it is sent to a specific device address, and to a specific device endpoint address. The address and endpoint pair defines exactly where the data is going on any particular bus.

[turboscrew]

First: Thanks. You cleared a lot.

This answers my "main" question completely (although, what follows, clarify more).

There is one default endpoint per device. This endpoint can be used by the device and by all interfaces in the device. Control requests are addressed to the particular part of the device by the bmRequestType field of the SETUP packet. In effect each interface also includes endpoint zero.

After rereading your question, I'm not sure if you are confusing endpoints and device addresses. Endpoints (EPs) are specific to a device. Addresses are unique among devices on a bus. Each physical bus controller has its own set of device addresses 0-127. As traffic is broadcast, to just the bus the controller controls, a different controller can have another set of addresses as its traffic does not go to the devices controlled by the other controller.

I kind of got confused.

Address zero is a special case, its only used for enumeration. The first thing the controller does is assign an address to a device which is addressed at device zero. A device gets address zero when it enters the default state after being reset. A reset also enables the port the device is attached to. So devices before reset do not see traffic to address zero, devices after reset see all traffic including traffic to address zero and respond to it. They are then addressed and no longer respond to it.

I read something about address zero EP zero and wondered how different devices could tell to which the message is meant.
Should I see address zero as broadcast?
How about device control messages? Do they go to device address + EP zero? If. then why some devices only use one interrupt IN EP?
Where are the control requests sent? Which address/EP?

Hubs do not change this behavior, all traffic is broadcast to all enabled ports. As I said, resetting a device (which is equivalent to resetting its port), enables the port it is attached to. So unrest devices do not see any traffic.

I understand that without HUBs it's one controller per bus = one connector = one device. And gadgets with multiple devices have internal HUBs (in principle)?

Device addresses and device endpoints (and device endpoint addresses), are separate concepts. You question does not seem clear on the distinction. To send data to a device it is sent to a specific device address, and to a specific device endpoint address. The address and endpoint pair defines exactly where the data is going on any particular bus.

Aha: "device endpoint addresses" - that's probably the missing "building block".
That probably caused my confusinon.

[Barry Twycross]

I read something about address zero EP zero and wondered how different devices could tell to which the message is meant.
Should I see address zero as broadcast?

Address zero is just another address. Its not a broadcast address, there is no broadcast address in USB. As I said, only one device ever has address zero at one time, and the controller driver has to ensure this is true, or things fall apart. Address zero is a transitory state, or should be.

How about device control messages? Do they go to device address + EP zero?

A device only worries about transactions addressed to it. So only transactions addressed to the device concern the device, so saying "device address + EP zero" seems like putting the wrong emphasis on things.

Control messages are usually sent to the device's default (control) endpoint. Ie the device's address, plus endpoint zero.

If. then why some devices only use one interrupt IN EP?

I don't see what you're getting at. Every device also has the default endpoint. Control messages are sent to the default endpoint. The interrupt endpoint is concerned with data for the device's actual function. A typical example would be a mouse. The interrupt endpoint sends coordinate data when available.

Where are the control requests sent? Which address/EP?

To the defult (control) endpoint, where else? As mentioned, every device has a default endpoint.

I understand that without HUBs it's one controller per bus = one connector = one device.

Every controller has a built in root hub. The root hub is not a physical hub, but a notional hub, to hang the controller's ports on. A root hub can have almost any number of ports. So a controller can have almost any number of ports. Though with the usual controller standards, the number of ports is limited by the width of status registers.

And gadgets with multiple devices have internal HUBs (in principle)?

Devices with multiple functions can be implemented as a hub with multiple devices, called compound devices (a multifunction printer/scanner would typically be a compound device). Or they can be implemented as one device with multiple interfaces, called composite devices. To confuse matters, most devices are composite devices with one interface.

[turboscrew]

The thing is: I'm trying to write an USB host CDC driver for a uC board with OTG-capable chip and no OS.
That's why I can't leave things to the host. :-)

[Barry Twycross]

I'm not sure I said you should leave anything to the host. If you're rolling your own host driver, you'll have to worry about all the points I mentioned. Though it sounds like your hardware does have only one port (on the root hub), which makes life easier. This is not the general case though.

What you need to do, goes something like this, you'll need to find how to do these steps in your documentation:

1. Turn the port on. (So port power appears at the connector.)
2. Wait until the port signals an attach
   There will usually be an interrupt for this, and a status register with an attach bit.
3. Do a port reset.
     The port may do the reset and report back,
     or you may need to set reset, wait 10 (or 50) ms and turn it off again.
4. Wait (at least) 10ms.
[This next step is really only necessary for full speed devices.]
5. Send a Get_Descriptor(device_descriptor) to address zero (endpoint zero)
    you can use a max packet of 64 here
    If the device is not the one you're expecting, you can give up now. The device descriptor tells you the VID/PID.
6. Send a Set_Address command with an address (1 is a good choice) to address zero (endpoint zero)
7. Wait at least 2ms (probably longer).
8. Configure EP zero for the new address.
    The device descriptor will tell you the max packet size to use, or 64 for high and 8 for low speed.
9. Send a Get_Descriptor(device_descriptor) to the device, ask for 18 bytes.
10. Send a Get_Descriptor(configuration descriptor) to the device for 1 max packet size
11. Send a Get_Descriptor(configuration descriptor) to the device for the total size of the descriptors (3rd and 4th byte received above)
 
You now have the descriptors which tell you which endpoints the device wants to use. You have to parse them to extract this information.

12. Configure the endpoints described by the endpoint descriptors above.
     endpoint number, direction and max packet size are the important information.
13. Make transactions as necessary to the data endpoints.

For a CDC device, any data you're given to send to the device gets sent on the Bulk/OUT endpoint of the data interface. Always have a read oustanding on the Bulk/IN endpoint of the data interface (there's usually an interrupt when thy complete). Asking for 1 max packet at a time would probably work best. When ever any data arrives on that endpoint send it to whoever's interested in it.

The above requires control requests. A generic control request goes like this:

1. Send the supplied 8 byte SETUP packet
2. If wLength if greater than zero, make a data transaction in the direction of bit 7 of bmRequestType for wLength bytes
3. Make a zero length transaction in the direction opposite to bit 7 of bmRequest type

Systems I've implemented to do this sort of thing have multiple components.
1. A hardware abstraction layer, it knows how to make basic transactions on the bus.
2. A system middleware layer to keep track of multiple devices and provide services and an abstraction to device drivers. (With only one device, you may not need that.)
3. A hub driver which looks after hubs and takes care of steps 1-8.
4. Device drivers which are matched to the information in the descriptors and know how to operate their particular device.

[turboscrew]

Thanks. I'm getting forward.
I managed to send RNDIS initialization message and got a sensible response message back.