USB : Overview    USB Is Like A Railroad  

Page 1

Most books on USB start out with all sorts of heart-stopping detail that make our eyes glaze over right away.

We figure you only want to learn enough USB to get your job done (but get it done right), so we’re going to take a different approach here. We’ll start off describing USB by an analogy. Occasionally, we’ll slip in a real USB term in parentheses, to show which part of our analogy corresponds to which term in the USB world.

  Click on the image for page view.

Page 2

You can think of USB as a railroad, and for simplicity’s sake, we’ll talk about just two railroad stations: one in your peripheral device, which we’ll think of as our cozy little home town called Hidville.
  Click on the image for page view.

Page 3

And the other is in your PC, which we’ll think of as the big bustling PC City.

It’s a pretty fast railroad, with a new train (USB Frame) leaving each station every millisecond. (That's every 0.001 second.)

  Click on the image for page view.

Page 4

We’ll think of ourselves as a business that has branches in both Hidville and in PC City. We need to send packages back and forth between these branches, using the USB Railroad.
  Click on the image for page view.

Page 5

 So, how do we get on the train?

  Click on the image for page view.

Page 6

If we can get a ticket on the train, the deal is pretty sweet: we get your own private railroad car —or if we need it, a whole set of private cars.

However, there is a catch: we may not be able to get on the train at all, unless we pay for our ticket with the right currency.

  Click on the image for page view.

Page 7

We don’t pay with money. Instead, we have to pay by providing detailed engineering specifications for our private car: how big it is, where and how the freight boxes are stacked inside it, and so on.

  Click on the image for page view.

Page 8

We have to provide this information in a rigid format that must please the rather dour Freight Manager, in PC City.

If he likes our specifications, we get our private car for use as often as we like (with some limitations). If he does not like our specifications, we do not get to go on the train at all.

Oh, and one more thing. If he doesn’t like our specifications, the Freight Manager won’t tell us why. He’ll just ignore us.

The PC City Freight Manager

(He's not a fun guy.)


  Click on the image for page view.

Page 9

Using this analogy, what HIDmaker FS does for you is to act like a really indulgent shipping company. The “HIDmaker FS Shipping Company” writes those engineering specs for you, and since it knows what the Freight Manager likes, it always gets them right.
  Click on the image for page view.

Page 10

Then, once you get your private car, the “HIDmaker FS Shipping Company” will actually pack and unpack the boxes for you, at each end!
  Click on the image for page view.

Page 11

Let ’s keep our railroad analogy going a little longer. For the moment, we don’t need to worry about the details of how to write those specs, but it would be helpful to know some general information about what we can ask the Freight Manager to grant us.

How much we want to ask for depends on how much freight (data) we need to ship, what kinds of freight we need to send in each direction, when it needs to get to its destination, as well as how many and what kind of destinations we have.

  Click on the image for page view.

Page 12

If our company (USB device) is relatively small and simple, perhaps just getting started, it may have only one office in Hidville.

  Click on the image for page view.

Page 13

As our company grows, it may have multiple Divisions (Interfaces), each of which sells a different product or service, so each Division (Interface) needs to send completely different kinds of freight (data).

  Click on the image for page view.

Page 14

Since our company is very well managed, at the very beginning its leaders put together a detailed business plan, that has distinct phases (Configurations).
  Click on the image for page view.

Page 15

In the first phase (Configuration 1), we expect the company to only have one product, the Gizmo, so it essentially has only one Division (Interface 0).

First Phase (Configuration 1)

  Click on the image for page view.

Page 16

In the next phase (Configuration 2), the company will expand its product line and need multiple Divisions to make them: the Gizmo Division (Interface 0), the Doodad Division (Interface 1), and the Gazinta Division (Interface 2).

Notice that the company will operate in only one phase (Configuration) at a time: it cannot be in multiple phases (Configurations) simultaneously.

Second Phase (Configuration 2)

  Click on the image for page view.

Page 17

All of the Divisions (Interfaces) are physically located in Hidville (our USB peripheral device).

In PC City(the PC), our company has a warehouse close to the train station, where our freight (our data) is placed when it is taken off the IN-bound train, or where it is placed by us before it gets loaded onto an OUT-bound train.

The directions IN and OUT are always relative to PC City (the PC).

  Click on the image for page view.

Page 18

Within each Division (Interface) in Hidville (our USB peripheral device), there can be multiple loading docks (Endpoints), where OUT-bound data from PC City (the PC) arrives at the Division (Interface), and where our company must place the IN-bound data that will go from the Division (Interface) to PC City (the PC).

These loading docks (Endpoints) come in pairs that are numbered and directional: e.g. there is a Loading Dock 1 IN (Endpoint 1 IN) that is only used to send freight (data) that is headed IN toward PC City (thePC), and next to it, there is a Loading Dock 1 OUT (Endpoint 1 OUT) that is only used to receive freight (data) that comes OUT from PC City (the PC).

Each Division (Interface) must have its own loading docks (Endpoints) -- they cannot be shared.

Page 19

As we said, each Division has completely different shipping needs, and these may fit into pre-defined classes that the Freight Manager in PC City knows about. (This is analogous to USB Classes, like HID class, Audio class, Mass Storage Class, and so on.)

These classes determine things like how often the freight (data) can go out, how much freight (data) there can be, and so on.

Since each Division (Interface) has unique shipping needs, each Division (Interface) can specify that it wants to use a specific class (USB Class).

Page 20

One of these shipping classes (which is analogous to USB HID class) requires our company to declare, in advance, exactly what freight (data) items we want to send, how big each item is, and how those data items will be arranged.

We also have to provide a kind of catalog description of the item, so that anyone can understand what each item is and what it is used for.

Page 21

In the shipping class (USB class) we are using (HID class), we have to specify in advance exactly what freight (data) will be contained in each shipment (Report).

A shipment (Report) can contain more than one railroad car (Packet).

A shipment (Report) can be larger than a single railroad car (Packet), in which case it will probably be split among several trains (USB Frames). There are rules about how our cargo must be split up, but we don’t want to get bogged down in too many details here.

Page 22

Keeping to our railroad analogy, shortly after our company is formed (i.e., shortly after our USB Peripheral device is connected to the USB cable, is powered up, and performs some initialization), it applies for the an account with the railroad to send freight (data) to PC City (the PC).

It does so by submitting a set of specifications (a set of Descriptors) to the Freight Manager in PC City (the PC).

  Click on the image for page view.

Page 23

These specifications have to be submitted as a series of complicated blueprints (Descriptors) that must all be filled in absolutely correctly, or the Freight Manager in PC City (the PC) will ignore us and not tell us what we did wrong.
  Click on the image for page view.

Page 24

First we have to provide information about who we are: our company name, and some numbers that are sort of like licenses. This is the top of our stack of blueprints.

This first blueprint sheet describes our company (Device Descriptor). It identifies our Company with names and numbers, and tells, among other things, how many phases (Configurations) our business plan will have.

  Click on the image for page view.

Page 25

Next, we have to describe other stuff in great detail, including the details of our business plan that describe our planned phases (Configurations) and the business Divisions (Interfaces) that will exist in each phase.

To do this, the second item in our stack of blueprints is a form that describes the first phase of the business plan (Configuration Descriptor) that identifies how many Divisions (Interfaces) that our Company (our USB peripheral device) will have in this business plan phase (Configuration of the device).

Our business plan might have more than one phase (Configuration).

  Click on the image for page view.

Page 26

Immediately following the blueprint that describes each phase (Configuration Descriptor), there needs to be a set of blueprints (Descriptors) that describes each company Division (Interface Descriptor for an Interface in this Configuration).

This in turn is followed immediately by other blueprints (HID Descriptor and Endpoint Descriptors) that are needed to completely describe this one company Division (Interface) in this phase of the business plan (in this Configuration).

Got all that?

(Hey, we didn't say this was easy!)

  Click on the image for page view.

Page 27

The process repeats for all company Divisions (Interfaces) in this business plan phase (Configuration of the USB device).

If the business plan contains more than one phase (i.e., if the device contains more than a single Configuration), then this whole process repeats as many times as necessary to describe all the phases in the business plan (Configurations in the device).

Page 28

In addition, we need to describe, in great detail, the freight (data) we will ship in each direction IN and OUT of PC City (the PC), and how it is packed together for shipment.

So, after all those other sheets, our stack of blueprints must contain sheets that describe in detail the freight that will be shipped (Report Descriptors).

  Click on the image for page view.

Page 29

Finally, the stack of blueprints should have some additional sheets that act as explanatory appendices. These sheets contain helpful footnotes (String Descriptors that contain important strings like the Vendor Name and so on).
  Click on the image for page view.

Page 30

You can see that this process is complicated. Getting any of the pages (Descriptors) out of order is just as bad as making a mistake on any one of them, and will also result in getting our request to use the railroad (USB) denied (ignored).

Or worse, it could lead to a crash!

  Click on the image for page view.

Page 31

The USB name for the process of submitting our specs is called “Enumeration.” You can see from our analogy above that when the device is plugged in to the USB cable, it must submit a bunch of numerical tables called Descriptors that tell the PC everything about the device and the data that it will send in each direction.

If the device sends descriptors that the PC thinks are correctly formed, and if the PC decides that there is enough bandwidth available on the USB cable for this device, then the PC will allow the device to send and receive data over the USB. If any mistakes have been made in constructing or sending these Descriptors, then the PC will simply ignore the device, and give no indication why.

  Click on the image for page view.

Page 32

Once the device passes Enumeration, it can receive OUT data from the PC, or make IN data available for the PC to take.

Please re-read that last sentence carefully.

It’s important to understand that USB is a Master/Slave technology. The PC or "Host" is the Master, and your peripheral device is the Slave. The PC polls the peripheral device: it can send OUT data to the device any time it wants, and the PC expects to be able to read IN data from the device any time it wants. The device can only wait with its data until the PC host decides to ask the device for it. Despite the fact that one of the USB transfer types is called “Interrupt” type, the slave device cannot actually interrupt the PC at all.

  Click on the image for page view.

Page 33

This Master/Slave relationship between the PC or "Host" (Master) and the peripheral (Slave) means that the USB hardware on each end is very different.

A USB peripheral device does not have the right kind of USB hardware to command another USB peripheral, so please don’t expect to be able to turn your microcontroller-based USB peripheral device into something that can control another USB device like a printer. It can’t happen.

Page 34

This doesn't mean that you can never make a microprocessor device that can act as a USB Master or "Host."  It is possible, provided that you start with a microprocessor device that has the special hardware needed to be able to do all the things that a USB Host needs to be able to do.

A host device needs to be able to do a lot more stuff than a USB peripheral does, like being able to talk to multiple devices (which may be of different USB classes), to be able to determine whether any specific peripheral device has been connected or disconnected, and whether a peripheral device is behaving properly at all times.

Microcontrollers that can act as USB Host devices generally are bigger, more expensive devices, with more processing power and more memory for storing both programs and data, compared with microcontrollers that can only work as USB peripherals.

Oh, and before we forget: it's a whole lot more complicated to program these USB Host devices.

Page 35

Finally, there are the most complicated USB devices of all: devices that can act as either a Master ("Host") or a Slave ("Peripheral"), depending on how they are connected to a special USB cable.

Dual role devices like this are called "USB On The Go" devices.

These relatively new devices tend to be bigger 32 bit processors, and yes, there is a lot of work that must go into programming devices like this.


Text Author: Dr. Bob Miller   Copyright Notice and Author Information