USB Complete fourth- P19 pptx

If no EEPROM is detected, or ifthe 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.. Some interface chips suppor

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

%QPVTQNNGTUVJCV+PVGTHCEGVQ%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

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

560:29KTGNGUU+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

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 ter and then accesses the data by reading or writing to the Endpoint Data

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

%QORCP[ %JKRU %27+PVGTHCEG $WU5RGGF

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

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 endend-points can use virtual endend-points, 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#46CPF75$(+(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

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

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

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

&GXKEG%NCUUGU

This chapter is an introduction to the defined USB classes, including how to decide if a new design fits a defined class

'NGOGPVUCPF7UG

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

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

#RRTQXGF5RGEKHKECVKQPU

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

'NGOGPVUQHC%NCUU5RGEKHKECVKQP

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

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

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

%NCUU 8GTUKQP &CVG &GUETKRVQT9JGTG%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

1 The current version of the main specification document at this writing Some classes have additional, supplementary specifications.