14.2 More on USB

Originally I had planned to show an example on the second part of the USB tutorial. However, as I was writing the example, I realized that there are so many aspects of USB that requires more explanation. Therefore, before we begin any code, we need to take a closer look at some of the details of USB.

Vendor ID and Product ID

The consortium that runs the whole USB show is called the USB-IF, which is composed of major and minor players in the silicon and software business. Intel, Microsoft and HP are some of these major players. To uniquely identify each and every USB device, there are two 16 bit codes called the Vendor ID (VID) and Product ID (PID). Every USB device is required to have a VID and a PID. The VID identifies the manufacturer of the device and the PID identifies the product model. USB-IF REQUIRES all developers to register a proper VID with the implementers forum. The cost of such a venture is about $2000 for a onetime registration fee or, if you wish to become a USB-IF member and get benefits such as having your voice heard in the next USB standard revisions, then you can join the forum for a low annual fee of $4000. Personally, I have nothing to say about the next USB versions so I would just register the VID for a onetime fee.

So what would happen if you didn’t get registered? Well, for one, your device would never be deemed USB compliant. Secondly, there might be a device conflict in the real world. Many of the device drivers are written specifically for a particular VID and PID combination. If two different devices with the same VID and PID combination are plugged at the same time, a blue screen of death is a real possibility.

In any case, unless you are planning to sell a USB device, I would not recommend spending that money. You can use Microchip’s VID for development purposes. As for the PID, the assignment is arbitrary. There are no specific requirements in the USB standard that dictates how the PIDs should be assigned. However, make sure that the PID does not conflict with other Microchip devices that might be connected to your test PC. For example, don’t go out of your way to make a device with the same PID as the ICD3 or PicKit3 programmers.

Device -> Configuration -> Interface -> Endpoint

For a USB device, there is a hierarchy of how a communication message is sent. There are four levels in this hierarchy called the device, configuration, interface and endpoint. A device refers to the physical device that the USB connection is attached. Within the device, there can be one or more configurations. A device might have two functional purposes that are mutually exclusive. If specific drivers are implemented in the host, then the host can actively switch the device between configurations. Most devices only have one configuration. Within a configuration, there can be one or several interfaces. If there is only one interface within the device, it is considered a normal device. If there is more than one interface within the device, it is considered a composite device (e.g. a mouse-keyboard combo device). Each interface must have at least one endpoint. The required endpoint is the control endpoint, which, coincidentally transmit the description of the device to the host. In addition to the control endpoint, a USB device usually has at least one endpoint for data transfer during normal use. An endpoint only goes in one direction. For example, in the implementation of a generic USB mouse, the host only needs to read mouse pointer and click data. The host never needs to send any information to the mouse itself. Therefore, only one endpoint (on top of the required control endpoint) would be used to implement the mouse.

Endpoint Types

On top of the abstract communications layer hierarchy, there are also 4 flavors of endpoints. Control endpoints are used to extract configuration and descriptor information from the USB device. For our implementation, the control endpoints are almost completely automated by the USB stack and we don’t need to worry too much about it.

Bulk endpoints are used to transfer large amounts of data. USB hard drives, for example, use bulk endpoints to read and write from the hard drive disk. The data being transferred must not be time sensitive information (i.e. it doesn’t really matter when a file copy operation finishes). However data integrity is guaranteed since the host and device can request a resend of the data packet should the packet fail a CRC check. These requirements make bulk endpoints perfect for mass storage type applications.

Isochronous endpoints are used to transfer time sensitive information that is not critical, and does not require data integrity. For example, USB audio speakers require that the audio samples arrive at the speakers at a fixed frequency. However, if a sample fails to arrive at the speaker, there is no need to resend the audio sample. In applications where the information is being streamed live to the user (or to the host, as in the case of a microphone), isochronous endpoints are the ideal candidate.

Interrupt endpoints are time sensitive information that are extracted on a regular time interval. Your USB keyboard for example, is constantly sending information, even when no keys are pressed. Your USB mouse is constantly sending information to the host about whether a click has occurred or whether the pointer has moved. The information must be sent to the host on a tight schedule on the order of a few milliseconds (usually 1 to 5 ms). Even if the mouse pointer is delayed by a mere 100 ms or so, the mouse would feel sluggish, and would probably cost you many miss-clicks during its operation. HID devices only use interrupt type endpoints.

The reason for having these different types of endpoints is to allow a large amount of flexibility in the variety of USB devices. In addition, because USB connections are packetized into time frames, there can be an enormous amount of traffic demands on a single connection. With different endpoints, the priorities can be filtered. Obviously, the time-sensitive critical information must arrive at the host on a regular schedule. For this reason, control endpoints and interrupt endpoints take the first bite out of the USB connection’s available bandwidth. If there is any available bandwidth left, it is then distributed amongst the bulk and isochronous endpoints.

The descriptors transmitted by the device to the host describe which non-control endpoints are available within the interface. During the enumeration process, the host opens the control endpoint. Next the descriptors are transferred and read by the host. The host then loads the appropriate drivers, if any, so that the non-control endpoints described in the control endpoint can be read and written to. Once the endpoints are opened, the device connection is successfully established.

Endpoint Directionality

USB is a point to point type network, which means that a connection can only have two nodes. This connection can have several different varieties. These include host to device, host to hub, hub to hub, hub to device. In all of these cases, the directionality reference is always towards the host. An “input”, therefore is information from the device to the host, (i.e. from the host’s perspective, data is coming in). An output is data going out from the host, to a hub or a device. In the case of the hub to hub connection, one hub is actually considered the device. You will notice that on USB hubs, there is one USB connector that is different from the rest. The unique connector is the one that is connected to the USB host. If a series of hubs are chained together, the topology is still maintained (just think about it real hard). An input is still information going towards the host computer. In mouse example mentioned earlier, the endpoint is an IN direction endpoint. Serial communication devices such as a USB to serial point converter would require an IN and an OUT direction endpoint since communications must occur both ways. Control endpoints are special, and are considered bi-directional.

So that’s the gist of it. I think that’s most of what you need to know before we start coding.