Jan Axelson, USB Complete

Подождите немного. Документ загружается.

Chapter 6

156

Run Code from External Parallel Memory. If no EEPROM is detected, or if

the first byte isn’t C0h or C2h, and if EA is a logic high, the chip boots from

code memory on the external parallel data bus. ReNum is set to 1. The host

enumerates the device and loads a driver, and there is no re-enumeration.

#4/

For high-end applications, many developers turn to ARM microcontrollers,

which have a fast, efficient, 32-bit RISC architecture. ARM Holdings licenses

intellectual property (IP) cores to chip companies for use in their chips. The

ARM family includes a range of cores with different capabilities.

An example of an ARM processor with a USB device port is Atmel’s

AT91SAM7S321. The chip has a full-speed USB port, 32 KB of flash memory

for firmware, and 8 KB of RAM. Other I/O includes an 8-channel, 10-bit ana-

log-to-digital converter and synchronous and asynchronous serial ports. Pro-

gramming can use the free GNU GCC compiler or a compiler from IAR

Systems. NXP Semiconductors is another source for ARM-based device con-

trollers.

%QPVTQNNGTUVJCV+PVGTHCEGVQ%27U

A controller that interfaces to an external CPU enables adding USB to just

about any CPU circuit. A disadvantage is the need to use two chips instead of

having the CPU and USB controller on a single chip. Also, example code for

USB communications using your CPU might not be available.

Some interface chips support a command set for USB-related communications,

while others use a series of registers to store USB data and configuration, status,

and control information.

Most interface chips have a local data bus with a parallel interface to communi-

cate with the CPU. For fast transfers with external memory, many chips sup-

port direct memory access (DMA). To use DMA, the CPU sets up a transfer

that reads or writes a block of data to or from data memory without CPU inter-

vention. For CPUs that don’t have external parallel buses, a few controllers can

use a synchronous or asynchronous serial interface. An interrupt pin can signal

the CPU when the controller has received USB data or is ready for new data to

send.

Chip Choices

157

Table 6-3 compares a selection of interface chips. The following descriptions

will give an idea of the range of chips available. The chips described are a sam-

pling, and new chips are being released all the time, so for new projects, check

the latest offerings.

560:29KTGNGUU+52

The ISP1582 from ST-NXP Wireless is a full/high-speed controller that inter-

faces to an external CPU over a parallel interface.

#TEJKVGEVWTG

The chip has a serial interface engine for handling USB traffic, a 16-bit data

bus, and an 8-bit address bus. An external CPU can communicate with the

controller by accessing a series of registers. The controller supports multiplexed

and non-multiplexed address buses and DMA transfers.

75$%QPVTQNNGT

The USB controller supports full and high speeds. In addition to endpoint

zero, the chip can support up to seven IN endpoint addresses and seven OUT

endpoint addresses. All enabled endpoints share 8 KB of buffer memory. The

control endpoint has 64-byte buffers. Firmware allocates memory to each of the

other endpoint addresses, and any of these endpoint addresses can use double

buffering.

Firmware controls when the chip attaches to the bus. An external pull-up resis-

tor connects to the chip’s RPU pin and to a pull-up voltage. After a hardware

reset, the chip appears detached from the bus until the external CPU sets a reg-

ister bit that causes the chip to switch the pull-up onto the bus’s D+ line. This

firmware-controlled connection can give the chip time to initialize on power up

before the host begins enumeration.

The ISP1583 adds an ATA/ATAPI interface. The ISP1181B and ISP1183 are

options for full-speed devices.

2.:6GEJPQNQI[0'6

PLX Technology, Inc.’s NET2272 is a full/high-speed chip that interfaces to an

external CPU over a parallel interface.

Chapter 6

158

#TEJKVGEVWTG

A series of registers hold configuration data and other information. Packet buff-

ers hold USB data that has been received and data that is ready to transmit. The

parallel interface has 5 address bits and 16 data bits. Transfers to and from the

packet buffers can be 8 or 16 bits.

The registers store status and control information and the data received in the

last Setup transaction. The CPU also uses registers to read and write endpoint

data from and to the packet buffers.

The NET2272 supports three modes for accessing its registers. In direct address

mode, the five address bits specify a register to read or write to. In multiplexed

address mode, the CPU places the register address on the data bits and the

NET2272 reads the address on the falling edge of the ALE control signal. In

indirect address mode, the CPU uses the lowest address bit to distinguish

between a register address pointer (0) and data (1). The CPU writes a register

address pointer to specify a configuration register and then reads or writes data

at the address pointed to. Direct and multiplexed address modes can access only

registers 00h–1Fh, which typically contain the information accessed most fre-

quently. Indirect address mode can access all registers. The controller also sup-

ports DMA transfers. A CPU can write to the NET2272 at up to 60 MB/s and

can read at up to 57 MB/s (in DMA mode).

To access endpoint data in the packet buffers, the CPU selects an endpoint by

writing to the Endpoint Page Select register or the DMA Endpoint Select regis-

ter and then accesses the data by reading or writing to the Endpoint Data regis-

ter.

Table 6-3: These USB interface chips interface to an external CPU.

%QORCP[ %JKRU %27+PVGTHCEG $WU5RGGF

FTDI FT232BM Asynchronous serial Full

FT245BM Parallel Full

FT2232H, FT4232H Asynchronous serial

and parallel

High

ST-NXP Wireless ISP1181B, ISP1183 Parallel Full

ISP1582, ISP1583 Parallel Full/High

PLX Technology NET2272 Parallel Full/High

Chip Choices

159

75$%QPVTQNNGT

The NET2272’s USB controller supports full and high speeds and all four

transfer types. The controller has three physical endpoints in addition to end-

point zero. A device that needs more endpoints can use virtual endpoints,

where one or more logical endpoints share a physical endpoint’s resources. The

device firmware must switch resources between the logical and physical end-

points as needed.

Endpoint zero has a 128-byte buffer, and the other endpoints share 3 KB of

packet buffers. Two of the endpoints can use double buffers. After a failed IN or

OUT transaction, an endpoint automatically recovers and waits for the host to

retry.

(6&+75$7#46CPF75$(+(1

Future Technology Devices International (FTDI) offers controllers that are use-

ful for virtual COM-port devices and other devices that don’t fit a defined USB

class and need only bulk or isochronous transfers.

#TEJKVGEVWTG

FTDI’s chips take a different approach to USB design. The controllers handle

enumeration and other USB communications entirely in hardware.

The FT232R USB UART interfaces to a device CPU via an asynchronous serial

(UART) port. The controller handles all of the USB-specific protocols. Device

firmware just reads and writes data on the serial port. To send data to the host

computer, firmware writes the data to the asynchronous serial port. To read

data from the host computer, firmware reads the asynchronous serial port.The

FT245R USB FIFO functions in a similar way except the CPU interface is a

bidirectional parallel port. Both chips are full speed. The FT2232H is a

high-speed version with two ports that can each function as a UART or parallel

port. The FT4232H is high speed with four ports.

75$%QPVTQNNGT

Both the FT232R and FT245R have a 128-byte transmit buffer and a 256-byte

receive buffer. The chips use bulk transfers by default with one endpoint for

each direction. A driver for isochronous transfers is also available.

Chapter 6

160

On the host computer, the chips use a driver provided by FTDI. The driver

enables applications to access a chip as a USB virtual COM port or by using a

driver-specific API.

Many USB/RS-232 adapters contain FT232R chips. If you have an existing

device that communicates with a PC via RS-232, the FT232R offers a quick

way to upgrade to USB. In most cases, using an FT232R to convert an RS-232

device to USB requires no changes to device firmware or host application soft-

ware. The host accesses the device in the same way as if the device connected via

an RS-232 serial port.

Host software can access an FT245R as a COM port even though the chip

doesn’t have an asynchronous serial port. The host doesn’t need to know what

lies beyond the device’s USB port.

Both controllers contain on-chip EEPROM that can store vendor-specific val-

ues for a Vendor ID, Product ID, serial-number string, other descriptive strings,

and values that specify whether the device is bus- or self-powered. The control-

ler uses default values for items without stored values in EEPROM. FTDI pro-

vides a utility that programs the information into the EEPROM. By default,

the chips use FTDI’s Vendor ID and Product ID. On request, FTDI will grant

the right for your device to use their Vendor ID with a Product ID that FTDI

assigns to you. Or you can use your own Vendor ID and Product ID.

Figure 6-3. For easy prototyping with FTDI’s controllers, use the UM232R and

UM245R modules.

Chip Choices

161

Both chips also support a Bit Bang mode, where the chip operates as a basic

USB device without requiring a connection to a device CPU. A host computer

can monitor and control I/O bits on the chip to control LEDs, relays, or other

circuits and read switches and logic-gate outputs.

For easy prototyping, FTDI’s UM232R and UM245R modules (Figure 6-3)

each consist of a circuit board with a controller chip, USB connector, and

related circuits mounted on a 24-pin dual in-line package (DIP). The modules

fit breadboards or PC boards. A variety of other modules offer different form

factors, connectors, and capabilities. A chip with similar capabilities to the

FT232R is the Silicon Laboratories CP2102.

163



&GXKEG%NCUUGU

This chapter is an introduction to the defined USB classes, including how to

decide if a new design fits a defined class.

'NGOGPVUCPF7UG

Most USB devices have much in common with other devices that perform sim-

ilar functions. Mice send data about mouse movements and button clicks.

Drives transfer files. Printers receive data to print and inform the host when

they’re out of paper.

When many devices provide or request similar services, it makes sense to define

protocols for all of the devices to use. A class specification can serve as a guide

for programmers who write device firmware or host drivers. Drivers included

with an operating system eliminate the need for vendors to provide drivers with

their devices.

When a device in a supported class has features or abilities not included in a

class driver, a device sometimes can use a class driver along with a vendor-pro-

vided filter driver to support the added features and abilities.

Classes not currently supported by an operating system might be supported in a

future edition. Firmware that complies with a class specification for an unsup-

Chapter 7

164

ported class will likely be compatible with a driver added in a future edition of

the operating system.

#RRTQXGF5RGEKHKECVKQPU

The USB-IF sponsors device working groups that develop class specifications.

The defined classes cover most common device functions. Table 7-1 shows the

classes with approved specifications. The hub class is defined in the main USB

2.0 and USB 3.0 specifications rather than in a separate document. Every host

must support the hub class because the host requires a root hub to do any com-

munications. Chapter 4 listed the defined class codes for device and interface

descriptors.

Windows provides drivers for many classes. As Windows and the class specifica-

tions have evolved, the number of supported classes and the completeness of

support for those classes has improved. For some classes, such as the device

firmware upgrade class, Windows doesn’t provide a driver even though the spec-

ification has been available for many years. Table 7-2 shows the support for

each class under different Windows editions.

'NGOGPVUQHC%NCUU5RGEKHKECVKQP

A class specification defines the number and type of required and optional end-

points for devices in the class. The document may also define formats for data

to be transferred including application data and status and control information.

Some class specifications define uses for the data being transferred. For exam-

ple, the HID class has usage tables that define how to interpret data sent by

keyboards, mice, and joysticks. Some classes use USB to transfer data in a for-

mat defined by another specification. An example is the SCSI commands used

by mass-storage devices.

A class specification can define values for fields in standard descriptors and may

also define class-specific descriptors, interfaces, and control requests. For exam-

ple, the device descriptor for a hub includes a bDeviceClass value of 09h to

indicate that the device belongs to the hub class. The hub must have a class-spe-

cific hub descriptor with bDescriptorType = 29h. Hubs must also support

class-specific requests. For example, when the host sends a Get Port Status

request to a hub with a port number in the Index field, the hub responds with

status information for the port. A class may also require a device to support spe-

cific endpoints or comply with tighter timing for standard requests. Chapter 4

showed how the device or interface descriptor declares a class.

Device Classes

165

&GHKPGF%NCUUGU

The following sections introduce the defined classes. The purpose is to serve as

a guide to deciding whether a new design can use a defined class and if so, what

device controllers to consider and what host drivers are available. For more

information about a class, consult the class specification.

#WFKQ

The audio class encompasses devices that send or receive encoded voice, music,

or other sounds. Audio functions are often part of a device that also supports

video, storage, or other functions. Devices in the audio class can use isochro-

nous transfers for audio streams or bulk transfers for data encoded using the

MIDI (Musical Instrument Digital Interface) protocol.

Version 2.0 of the audio class specification retains much of the framework

defined in version 1.0 but is not backwards compatible. In other words, an

Table 7-1: These classes have approved class specifications.

%NCUU

8GTUKQP



&CVG &GUETKRVQT9JGTG%NCUU+U

&GENCTGF

Audio 2.0 05/06 Interface

Communication (CDC) 1.2 11/07 Device or interface

Content security 1.0 08/00 Interface

Device firmware upgrade (DFU) 1.1 08/04 Interface (subclass of Application

Specific Interface)

Human interface (HID) 1.11 06/01 Interface

IrDA bridge 1.0 03/00 Interface (subclass of Application

Specific Interface)

Mass storage 1.2 06/03 Interface

Personal healthcare 1.0 11/07 Interface (preferred) or device

Printer 1.1 01/00 Interface

Smart card 1.1 03/01 Interface

Still image capture 1.0 07/00 Interface

Test and measurement 1.0 04/03 Interface (subclass of Application

Specific Interface)

Video 1.1 06/05 Interface

The current version of the main specification document at this writing. Some classes have

additional, supplementary specifications.