USB is now a mature technology yet many people are not using it since they perceive it as \u201ctoo complicated.\u201d To date, all USB books and most USB technical articles have presented USB as a \u201ctechnical wonder\u201d and the reader is flooded with details such as packet types and descriptor parsing. Not surprisingly, many people who could take advantage of USB are holding back. This paper treats USB as a tool that can be used to solve real world problems in embedded systems design.
This paper works through a range of examples, starting with a single button and ending with an embedded USB host controller. There are three distinct sections; this introduction covers essential USB terminology but explained relative to RS232 which you already know; I then build a range of embedded devices that attach to a USB host such as a PC, Mac, Linux, or any USB- aware OS; I then add a mass storage device to an existing embedded product. You will discover that all of the low-level USB issues have been already solved and you can use these building blocks to solve your unique embedded system design challenges. These examples are downloadable from www.USB-By-Example.com.
Lets first compare and contrast a USB solution with an RS232 solution. Figure 1 shows a PC with four connected devices, two serial and two USB devices. A serial connection has two signal wires and a ground while a USB connection has two signal wires, a power and a ground. A USB connection has one extra wire but otherwise the hardware looks similar.
The operating system running on the PC (Windows, MacOS, Linux, or other OS) has built-in support for both types of devices and the layered structure of the software on this PC is also shown in Figure 1. I use Windows names in the figure but the layered architecture for MacOS, Linux and others is the same, they just change the names to keep us hardware folks on our toes!
Windows does a lot of work as a result of this Win32api call - it has to determine if \u201ccom1\u201d is a valid symbolic name then it has to attach to the correct low-level driver. But once you have a Handle you canReadFile, WriteFile, or send IOCTLs until you callCloseHandle.
Note that I have a scanner attached to com1 and a modem attached to com2. The application programmer needs to know this and the baud rate of each of these devices (read the manual) and also needs to know the data exchange protocol for each device (study the manual in detail). This is all quite straight forward and programs have been written like this for a long time.
But now look what happens if I swap the connections of com1 and com2. The scanner application will be connected to the modem and the modem application will be connected to the scanner. Both devices will be initialized incorrectly, the data exchange will be garbled and both applications will fail. This is the price we pay for allowing the user to bind the application program with the hardware connection.
but this is NOT how it works. We wanted to remove the user from the hardware binding process and let the OS do this work. When a USB device is attached to a PC the OS enumerates the device - it sends a series of commands to the USB device that discover what the device is. The USB device responds with fixed-format data structures, called descriptors that identify it completely. The OS uses this descriptor information to load the supporting device driver. It then places this information into the OS\u2019s PlugAndPlay tables.
Note that each has a unique VID_PID combination and they belong to a differentclass. All USB devices are assigned to a class - examples are HumanInterfaceDevice (HID), MassStorageDevice (MSC), Audio, StillImage, Video, Hub, VendorDefined, etc. - depending upon their functionality. When you read that USB devices are \u201cself-identifying\u201d this interrogation by the OS and discovery of the devices capabilities is the process that is being described.
Now lets turn our attention back to the applications programmer who wants to open one of these USB devices. The initial problem is that the programmer doesn\u2019t know the name of the device to use in the CreateFile API call. But the programmer knows the TYPE of device that they need to connect to, so they ask the PlugAndPlay manager \u201cdo you have any MassStorageClass devices attached.\u201d The PnP manager responds with a list and we use some algorithm to isolate our chosen device - in this example we would select the removable device. Similarly the audio application would search for, and open, an AudioClass device.
So with USB devices we have an extra step to identify our device since it doesn\u2019t have a pre- declared name such as COM1 or LPT4. The benefit is that the user could swap the USB cables and both applications would still work. Additionally there was no need to read the manual of either device to discover their characteristics - these were read by the OS during the enumeration process and are available to the applications programmer
Bottom Line: a USB device contains descriptors that the OS reads so that it can load the correct device driver. The PlugAndPlay manager makes this information available to the applications programmer so that it can be initialized or changed.
I get questions like this almost every week at my website and people are surprised when I explain that you don\u2019t have to be a USB guru to solve this kind of problem. They tell me how they have hacked a USB mouse or keyboard to get a simple button but have then fallen into the \u201csystem input device\u201d trap of Windows.
I am going to solve some typical USB interfacing problems and you won\u2019t have to buy any new development tools over what you already have for serial and parallel port interfacing. I shall use readily available commercial products to implement these solutions so that you should have no problems adapting them for your particular application.
My first example is a simple push button and matching LED to show that the button has been pressed. This button press will be recognized by a PC, and the PC can also independently light the LED. To solve this interfacing problem I am going to use a special USB-to-Serial cable manufactured by FTDI \u2013 note that this TTL232R cable does not use RS232 levels, it uses TTL levels to enable it to interface directly with microcontrollers and other TTL circuitry. My application isnot what this product is specifically designed for but it is fully tested and warranted - it is also quite cheap! This cable is shown in Figure 3.
Now bringing you back...
Does that email address look wrong? Try again with a different email.
This action might not be possible to undo. Are you sure you want to continue?