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. %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. 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. 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. 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 $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 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#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. 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. '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 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. #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 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 &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. . 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. 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. 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