Jan Axelson, USB Complete
Подождите немного. Документ загружается.
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