USB Complete fourth- P18 docx

For each enabled endpoint address, the firmware must reserve memory for a buffer and a buffer descriptor.. When readying an endpoint to perform a transfer, the last operation the firmwar

(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

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).

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.

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

Table 6-1: USB controller chips that are compatible with popular microcontroller architectures are available from many sources.

NXP Semiconductors LPC292x, LPC214x full

AVR32UC3

low/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

Microchip PIC18 Microchip Technology PIC18F2455/2550/

4455/4550, PIC18(L)F1xK50

low/full

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 I2C 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 register contain the number of bytes sent or ready to send in an IN transaction

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 endend-point, an OUT endend-point, 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)

// A buffer descriptor table holds 4 bytes.

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

typedef union BDT

{

{

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

};

{

unsigned :8;

unsigned :8;

BYTE* ADR; // Address pointer

};

} BDT_ENTRY;

Listing 6-1: Firmware can use structures to represent the contents of an endpoint’s buffer descriptor table (Part 1 of 2)

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

typedef union _BD_STAT

{

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

};

{

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)

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 speclass-spe-cific 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

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 I2C 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 I2C 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

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

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.

(KTOYCTG5QWTEG

Load from host on

re-enumerating

present OR not B4 or B6

No EEPROM present OR not C0 or C2

present OR not B4 or B6

No EEPROM present OR not C0 or C2