In recent years USB has taken the place of traditional serial standards
as the main communications protocol between devices. Lately, there has
been an increase in the market demand for products to support USB
devices like keyboards, printers, and memories; or for products to
communicate with a PC through the USB interface.
Since its introduction more than a decade ago, the Universal
Serial Bus (USB)
protocol has become a technology "rock
star". Walk into any electronic store and most likely one out of three
devices has a USB port.
It started as a substitute to old communications ports on the PC
such as RS232 and the parallel port to meet the new demands of the PC
market. And since then it has been used in everything from coffee mug
warmers to 10GByte hard drives.
The USB specification defines everything from mechanical connectors
and cables, all the way through operation of the system, network
layers, and power management. We will review some of these issues in
this article and look at some example im[lementations.
Brief history
The USB standard was officially introduced in 1995 by a consortium form
by seven computer and telecommunication industry leaders: Compaq, DEC,
IBM, Intel, Microsoft, NEC and Northern Telecom. Since then it has
grown to more than 1000 members in the USB implementers forum (USB-IF).
In 1996 the USB 1.0 standard was released specifying the main
aspects of the USB standard as we know it: support for 12Mbps high
speed bus and a low speed bus at 1.5Mbps, the definition of the
mechanical connectors, and the specification of the software stack.
By 1999 due to the popularity of the USB protocol and some problems
that had been identified, revision 1.1 was released. This version
clarified some ambiguities regarding timing and corrected some problems
that existed in the previous revision.
But not until 1999, when Microsoft and Apple incorporated the use of
USB into their operating systems did USB find "stardom". In the year
2000, the USB revision 2.0 was released specifying the implementation
of a 480 Mbps bus and backward compatibility with revision 1.1.
Later in 2001 the USB On-The-Go (OTG) supplement
was added. This was done to accommodate the increasing demand of USB
handheld devices and the need to have devices talk to each other. Some
of the features include smaller connectors and more efficient power
management.
Last year in May, the Wireless USB standard was
released which is a point to point wireless communications link based
on the USB network protocol. Presently, there are a few IC companies
making parts for the standard but these are in their final testing
stages.
The USB standard specifies a star network configuration where each
hub is the center of the star. The network has only one host per
system, typically this is the PC but with the introduction of the USB
On-The-Go (OTG) standard any device can be the Host.
The USB Bus can provide power to devices that connect to it. It
initially provides 100mA. This power can be used by devices during
configuration. Once the device is configured, the bus can increase the
current capabilities to 500mA.
Power distribution is one of the nice features that the USB
interface provides. As mentioned before; there are many products in the
market that use the USB port for power alone, like lamps, fans, and
coffee mug warmers. This kind of appliance usually use less than 100mA
since they do not initiate any handshake with the host, nevertheless
still it is 0.5W.
Some groups are working on creating a new standard for Powered USB
or USB PlusPower. The USB PlusPower
design would provide power voltages up to 24VDC and current capacity of
6A. This is achieved by two additional wire pairs inside the cable and
modified connectors that are backward compatible with the standard USB
connector.
The growth of applications for the USB bus has motivated the USB
organization to specify certain standard for products that have similar
characteristics, these groups are called classes. The creation of these
specifications allows developers to create generic device drivers that
could be used with different devices within the same class. A single
device can belong to multiple classes.
Doing USB designs - some design
guidelines
When starting a USB design, just as with any other project, one should
ask multiple questions that will help the designer to select the right
parts and architecture for the design:
* Is
this design considered a host, a device, or both?
* Is the instrument going to interact
with other devices or a PC?
* Are we communicating at low, full,
or high speed?
* Is it considered a high power or
low power device?
* Is the architecture going to be
based on stand alone design or
multiple
processors?
* If multiple processors are to be
used, how do they interface?
* To which devices is the design
going to interface? HID class?
Mass-storage? Etc?
*Should there be a USB hub?
* Do we need the USB compliance or
could we live without it?
As you proceed in your hardware design and look for solutions, you
will encounter an unlimited set of possibilities either for a host
design or peripheral. The most simple of these options is to purchase
an external USB conversion adapter that interface the communications
interface present in your design.
To do this, there are products from companies like B&B or Belkin
that convert USB to RS-232, or USB to Ethernet. Also there are
companies that already provide solutions with USB interfaces to DAQs
and motion controllers.
If the requirement is more stringent in cost and size, these
adapters can be implemented with a set of ICs, and the circuits can be
integrated with your present design. Some manufactures such as TI,
FTDI, and Kawasaki provide solutions to convert USB signals to Ethernet
or RS-232.
Other companies such as Philips, Micronas, Cypress, Atmel, and
Genesis provide solutions for specific designs including Flash Drive
Interfaces, Audio Codecs, and Smart Media.
If your solution requires a specific low-cost controller, companies
such as Microchips, Atmel, and Cypress provide 8-bit ARM controllers
with built-in device interfaces, host controllers, or on-the-go
controllers. These solutions usually integrate the physical layer and
some level of the error detection.
For more sophisticated designs, Freescale, Intel, TI, and NEC
provide higher end controllers with 32-bit cores or DSPs that allow you
to interface devices that are more complex and require more intensive
computing power. The implementation of a USB interface does not only
have implications on the hardware but also has implications on the
software.
If the design for a USB peripheral, then you need to be sure that
the software complies with the USB protocol handshakes and class
description. Usually the main USB software effort involves providing a
descriptor to the USB host and respond to the host instructions.
If the software being developed is for a host, the implications are
larger since the host is a more complex entity. The software in the
host must interface to the host controller (if it is another IC), the
USB protocol, and then the drivers for the device which may have to
comply with one of the pre-defined classes given by the USB
organization.
To assist the software development effort and minimize the risk of
meeting deadlines, one can look at commercial software that is already
available, especially when developing a USB host.
One option is to buy software stacks from companies such as
SoftConnex (owned by Transdimension) and Jungo. Depending on the
company, they usually provide a stack that has been rigorously tested
and can interface to either custom OSes or commercial ones. Also
depending on their license agreements and business strategies, they
provide different packages that include USB protocol only, USB class
stacks, source code, or onetime expense.
Another option is to use a commercial OS such as WindowsCE, Mentor's
Nucleus, Linux (commercial or not), etc. This option provides an OS and
in most instances includes drivers that are available and tested. Most
of these OSes are already ported to selected microcontrollers. In some
instances, the only task left is to create the host controller
interface since the host in embedded system designs is implemented with
a circuit that it is not common for PCs.
Example 1: A USB Peripheral/Host
A biomedical instrument had the following requirements with regard to
the communications interface:
*
Interface to USB printer
* Interface to USB keyboard
* Interface to USB Flash drive
* Interface to PC USB port
One special note is that the peripherals and the PC interface are
mutually exclusive. All of these features could have been implemented
with cheaper and simpler technologies such as serial and parallel
interfaces, but a primary attractive feature was the standardization
and availability of products with USB.
The design had included a 32-bit microcontroller to do the main
functions of the instrument and the user interface. So at the beginning
of the design, we looked at options of microcontrollers that had USB
features built in. Most of them only had USB device interfaces, and the
few that had host and device controllers were not available or were
more expensive than our final solution. So we selected a standard
32-bit controller and looked for a peripheral IC that would meet our
specifications.
To meet the above specification, we looked at multiple options and
ICs, mainly from Cypress and Phillips. We decided on the Cypress
EZ-Host solution (CY7C67300) because it had four channels which allowed
us to interface all the peripherals at the same time. It also had a few
options to interface the main 32-bit microcontroller and our experience
with their technical support has been great.
The diagram in Figure 1 below
shows a high level design, it only
includes the flash drive interface, the other two interfaces are also
attached to the EZ-Host.
 |
| Figure
1 |
We connected the Cypress part and memory mapped it into the
microcontroller memory space. Since we were connecting to off-the-shelf
peripherals, we had to be cautious with the design of the power supply
and power management of the USB bus. We had to mitigate in-rush
currents and limited the power consumption such that it did not drain
our power resources.
The next task was to choose a software development path. If this
instrument were a peripheral only, the software path would have been
much simpler since a peripheral only has to support a limited number of
functions to be USB compatible, mainly provide a descriptor and do some
handshaking.
But since this instrument also had host functionalities, the
software implications were large and became critical in the short
timeline we had for its implementation. We evaluated off-the-shelf USB
stacks, commercial OSes, and custom OSes.
The solution we came up with was to use a commercial version of
embedded Linux. This reduced the development effort of building the USB
drivers, it also gave us the flexibility to have drivers for a variety
of USB devices (printer, keyboard, and flash drive) that already exist,
and it had a lower cost than some of the other software stacks
available.
The only missing piece was the software interface required by the
host controller, but fortunately this was also provided by Cypress with
their development kit for the EZ-Host controller IC. Then it just
became a system integration effort.
Since this design other products are available in the market that
might ease the design process. Among these, there is a controller
designed by GHI Electronics called USBWiz that can interface USB
devices and interface a secondary processor through a serial port.
Example 2: Software Power Switch
A biomedical instrument had several USB devices (a camera and a motion
controller) all connected through a USB hub, built in.
As shown in Figure 2, below,
the design of the instrument required a
software-controlled power switch and limited the number of cables
between the PC and the instrument to one. Also, the power switch meant
that it had to be powered from a second source since the main power
supplies were not supposed to be ON.
 |
| Figure
2 |
Our solution was to integrate the power switch to the USB bus. The
design was based on a Microchip PIC18F2455 which has a USB interface.
The PIC was the interface to the USB port and it controlled a solid
state relay. This relay then switched the main AC power lines that were
the source for the main power supplies. We presented the device as a
HID interface such that the software development effort on the PC was
not a huge task.
Example 3: USB/RS232 Adapter
In another instance, a design came about that required a product
update. The present product was instrumentation equipment that had a
RS-232 interface to the PC (Figure 3,
below). The RS- 232 interface was
part of a proprietary circuit that was not well-documented, and the
owner did not want to make much of the schematic available.
 |
| Figure
3 |
For this application we used a similar Microchip part to the one
above. The reason this option was selected was were previous knowledge
of the vendor USB hardware, low cost, and flexibility to add new
features, such as more digital I/O lines and analog input. Other
solutions we could have used were RS-232 adapters from Belkin or
B&B, but these were too big for the space constraints the design
had, ICs from FTDI and TI were also available that required no software
development but the limitation was the digital I/O.
Example 4: USB Hub Design
In this application (Figure 4, below)
lwe had a need to connect four
RS-232 devices into a highly integrated device that had a built in PC.
Unfortunately the PC did not have any RS-232 ports. The only option was
to convert all the RS-232 lines to USB and put all off them through a
USB hub, such that we could connect it to the USB port of the PC.
 |
| Figure
4 |
For the RS-232/USB adapter we used a similar solution to the one
mentioned above. For the USB hub, we used a simple TI part number
TUSB2046, the reason we used this part was its simple integration, low
cost, and that it was USB 1.1 compatible. Other options were available
from Cypress and Philips, especially components that were USB 2.0
compatible.
Summary
The USB protocol has features that appeal to both product developers
and users, including bus powered devices, auto-detection, self
configuration, expandability, and speed. Of course, all of this
simplicity is at the cost of a more complex and expensive hardware and
software design than the older serial and parallel interfaces it
replaces.
The interface is flexible enough to use for common peripheral types
like drives and keyboards, as well as custom, application-specific
designs like medical instruments, instrumentation equipment, or coffee
mug warmers with PID controls.
Allan Neville is a Sr. Electrical
Engineer with Design
Continuum, Inc. He has over ten years of experience developing
embedded systems for medical and consumer products. He has worked on a
variety of projects designing and developing analog and digital
circuits, RF circuits, motion control systems, and PC interfaces. He
also has vast knowledge of firmware and software development.
References and resources
1) Universal Serial Bus Specification, Revision 2.0
2) USB Design by Example: A
Practical Guide to Building I/O Devices, Second
Edition by John Hyde
3) USB
Complete by Jan Axelson
http://www.penram.com/PC-Communication/USB-Complete.asp
4) www.beyondlogic.org/index.html#USB
" Has a great USB reference and links to a bunch of vendors.
5) www.usb.org
" Has all the standards and a few presentations that have useful
information
6) www.everythingusb.com
" Has a lot of products and new applications for USB
7) www.usbman.com
" Has a lot of developer tips and other useful stuff
This article is excerpted from a
paper of the same name presented at
the Embedded Systems
Conference
Boston 2006.
|