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 /KETQEJKR2+%( 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 $WU5RGGF 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 2 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 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 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; 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 2 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 2 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. (KTOYCTG5QWTEG 5VCVGQH'#RKP (KTUV$[VGKP5GTKCN''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 . 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. C8051F34x low/full Standard Microsystems Corporation (SMSC) USB2 005, USB2 22x full, full/high Texas Instruments TUSB3210/3410 full TUSB6250 full/high Microchip PIC18 Microchip Technology PIC18F2455/2550/ 4455/4550,. 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