Chapter 5 136 1VJGT4GSWGUVU In addition to the requests defined in the USB 2.0 and USB 3.0 specifications, a device may respond to class-specific and vendor-specific control requests. %NCUU5RGEKHKE4GSWGUVU A class can define mandatory and optional requests. Class drivers on the host should support the mandatory requests and may support optional requests. Some requests are unrelated to the standard requests, while others build on standard requests by defining class-specific fields. An example of a request that’s unrelated to standard requests is the Get_Max_LUN request supported by some mass-storage devices. The host uses this request to find out the number of logical units the interface supports. An example of a request that builds on an existing request is the Get Port Status request for hubs. This request is struc- tured like the standard Get Status request but bits 4 0 = 00011 indicate that the request applies to a unit other than the device, an interface, or an endpoint. (The request applies to a port on a hub.) The wIndex field contains the port number. 8GPFQT&GHKPGF4GSWGUVU Implementing a vendor-defined request in a control transfer requires all of the following: • Vendor-defined fields as needed in the Setup and Data stages of the request. Bits 6 5 in the Setup stage’s data packet are set to 10 to indicate a ven- dor-defined request. • In the device, code that detects the request number in the Setup packet and knows how to respond. • In the host, a vendor-specific device driver that supports the request. The driver can expose a function that enables applications to initiate the request. 137 %JKR%JQKEGU This chapter is a guide to selecting a device controller. The chips covered include USB 2.0 controllers with basic USB support as well as more full-fea- tured, high-end chips. Chapter 20 discusses controllers for use in USB On-The-Go devices. For information on USB 3.0 controllers as they become available, visit www.Lvr.com %QORQPGPVUQHC75$&GXKEG Every USB device must have the intelligence to detect and respond to requests and other events at the USB port. A programmed microcontroller or an appli- cation-specific integrated circuit (ASIC) can perform these functions in a device. Device-controller chips vary in how they implement USB communications and in how much firmware support the communications require. Some controllers require little more than accessing buffers to provide and retrieve USB data. Others require device firmware to handle more of the protocol, including man- aging the sending of descriptors to the host, setting data-toggle values, and ensuring that endpoints return appropriate handshake packets. In general, Chapter 6 138 low-level firmware isn’t portable among chips with different architectures, but chip companies provide example firmware for common tasks and applications. A USB device controller contains a USB port along with whatever buffers, reg- isters, and other I/O capabilities the controller requires to accomplish its tasks. Some device controllers include a general-purpose CPU and on-chip program and data memory or an interface to these in external memory. Other device controllers must interface to an external CPU that handles non-USB tasks and communicates with the USB controller as needed. These chips are sometimes called USB interface chips to distinguish them from microcontrollers with USB capabilities. For high-volume products and products that require fast performance, an option is a custom-designed ASIC. Several sources offer synthesizable VHDL and Verilog source code for ASICs that function as USB controllers. +PUKFGC75$%QPVTQNNGT A typical USB 2.0 controller contains a USB transceiver, a serial interface engine, buffers to hold USB data, and registers to store configuration, status, and control information relating to USB communications. 6JG6TCPUEGKXGT The USB transceiver is the hardware interface between the device’s USB con- nector and the circuits that control USB communications. The transceiver is typically embedded in the chip, but some controllers allow interfacing to an external transceiver. 6JG5GTKCN+PVGTHCEG'PIKPG The circuits that interface to the transceiver form a unit called the serial inter- face engine (SIE). The SIE handles sending and receiving data in transactions. The SIE doesn’t interpret or use the data but just places provided data on the bus and stores any data received. A typical SIE does all of the following: • Detect incoming packets. • Send packets. • Detect and generate Start-of-Packet, EOP, Reset, and Resume signaling. • Encode and decode data for the bus using NRZI encoding with bit stuff- ing. • Check and generate CRC values. Chip Choices 139 • Check and generate Packet IDs. • Convert between USB’s serial data and parallel data in registers or memory. $WHHGTU USB controllers use buffers to store received data and data that’s ready to trans- mit on the bus. In some chips, such as PLX Technology’s NET2272, the CPU accesses the buffers by reading and writing to registers, while others, such as Cypress Semiconductor’s EZ-USB series, reserve a portion of data memory for the buffers. To enable faster transfers, some chips have double buffers that can store two full sets of data in each direction. While one block is transmitting, firmware can write the next block of data into the other buffer so the data is ready to go as soon as the first block finishes transmitting. In the receive direction, the extra buffer enables a new transaction’s data to arrive before the firmware has retrieved the data from the previous transaction. The hardware automatically switches, or ping-pongs, between the two buffers. Some controllers, such as the Cypress EZ-USB FX2 series, support quadruple buffers. %QPHKIWTCVKQP5VCVWUCPF%QPVTQN+PHQTOCVKQP USB controller chips typically have registers that hold information about what endpoints are enabled, the number of bytes received, the number of bytes ready to transmit, Suspend-state status, error-checking information, and other status and control information. The number of registers, their contents, and how to access the registers vary with the chip architecture. These differences are one reason why low-level firmware for USB communications typically isn’t portable between chip families. %NQEM USB communications require a timing source, typically provided by a crystal oscillator. Because USB’s low speed allows more variation in clock speed, low-speed devices can sometimes use a less expensive ceramic resonator. Some controllers have on-chip oscillators and don’t require an external timing source. 1VJGT&GXKEG%QORQPGPVU In addition to a USB interface, the circuits in a typical USB device include a CPU, program and data memory, other I/O interfaces, and other features such Chapter 6 140 as timers and counters. These circuits may be in the controller chip or in sepa- rate components. %27 An on-chip CPU in a microcontroller may be based on a general-purpose archi- tecture such as the 8051, or the CPU may have an architecture developed spe- cifically for USB applications. An interface-only USB controller can communicate with any CPU that has a compatible interface. 2TQITCO/GOQT[ The program memory holds the code that the CPU executes, including code for USB communications and whatever other tasks the chip is responsible for. This memory may be in the microcontroller or in a separate chip. The program storage may use ROM, flash memory, EEPROM, EPROM, or RAM. All except RAM (unless battery-backed) are nonvolatile: the memory retains its data after powering down. Chips that can access memory off-chip may support a megabyte or more of program memory. Another name for the code stored in program memory is firmware. The term suggests that the memory is nonvolatile and not as easily changed as program code that can be loaded into RAM, edited, and re-saved on disk. This book uses the term firmware to refer to a controller’s program code, with the understand- ing that the code may reside in a variety of memory types, some more volatile than others. ROM (read-only memory) must be mask-programmed at the factory and can’t be erased. ROM is practical only for product runs in the thousands. Flash memory is electrically erasable and thus is popular for use during project development and for final code storage in low-volume projects or devices that might require firmware updates in the field. Current flash-memory technology enables around 100,000 erase/reprogram cycles. EPROM (erasable programmable ROM) is reprogrammable but is not electri- cally erasable and thus has been replaced by flash memory in recent chips. EEPROM (electrically erasable PROM) tends to have longer access times than flash memory but is useful for storing data that changes occasionally such as configuration data. Cypress’ EZ-USB controllers can store firmware in EEPROM and load the firmware into RAM on powering up. EEPROMs are available with parallel interfaces and with synchronous serial interfaces such as Chip Choices 141 Microwire, I 2 C, and SPI. Current EEPROM technology enables around 10 million erase/reprogram cycles. RAM (random-access memory) can be erased and rewritten endlessly, but the stored data disappears when the chip powers down. RAM can store program code if using battery backup or if the code loads from a PC into RAM on each power up. Cypress Semiconductor’s EZ-USB chips can use RAM for program storage with special hardware and driver code that loads code from the host computer into the chip on power up or attachment. RAM loaded in this way has no limit on the number of erase/rewrite cycles. For battery-backed RAM, the limit is the battery life. Access time for RAM is fast. &CVC/GOQT[ Data memory provides temporary storage during program execution. The con- tents of data memory may include data received from the USB port, data to be sent to the USB port, values for use in calculations, or anything else the chip needs to remember or keep track of. Data memory is RAM. 1VJGT+1 To do useful work, virtually every USB controller has an interface to the world outside itself in addition to the USB port. An interface-only chip must have a local bus or other interface to the device’s CPU. Most chips also have a series of general-purpose input and output (I/O) pins that can connect to other circuits. A chip may have built-in support for other serial interfaces, such as an asyn- chronous interface for RS-232, or synchronous serial interfaces. Some chips have dedicated interfaces for special purposes such as accessing drives or audio components. 1VJGT(GCVWTGU A device-controller chip may have additional features such as hardware timers, counters, analog-to-digital and digital-to-analog converters, and pulse-width-modulation (PWM) outputs. Just about anything that you might find in a general-purpose microcontroller is available in a USB device control- ler. Chapter 6 142 5KORNKH[KPI&GXKEG&GXGNQROGPV Project development will be easier and quicker if you can find a controller chip with all of the following: • A chip architecture and compiler you’re familiar with. • Excellent hardware documentation. • Well-documented, bug-free example firmware for an application similar to yours. • A development system that enables easy downloading and debugging of firmware. Also helpful is the ability to use a class driver included with the operating sys- tem or a well-documented and bug-free driver provided by the chip company or another source. These are not trivial considerations. The right choices will save you many hours and much aggravation. &GXKEG4GSWKTGOGPVU In selecting a device controller suitable for a project, these are some of the areas to consider: Speed. A device’s rate of data transfer depends on the supported speeds on the device and bus, the transfer type. and how busy the bus is. As a device designer, you don’t control how busy a user’s bus will be, but you can select a speed and transfer type that give the best possible performance for your application. If a product requires no more than low-speed interrupt and control transfers, a low-speed chip might save money in circuit-board design, components, and cables. But low-speed devices can transfer only up to eight data bytes per trans- action, and the USB specification limits the guaranteed bandwidth for an inter- rupt endpoint to 800 bytes per second, much less than the bus speed of 1.5 Mbps. Plus, implementing low speed’s slower edge rates increases the manufac- turing cost of low-speed controller chips, so you may find a full-speed chip that can do the job at the same or lower price. Compared to low and full speeds, circuit-board design for high-speed devices is more critical and can add to the cost of a product. If possible, devices that sup- port high speed should also support full speed so they will work with USB 1.x hosts and hubs. Chip Choices 143 Endpoints. Each endpoint address supports a transfer type and direction. A device that uses only control transfers needs just the default endpoint. Inter- rupt, bulk, or isochronous transfers require additional endpoint addresses. Not all chips support all transfer types. Not every controller supports the maximum possible number of endpoint addresses, but few devices need the maximum. Firmware upgrades. For firmware upgrades in the field, store program code in flash memory, in EEPROM, or in RAM loaded from the host on attachment. The Device Firmware Upgrade USB class specification defines a protocol for loading firmware from a host to a device. Chapter 7 has more about this class. Cables. One reason why mice are almost certain to be low-speed devices is the less stringent cable requirements that allow thinner, more flexible cables. A cable on a low-speed device has a maximum length of 3 m, while full- and high-speed cables can be 5 m. Other needs. Additional considerations are the amount and type of other I/O, the size of program and data memory, on-chip timers, and other special features that a particular application might require. %JKR&QEWOGPVCVKQP Most chip companies supplement their data sheets with technical manuals, application notes, example code, and other documentation. The best way to get a head start on writing firmware is to begin with example code. Example code can be useful even if it doesn’t perfectly match your desired appli- cation. Enumeration code is useful for any device and also provides a model for performing control transfers for other purposes. Get Descriptor can serve as a model for other control read transfers. Set Address can serve as a model for con- trol write transfers with no Data stage. Example code for control write transfers with a Data stage is harder to find. The only standard, not-class-specific USB request with a host-to-device Data stage is the rarely supported Set Descriptor. One possibility is in code for the communications device class with support for the class-specific Set Line Coding request, where the host sends serial-port parameters in the Data stage. From the firmware’s point of view, bulk and interrupt transfers are identical (except for SuperSpeed’s support for streams in bulk transfers) so code for either type of transfer (such as HID code for exchanging reports via interrupt trans- fers) can serve as a model for any firmware that uses bulk or interrupt transfers. Chapter 6 144 Chip and tool vendors vary in the amount and quality of documentation and example code provided. You might also find code examples from others who are willing to share their work. &TKXGT%JQKEGU If your device fits into a class supported by the operating system(s) that the device’s USB hosts use, you don’t have to write or obtain a device driver. For example, applications can access a HID-class device using standard API func- tions that communicate with the HID drivers included with Windows. Some chip companies provide a generic driver that you can use to exchange data with devices. Cypress Semiconductor, Microchip Technology, and Silicon Laboratories all have general-purpose drivers. Devices for Windows systems also have the option of using Microsoft’s generic WinUSB driver. Chapter 7 and Chapter 8 have more about classes and device drivers. &GDWIIKPI6QQNU Ease of debugging also makes a big difference in how easy it is to get a project up and running. Products that can help include development boards and soft- ware offered by chip companies and other sources. A protocol analyzer can save much debugging time. Chapter 17 has more about protocol analyzers. $QCTFUHTQO%JKR%QORCPKGU Chip manufacturers offer development boards and debugging software to make it easier for developers to test and debug new designs. A development board enables you to load a program from a PC into a chip’s program memory or cir- cuits that emulate the chip’s hardware. Typical debugging software provided with development boards is a monitor program that runs on a PC and enables you to control program execution and view the results. Common features include the ability to step through a pro- gram, set breakpoints, and view the contents of the chip’s registers and memory. You can run the monitor program and a test application at the same time. You can see exactly what happens inside the chip when it communicates with your application. USB’s timing requirements can limit what you can do with breakpoints. For example, if you halt execution during enumeration, the host will give up, and you’ll need to restart the enumeration process. But even so, a monitor program can provide a useful window to the firmware in action. Chip Choices 145 The Silicon Laboratories C8051F34x controllers include a dedicated 2-wire debugging interface that uses no additional memory or port bits on the chip. With these chips, you can debug without needing to assign other chip resources to debugging. $QCTFUHTQO1VJGT5QWTEGU If you’re on a limited budget, inexpensive printed-circuit boards from a variety of vendors can serve as an alternative to the development kits offered by chip manufacturers. You can also use these boards as the base for one-of-a-kind or small-scale projects, saving the time and expense of designing and making a board for the controller chip. Boards that include firmware and a host driver make it easy to exchange data with the device. I/O Boards. A typical board contains a USB controller and connector along with I/O pins that you can connect to external circuits of your own design. The EZ-USB family is a natural choice for this type of board because its firmware is downloadable from the host so you don’t need additional programming hard- ware. Figure 6-1 shows two high-speed USB boards with EZ-USB chips: the USBee EX2 Experimenter’s Board from CWAV, Inc. and the QuickUSB Module from Bitwise Systems, Inc. Both boards contain programmed Cypress EZ-USB FX2 controllers, Both companies provide host drivers for generic I/O including accessing a high-speed parallel port, and example applications in multiple pro- gramming languages. The USBee EX2’s driver enables configuring and reading and writing to an 8-bit port. The QuickUSB’s driver and user libraries enable accessing up to five 8-bit ports and provides functions to support a parallel port, asynchronous serial ports, I 2 C and SPI communications, and configuring FPGAs. A stacking connector mates with an adapter board with headers for accessing the ports. Two asynchronous serial ports have RS-232 interfaces. Another option is the USBI2C/IO (Figure 6-2) from DeVaSys Embedded Sys- tems. This board contains a Silicon Laboratories full-speed USB C8051F340 with 63 KB of flash memory. Headers provide access to 31 I/O bits plus an I 2 C port. DeVaSys provides firmware, a host driver for accessing ports and I 2 C communications, and example applications. Emulating a Device with a PC. Using a PC to emulate a device is another option for developing. You can use the compilers, debuggers, and other soft- ware tools you’re familiar with on your PC and compile, run, and debug the device code on the PC. PLX Technology’s NET2272 Rapid Development Kit . high-speed USB boards with EZ -USB chips: the USBee EX2 Experimenter’s Board from CWAV, Inc. and the QuickUSB Module from Bitwise Systems, Inc. Both boards contain programmed Cypress EZ -USB FX2 controllers,. that handles non -USB tasks and communicates with the USB controller as needed. These chips are sometimes called USB interface chips to distinguish them from microcontrollers with USB capabilities. For. ASICs that function as USB controllers. +PUKFGC75$%QPVTQNNGT A typical USB 2.0 controller contains a USB transceiver, a serial interface engine, buffers to hold USB data, and registers