Вы находитесь на странице: 1из 17

Integrating USB into Products

Allan Neville
Design Continuum
Fall – Boston – 2006
Class #343

Abstract
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. This
course will go over the USB standard and how it can be integrated into present and
future products such that it can interface many of these devices. It will go over the design
implications and some solutions.

Introduction
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.

Swiss Army
Coffee Mug Warmer Illuminated Aquarium
Thumb Drive

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 most of these items through the paper and look at some examples.

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.

-1-
Integrating USB into Products Class #343

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.

Hardware Topology
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 network can have a maximum of seven levels of tiers; the first one being the host,
which is the root hub. The last level would have only devices, which means that there
can only be five non-root hubs connected together. Each segment will have a hub at the
center; the cable length for each segment can be 5 meters. That means that the
maximum distance between the host and the most remote device can be 30 meters
(uses six hubs). This could probably be increased by using devices like IOGear’s cable
boosters which boost host-device lengths of 75ft for full and low speed.

The USB host manages and controls the use of the bus, and it schedules and initiates
data transfers. No slave devices can assert signal on the bus until the USB host asks for
it. The host and hubs also take care of detecting when a device is attached or removed.
Each slave device on the bus is assigned a unique USB address through a process called
enumeration which is managed by the host. The maximum number of devices allowed
to connect to the bus is 127, this limitation is due to the address bit-field which is 7 bits
long.

-2-
Integrating USB into Products Class #343

The hub provides the connecting ports for the devices and provides power to the bus. It
also manages any fault detections and takes corrective actions.

As seen above, the data transfer rate is given by the hub that the device is connected to.
For example if a high speed device is connected to a full speed hub, the data rate will be
limited to the full speed rate. Also, higher speed hubs will support lower speed devices
and sustain the communications link to the upstream hub at the high speed rate.

Power Management
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.

Most of the USB devices (that communicate with the host) can be classified under three
groups: bus-powered, self-powered and hybrid powered. The bus-powered device sinks
power from the USB bus. This type of device could be either low power if it consumes
less than 100mA or high power if it consumes more than 500mA. USB devices that are
bus-powered have to report to the host that it will be drawing a given amount of
electrical current from the VBus in units of 100mA load, this is specified in the
descriptor.

-3-
Integrating USB into Products Class #343

A self-powered device gets its power from an independent power supply provided with
the device. A hybrid powered device takes power from both the USB bus as well as from
its own power supply. As in the case of a bus-powered device, it will have to report how
many units of load of electrical current will be drawn from the host via the USB bus.

USB hubs can also be self-powered or bus-powered. If the hub is bus-powered the
maximum current it can provide to any device downstream is 100mA, so, only low
power self-powered devices will work properly. Any high power device that is detected
would be able to report to the host to indicate an error.

Also, the USB bus allows for a suspend mode. In this mode a device can be put into a
low power consumption state without initiating a new configuration process. This is
done by the host sending three consecutive no SOF (Start-Of-Frame packets, see below).
Once the device detects this the device goes into suspend mode. In this mode the
device will not consume more than 500uA. In a special case, if the device can wake-up,
the host the current will be limited to 2.5mA. This specification would be indicated in
the descriptor of the device.

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.

Mechanical Connectors
The standardized connectors and cables defined in the USB specification details the
mechanical, electrical/mechanical stress, materials and electrical characteristics of the
cables.

The cable is made of four 28 AWG conductors, two for data and two for power. The
data pair is twisted to increase noise immunity. The cable construction can vary
depending on the USB speed designed for. Low speed cables do not require shield and
should be attached to the device while full and high speed cables are shielded and are
detachable. As mentioned before the cable length is limited to 5 meters. A cable
description is listed below:

Contact Number Signal Name Wire Color


1 Vbus Red
2 D- White
3 D+ Green
4 Gnd Black
Shell Shield Drain wire

The USB standard also describes how the connector should be constructed and
designed. In USB rev. 1.0, the connector and receptacle type A and B were specified.
These connectors were designed such that devices could be differentiated from hosts. All

-4-
Integrating USB into Products Class #343

of the connectors have longer power and ground pins to ensure that the device has a
stable voltage before the data signals are applied. Later in revision 2.0, the connector
and receptacle type Mini-B was added to the standard due to the increase of small
appliances that were using the USB standard. Recently with the introduction of the OTG
supplement, connector and receptacle type Mini A was added, and a receptacle type
Mini AB was added. These were added to accommodate the duality of products that
could be host and device. The receptacle Mini AB could receive connectors type Mini-A
and Mini-B. Also, a pin was added which is used for identification.

Type A Type B Type Mini A Type Mini B

Device detection
Once a USB device connects to the USB host data rate speed negotiations are carried
out. The current limiter on the host limits the current consumption to 100mA, this
should be enough power for a bus powered device to initiate the negotiations.

USB Cable

Current
Limiter 1.5K
Vbus Vbus

D+ D+

Host D- D- Device
Controller Controller

Gnd Gnd

Once the device is connected, either the D+ or the D- line will be pulled high. This
indicates to the host that a device is being connected. If the D+ is high, the device is a
full speed, if it is the D-, the device is a low speed device.

High Speed negotiation protocol occurs during the Bus Reset phase. A high-speed
device is initially detected as a full speed device. Once a device is detected, the host will
issue a reset signal by driving both D+ and D- to low (SE0). This resets the USB device to
a default USB address of 0. Soon after detecting the reset signal, the high speed device

-5-
Integrating USB into Products Class #343

will signal the host with a 480 Mbps chirp that lasts from 1 to 7 ms. A high speed host
or hub will recognize this signal as a request from a high speed device and respond with
a series of chirps. Once the high speed device sees this it will increase its speed to high
speed.

Physical Layer signaling


The USB standard does not include a clock signal, so the communications are
asynchronous. Data on the bus is encoded using Non-Return to Zero Inverted (NRZI)
with bit stuffing. This encoding enables the receiver to remain synchronized with the
transmitter without the overhead of sending a clock signal or start and stop bits with
each byte.

Instead of defining logic 0s and 1s as voltages, NRZI defines logic 0 as a voltage change,
and logic 1 as a voltage that remains the same. Each logic 1 will result in no change. The
bits transmit least-significant-bit (LSB) first.

Bit stuffing is required because the receivers synchronize on transitions. If the data is all
0s, there are plenty of transitions. But if the data contains a long string of 1s, the lack of
transitions could cause the receiver to get out of sync.

If the data has six consecutive 1s, the transmitter stuffs, or inserts, a 0 (represented by a
transition) after the sixth 1. This ensures at least one transition for every seven bits. The
receiver detects and discards any bit that follows six consecutive 1s. The bit-stuffing
overhead for random data is just 0.8%, or one stuff bit per 125 data bits.

The fundamental element of communications on the USB bus is the packet. A packet is
made of three parts: the start, the information, and the end of the packet. The start of a
packet will be the transition from the idle state (J) into an active state (K). In low speed
the D+ line is low and the D- is high when the bus is idle, and in full speed the D+ line is
high and the D- is low. The active state is defined the opposite way. For high speed the J
and K states are defined as the full speed bus specification but the idle state is when
both D+ and D- are low.

At the beginning of the packet there is sequence of transitions which is called the SYNC
sequence. This sequence is made of a chirp pattern of 32-bits where each bit is a J or K
state, as described above. The SYNC chirp pattern is KJKJKJK...KJKJKJKJKK. Some of these
bits will be used to synchronize the clocks of the host, hubs, and devices.

The packet information varies from 1 byte up to 1024 bytes. This section of the packet is
formed by the Packet Identifier (PID) and the payload. The PID is the first byte of the

-6-
Integrating USB into Products Class #343

packet, the first 4 bits of the byte are to identify the packet type while the other four are
the complement of the first four. This is used for error checking.

The last part of the packet is end-of-packet identifier (EOP). The EOP is indicated by
having both D+ and D- low for two bit times. In a high speed bus, the EOP is indicated
with 40 bit-times without a transition.

Packets
As previously mentioned, the packet is the basic component of the communications
standard. There are four types of packets: token packets which are used to set-up the
communications link and describe the direction and use of future packets; data packets
are used to carry data; handshake packets which are used as controls to maintain the
reliability and integrity of the link; and last is the special packets which are mainly used
with high-speed devices.

Below is a small diagram that describes the most common packets. The SOF (start of
frame) packet is used to indicate the beginning of a frame or microframe (see below). It
has 11 bits dedicated to the frame number and a 5 bit CRC.

The IN, OUT and SETUP packets are token packets that are used to setup the data
transfer between the host and the device. They contain a 7 bit device address, a 4 bit
endpoint address, and 5 bit CRC. The IN packet is used to setup data transfers from the
device to the host, the OUT packet is used for the transfer of data from the host to the
device, and the SETUP packet is a high priority OUT packet indicating the device that it
must accept it.

The DATA packets are used for data transfer, and this can have a payload that varies
from 0-1024 bytes. This type of packet has a 16 bit CRC for error detection. Also, when
transmitting data the software can toggle between the DATA0 and DATA1 token, this
helps to identify if packets have been lost.

The handshake packets are used by the data receiver to indicate the quality or the
reception. ACK indicates that the data was received without error. NAK is used by the
device to indicate that it is busy, STALL is used when a control request failed, and NYET
indicates that is not ready to receive more data.

-7-
Integrating USB into Products Class #343

Frames
All USB communication links are broken into frames. Each frame is transmitted every 1
ms. A high-speed host will also add a microframe every 125us to minimize the buffer
requirements for high speed devices at the cost of increasing the system complexity. The
first packet of each frame is the Start-Of-Frame packet (SOF).

Transfers
A predefined sequence of packets is called a transfer. The USB standard specifies four
different transfers to move different types of data, these are: Control, Isochronous,
interrupt, and Bulk.

-8-
Integrating USB into Products Class #343

The control transfer type is non-periodic, it is used mostly for commands and status
operations. All the devices must support control transfers over the default endpoint
(Endpoint 0). Control transfers require both and IN and OUT pipe.

Isochronous transfers have a fixed number of bytes per frame, the bandwidth is
guaranteed. The maximum number of bytes is 1024 per frame for full speed and 1024
per microframe for high speed. This transfer type is typically used for streaming data like
audio. It is error tolerant and it is only supported by full and high speed devices.

The interrupt type is periodic and the latency between transactions is guaranteed. The
maximum packet size is 8 bytes for low, 64 for full and 1024 for high speed bus.

The bulk transfer type is not periodic and it is used mostly to transfer large amounts of
data. The host controller ensures that bulk transfers are eventually completed but it does
not guaranteed its bandwidth. It is only supported by full and high speed devices.

Endpoints
All packets are sent to and received by the device via endpoints. Endpoints are buffers
where a device either puts data to go out or gets data that has arrived. Up to sixteen
endpoints can reside within a device. Each endpoint has a direction and an address. The
direction is from the host perspective: OUT is going into the device, and IN is coming
out of the device. Endpoint 0 is always the control endpoint and it contains both input
and output endpoints.

Once an endpoint is identified and defined, a pipe is established between the host and
the endpoint. The pipe is only removed once the device is removed from the USB bus.
Pipes are established for an interrupt and isochronous endpoints to ensure there is
sufficient bandwidth for the data transmissions.

Enumerations
Once the device is attached, enumeration starts. During enumeration, the host requests
a number of data structures called descriptors from the device. These descriptors contain
information about the number and type of communication channels, or endpoints, that
the USB device desires to use, as well as information about any device class.
Enumeration occurs on the default endpoint, which is endpoint 0, also known as the
control endpoint. The host also assigns a unique 7-bit address to the device, directing
communications to a particular device.

Descriptors
Descriptors are data structures that are provided by the device to the host during
enumeration. It describes the USB device’s attributes. It is typically stored in an EEPROM
in the device’s circuit. There are two types of descriptors; the standard descriptor that
pertains to all USB devices and the class descriptor that are associated with each
particular class.

Among the standard descriptors, is the Device descriptor, which contains general
information about the USB device, such as Product ID, Vendor ID, and such. The
Configuration descriptor provides information regarding specific device configuration.
The Interface descriptor tells the host how many endpoints a device feature uses, and it

-9-
Integrating USB into Products Class #343

also declares the class identity. The last type of descriptor is the Endpoint descriptor,
which describes the properties of an endpoint. These properties are namely whether the
endpoint is IN or OUT, etc. Each endpoint has its own descriptor.

Classes
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. Below we can see a list of the most common
classes and examples.

Class Name Sample of Application


Audio Class MP3 players, speakers
Mass Storage Class Flash drives, external CD-ROMs
Human Interface Device (HID) Class Mice, keyboards, joysticks
Imaging Class Cameras, video recorders
IrDA Class IrDA interface
Printer Class Printers

USB On-the Go
The On-The-Go specification is given as a supplement to add-on to the main USB2.0
specifications. Therefore the essence of USB being a Host-centric system has not
changed. What is new is that a device can have dual capability of a Host and Device on
the same USB connector. However, they can only be used as a Host or Device one at a
time and not concurrently.

As mentioned before a set of smaller connectors were defined to accommodate the


smaller size of the devices. The minimum power consumption is reduced to 8mA since
many of these devices can be battery powered and are limited in resources.

This supplement also adds specifications for the protocol that handles the dynamic
switching between device and host, and defines session request protocols (SRP) that
allow the host to turn on or off bus-powered devices.

Wireless USB
The Wireless USB specification was added in 2005 to meet the increasing necessity of
wireless devices. This specification uses Ultra Wide Band (UWB) as the physical platform
for communications.

The standard specifies throughput rates of up to 480Mbps (at 2 meters) and ranges of
up to 10 meters. This protocol is design as a host spoke architecture and allows up to
127 devices to attach to it. It has built in security features and power management
features for the radio.

As in previous standards it should be compatible with previous versions of USB standards


and for this purpose it defines entities that bridge the wired and wireless domains.

- 10 -
Integrating USB into Products Class #343

Devices that meet this standard are still in their infant stages. Some companies like NEC
and Wisair have some products available that would allow Wireless USB
communications.

Compliance
The USB organization has created a compliance program to ensure that devices meet
the standard specifications. Though no law mandates that any device must pass these
tests, doing so ensures that the user’s experience with your product will be as trouble-
free as possible.

The compliance program's two criteria are checklists and compliance testing. The
checklists contain questions relating to a product and its behavior. Separate checklists
exist for vendors of peripherals, hubs, systems with USB hosts, and cables. The checklist
covers mechanical design, device states and signals, and operating voltages and power
consumption. The checklists are available from USB-IF's website.

On-The-Go Basic- On-The-Go


Basic-Speed Version Hi-Speed Version Wireless USB
Speed Version Hi-Speed Version

For thorough testing of a product under a variety of conditions, USB-IF members can
enroll a device in the Compliance Program for a small membership fee. When a device
meets the compliance program's criteria, USB-IF considers it to have reasonable
measures of acceptability and adds it to its Integrators List of compliant devices.

Usage of the USB logo requires a product to be compliant as demonstrated by passing


the USB-IF Compliance Testing Program. There are a set of registered USB logos which
are not interchangeable, see above. On receiving a signed license agreement and
payment, USB-IF authorizes the device to display the USB logo.
In addition to successfully completing the USB-IF Compliance Program and having their
product included under their company name on the Integrators List, companies must
execute the USB-IF Trademark License Agreement to be eligible to use the logo in
conjunction with the product.

Solutions
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?

- 11 -
Integrating USB into Products Class #343

• 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 one-
time expense.

- 12 -
Integrating USB into Products Class #343

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.

Examples
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 below shows a high level
design, it only includes the flash drive interface, the other two interfaces are also
attached to the EZ-Host.

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.

- 13 -
Integrating USB into Products Class #343

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 about 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. 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.

- 14 -
Integrating USB into Products Class #343

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. 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. 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.

- 15 -
Integrating USB into Products Class #343

Example 4: USB Hub Design


In this application we 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.

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
This paper has shown you a glimpse of the USB standard and how can it be used in your
future projects. 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.

Reference
Documents
• Universal Serial Bus Specification, Revision 2.0
• USB Design by Example: A Practical Guide to Building I/O Devices, Second
Edition by John Hyde
• USB Complete by Jan Axelson

Web Sites
• www.beyondlogic.org/index.html#USB – Has a great USB reference and links to
a bunch of vendors

- 16 -
Integrating USB into Products Class #343

• www.usb.org – Has all the standards and a few presentations that have useful
information
• www.everythingusb.com – Has a lot of products and new applications for USB
• www.usbman.com – Has a lot of developer tips and other useful stuff

About the author


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.

Allan can be reached at aneville@dcontinuum.com

- 17 -

Вам также может понравиться