Jan Axelson, USB Complete

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

Chapter 6

146

(RDK) enables using a PC as a device when developing code using PLX Tech-

nology’s NET2272 USB interface chip. The kit includes a PCI card with a

header that attaches to a daughter card that contains a NET2272. You can

install the PCI card in a PC and write applications that perform the role of

device firmware that communicates with the interface chip. The application

can run as a console application on the PC.

The USB connector on the PCI card can connect to any USB host. When

development on the emulated device is complete, you can port the firmware to

run on the CPU that the final design will use. If you want to use the develop-

ment kit’s circuits, you can remove the daughter board from the PCI card and

wire the daughter board to your device’s hardware.

The emulated device may have timing differences, and the may not have the

same hardware architecture as the target device, but the ease of developing on a

PC can help in getting the code for enumerating and basic data transfers work-

ing quickly.

Figure 6-1. Two development boards for the Cypress EZ-USB FX2 are Bitwise

Systems, Inc.’s QuickUSB Module (left, shown with adapter board) and CWAV,

Inc.’s USBee EX2 Experimenter’s Board (right).

Chip Choices

147

75$/KETQEQPVTQNNGTU

If you have a favorite CPU family, the chances are good that a USB-capable

variant is available. The family with the most sources for device controllers is

the venerable 8051. Although Intel, the 8051’s creator, no longer offers

USB-capable 8051s, other manufacturers do. Table 6-1 lists chips that are com-

patible with this and other microcontroller families.

For common applications such as keyboards, drives, and interface converters,

application-specific controllers include hardware to support a particular appli-

cation. Chapter 7 has more about controllers for specific applications.

The following descriptions of USB controllers with embedded CPUs will give

an idea of the range of chips available. The chips described are a sampling, and

new chips are being released all the time, so for any new project, check the latest

offerings.

Figure 6-2. The DeVaSys USB I2C/IO board contains a Silicon Labs C8051F340,

which has an on-chip debug port.

Chapter 6

148

/KETQEJKR2+%(

Microchip Technology’s PIC microcontrollers are popular due to their low cost,

wide availability, large selection, good performance, and low power consump-

tion. The PIC18F4550 contains a USB controller that can function at low and

full speeds. Microchip offers other variants with different combinations of fea-

tures.

#TEJKVGEVWTG

The PIC18F4550 is a member of Microchip’s high-performance, low-cost,

8-bit PIC18 series. Firmware resides in 32 KB of flash memory. The chip has 2

Table 6-1: USB controller chips that are compatible with popular microcontroller

architectures are available from many sources.

%JKR(COKN[ /CPWHCEVWTGT %JKRU $WU5RGGF

ARM Atmel AT91SAM7S full

AT91SAM9R64 high

NXP Semiconductors LPC292x, LPC214x full

Atmel AVR Atmel AT90USBx,

AVR32UC3

low/full

Infineon C166 Infineon C161U full

Intel 80C186 AMD Am186CC full

Intel 8051 Atmel AT89C513x full

Cypress

Semiconductor

CY7C64713 EZ-USB full

CY7C6801x EZ-USB full/high

Silicon Laboratories C8051F34x low/full

Standard

Microsystems

Corporation (SMSC)

USB2005, USB222x full, full/high

Texas Instruments TUSB3210/3410 full

TUSB6250 full/high

Microchip PIC18 Microchip Technology PIC18F2455/2550/

4455/4550,

PIC18(L)F1xK50

low/full

STMicroelectronics ST7 STMicroelectronics ST7260 low

ST7265X full

ST7268x full/high

Chip Choices

149

KB of RAM and 256 bytes of EEPROM. A bootloader routine can upgrade

firmware via the USB port.

The chip has 34 I/O pins that include a 10-bit analog-to-digital converter, a

USART, a synchronous serial port that can be configured to use I

C or SPI,

enhanced PWM capabilities, and two analog comparators.

The USB module and CPU can use separate clock sources, enabling the CPU

to use a slower, power-saving clock.

75$%QPVTQNNGT

The USB controller supports all four transfer types and up to 30 endpoint

addresses plus the default endpoint. The endpoints share 1 KB of buffer mem-

ory, and transfers can use double buffering. For isochronous transfers, USB data

can transfer directly to and from a streaming parallel port.

For each enabled endpoint address, the firmware must reserve memory for a

buffer and a buffer descriptor. The buffer descriptor consists of four registers.

Firmware can access the register’s contents as a structure, a single 32-bit value,

or a byte array (Listing 6-1).

The status register contains status information and the two highest bits of the

endpoint’s byte count. The byte-count register plus the two bits in the status

or the number of bytes expected or received in an OUT transaction. The

address-low and address-high registers contain the starting address for the end-

point’s buffer in RAM.

The microcontroller’s CPU and the USB SIE share access to the buffers and

buffer descriptors. A UOWN bit in the buffer descriptor’s status register deter-

mines whether the CPU or SIE owns a buffer and its buffer descriptor. The SIE

has ownership when data is ready to transmit or when waiting to receive data

on the bus. When the SIE has ownership, the CPU shouldn’t attempt to access

the buffer or buffer descriptor except to read the UOWN bit. When readying

an endpoint to perform a transfer, the last operation the firmware should per-

form is to update the status register to set UOWN, which passes ownership to

the SIE. When a transaction completes, the SIE clears the UOWN bit, passing

ownership back to the CPU.

Each endpoint number also has a control register that can enable a control end-

point, an IN endpoint, an OUT endpoint, or a pair of IN and OUT endpoints

with the same endpoint number. Other bits in the register can stall the end-

point and disable handshaking (for isochronous transactions).

Chapter 6

150

// A buffer descriptor table holds 4 bytes.

// This union enables firmware to access the bytes in different ways.

typedef union __BDT

{

struct // Four 8-bit variables.

{

BD_STAT STAT; // Status byte structure

BYTE CNT; // Byte count, bits 0-7

BYTE ADRL; // Endpoint address in RAM, low byte

BYTE ADRH; // Endpoint address in RAM, high byte

};

struct // The endpoint address in RAM

{

unsigned :8;

BYTE* ADR; // Address pointer

};

DWORD Val; // One 32-bit value.

BYTE v[4]; // Byte array.

} BDT_ENTRY;

Listing 6-1: Firmware can use structures to represent the contents of an

endpoint’s buffer descriptor table. (Part 1 of 2)

Chip Choices

151

// This union represents the buffer descriptor’s 8-bit status register in a variety of ways.

typedef union _BD_STAT

{

BYTE Val; // Byte variable

struct // Bit values if the CPU owns the buffer.

{

unsigned BC8:1; // Byte count, bit 8

unsigned BC9:1; // Byte count, bit 9

unsigned BSTALL:1; // Buffer stall enable

unsigned DTSEN:1; // Data toggle synchronization enable

unsigned INCDIS:1; // Address increment disable

unsigned KEN:1; // Buffer descriptor keep enable

unsigned DTS:1; // Data toggle synchronization value

unsigned UOWN:1; // USB ownership

};

struct // Bit values if the USB module owns the buffer.

{

unsigned BC8:1; // Byte count, bit 8

unsigned BC9:1; // Byte count, bit 9

unsigned PID0:1; // PID, bit 0

unsigned PID1:1; // PID, bit 1

unsigned PID2:1; // PID, bit 2

unsigned PID3:1; // PID, bit 3

unsigned :1;

unsigned UOWN:1; // USB Ownership

};

struct // The 4-bit PID

{

unsigned :2;

unsigned PID:4;

unsigned :2;

};

} BD_STAT;

Listing 6-1: Firmware can use structures to represent the contents of an

endpoint’s buffer descriptor table. (Part 2 of 2)

Chapter 6

152

Additional registers store the device’s bus address and status and control infor-

mation for USB communications and interrupts.

Devices with simpler I/O needs can use the 20-pin PIC18(L)F1xK50 series.

Microchip provides USB Framework firmware and example applications for

USB communications. The firmware is written for Microchip’s C compiler for

PIC18 CPUs. The Framework handles general USB tasks and some class-spe-

cific tasks. The files may require only minor changes and additions for a specific

application. Provided example projects include keyboard, mouse, generic HID,

mass storage, virtual COM port, WinUSB device, and Microchip generic driver

device.

Other C compiler options are the CCS C compiler from CCS, Inc. and the

HI-TECH C compiler from HI-TECH Software.

For Basic programmers, microEngineering Labs, Inc. offers the PICBASIC

PRO compiler. The compiler’s built-in USB support enables developing devices

without having to know much about USB protocols. The supported USB capa-

bilities are limited yet sufficient for many applications. The compiler comes

with example code for a mouse, generic human interface device, virtual COM

port, and Microchip generic-driver device.

PICBASIC PRO programs can use four USB-specific instructions:

USBInit initializes the USB port.

USBService monitors the bus status and manages low-level USB communi-

cations. A PICBASIC PRO program must call USBService at least every 10

ms.

USBIn retrieves received data from a bulk or interrupt endpoint.

USBOut writes data to a bulk or interrupt endpoint for transmitting.

Assembly-code files provide behind-the-scenes support for the instructions.

The compiler automatically includes the files when needed. Adding new USB

capabilities to the compiler requires editing the assembly-language source code.

%[RTGUU'<75$

Cypress Semiconductor’s EZ-USB family includes full-speed and full/high

speed controllers. The chips support a variety of options for storing firmware,

including loading firmware from the host on each power-up or attachment.

Chip Choices

153

#TEJKVGEVWTG

The EZ-USB’s architecture is similar to the Maxim Integrated Products

DS80C320, which is an 8051 with a redesigned core for enhanced perfor-

mance. The instruction set is compatible with the 8051’s. All of the combined

code and data memory is RAM. There is no on-chip, non-volatile memory.

However, the chips support non-volatile storage in I

C serial EEPROM and in

external parallel memory.

The EZ-USB family includes the full-speed CY7C64713 in the FX1 series and

the full/high speed CY7C6801x chips in the FX2 series. Keil Software has a C

compiler with a free evaluation version.

75$%QPVTQNNGT

The EZ-USB’s many options for storing firmware make the chip very flexible

but also make the architecture more complicated compared to other USB con-

trollers.

When an EZ-USB wants to use firmware stored in the host, the device enumer-

ates twice. On boot up or device attachment, the host attempts to enumerate

the device. Every EZ-USB contains a core that knows how to respond to enu-

meration requests and can communicate when the device attaches to the bus.

The EZ-USB core is independent from the 8051 core that normally controls

the chip after enumeration. The EZ-USB core communicates with the host

while holding the 8051 core in the reset state.

The EZ-USB core also responds to vendor-specific requests that enable the chip

to receive, store, and run firmware received from the host. For basic testing, the

core circuits enable the device to transfer data using all four transfer types with-

out any firmware programming.

A ReNum register bit determines whether the EZ-USB or the 8051 core

responds to requests at endpoint zero. On power-up, ReNum is zero and the

EZ-USB core controls endpoint zero. When ReNum = 1, the 8051 core con-

trols endpoint zero.

The source of an EZ-USB’s firmware depends on two things: the contents of

the initial bytes in an external EEPROM and the state of the chip’s EA input.

On power-up and before enumeration, the EZ-USB core attempts to read bytes

from a serial EEPROM on the chip’s I

C interface. The result, along with the

state of the chip’s EA input, tell the core what to do next: use the default mode,

load firmware from the host, load firmware from EEPROM, or boot from code

Chapter 6

154

memory on the external parallel data bus (Table 6-2). The values in the first

EEPROM locations vary depending on whether the chip is an FX1 or FX2.

The description below uses the values for the FX2.

Default Mode. The default mode is the most basic mode of operation and

doesn’t use the serial EEPROM or other external memory. The EZ-USB core

uses this mode if EA is logic low and either the core detects no EEPROM or the

first byte read from EEPROM is not C0h or C2h.

When the host enumerates the device, the EZ-USB core responds to requests.

During this time, the 8051 core is in the reset state. This reset state is controlled

by a register bit in the chip. The host can request to write to this bit to place the

chip in and out of reset. This reset affects the 8051 core only and is unrelated to

USB’s Reset signaling.

The descriptors retrieved by the host identify the device as a Default USB

Device. The host matches the retrieved Vendor ID and Product ID with values

in a Cypress-provided INF file that instructs the host to load the Cypress

CyUSB driver to communicate with the chip. The ReNum bit remains at zero.

This default mode is intended for use in debugging. You can use this mode to

get the USB interface up and transferring data. In addition to supporting trans-

fers over endpoint zero, the Default USB Device can use the other three transfer

types on other endpoints. All of these transfers are possible without writing any

firmware or device drivers.

Load Firmware from the Host. The core can also read identifying bytes from

the EEPROM on power up and provide this information to the host during

enumeration. If the first value read from the EEPROM is C0h, the core reads

EEPROM bytes containing the chip’s Vendor ID, Product ID, and release

number. On device attachment or system boot up, the host uses these bytes to

find a matching INF file that identifies a driver for the device. The driver con-

tains firmware to download to the device before re-enumerating. Cypress pro-

vides instructions for building a driver with this ability.

The driver uses the vendor-specific Firmware Load request to download the

firmware to the device. The firmware contains a new set of descriptors and the

code the device will run. For example, a HID-class device will have report

descriptors and code for transferring HID report data.

On completing the download, the driver causes the chip to exit the reset state

and run the firmware. By writing to a register that controls the chip’s DIS-

CON# pin, the firmware causes the device to electrically emulate removal from,

then reattachment to the bus. The pin controls one end of a resistor whose

Chip Choices

155

other end connects to D+. When pulled up, the pin indicates device attach-

ment, and when floating, the pin indicates device removal. The firmware also

sets ReNum = 1 to cause the 8051 core, instead of the EZ-USB core, to respond

to requests at endpoint zero.

On detecting the emulated re-attachment, the host enumerates the device

again, this time retrieving the newly stored descriptors and using the informa-

tion in them to select a device driver to load.

An advantage to storing firmware on the host is easy updates. To update the

firmware, you store the new version on the host and the driver sends the firm-

ware to the device on the next power up or attachment. There’s no need to

replace the chip or use special programming hardware or software. The down

side is a more complicated device driver, the need to have the firmware available

on the host, and longer enumeration time.

Load Firmware from EEPROM. A third mode of operation provides a way for

the chip to store its firmware in an external serial EEPROM. If the first byte

read from the EEPROM is C2h, the core loads the EEPROM’s entire contents

into RAM on power-up. The EEPROM must contain the Vendor ID, Product

ID, and release number as well as all descriptors required for enumeration and

whatever other firmware and data the device requires. On exiting the reset state,

the device has everything it needs for USB communications. The core sets the

ReNum bit to 1 on completing the loading of the code. When enumerating the

device, the host reads the stored descriptors and loads the appropriate driver.

There is no re-enumeration.

Table 6-2: An EZ-USB can run firmware from four sources.

(KTOYCTG5QWTEG 5VCVGQH'#RKP (KTUV$[VGKP5GTKCN''241/JGZ

(: (:

Load from host on

re-enumerating

Don’t care B4 C0

Load from serial EEPROM Don’t care B6 C2

Default USB Device logic low No EEPROM

present OR

not B4 or B6

No EEPROM

present OR

not C0 or C2

External parallel memory logic high No EEPROM

present OR

not B4 or B6

No EEPROM

present OR

not C0 or C2