From its introduction in 1995, the Universal Serial Bus
(USB) quickly gained widespread acceptance for connecting
peripherals to personal computers. More recently, its ease of use,
expandability, high bandwidth, and low cost have suited it quite
well for data transfer in embedded consumer electronic and mobile
devices. Thus, product developers are increasingly being asked to
design and implement a wide range of USB I/O devices. This idea
describes a technique for developing such devices.
A USB system is asymmetric, consisting of a host controller with
several downstream USB ports and multiple peripheral devices
connected in a tiered-star topology (Fig. 1). The
host (usually a personal computer) must include a device driver
(xxx.sys file) to communicate with the device controller. In addition,
an application programming interface (API) is needed (xxx.
dll file) to connect the application to the device driver. Finally, the
device controller contains an embedded program that defines the
device endpoint and mode of operation. Peripheral designers must
develop those three software elements.
An alternative is to use an off-the-shelf USB bridge like the
FT245R from Future Technology Devices International (FTDI).
The bridge includes the silicon and all software elements.
An evaluation module of this bridge (UM245R) has a DIP24W
footprint and is configured for one endpoint of an 8-bit data
bus (DB) and four control bits (WR, RD, TXE, and RXF).
The user needs to connect the bridge to the peripheral
processor or to the state machine (FPGA) that responds to
the bridge protocol to implement the entire design. Then,
the developer must check the communication between the
peripheral and the software that runs on the host.
In most cases, the developer must start debugging before the
peripheral hardware is available. Because the PC parallel port in
standard parallel port (SPP) mode is a real bidirectional port, you
can use it to emulate the peripheral processor. Figure 2 illustrates
the connections between the personal computer’s parallel-port
connector and the UM245R.
The parallel port’s data register (DR\[0...7]) connects to the
module data bus (DB\[0...7]). The parallel port control register
(CR\[1...3]) connects to the reset (RST), write (WR), and read
(RD) control pins of the module, while two parallel port status
bits (SR\[4, 5]) connect to the receiving flag (RXF) and transmit
enable (TXE) control pins of the module.
We used National Instruments’ LabWindows CVI to implement
the emulator in C. The three different source files (UM245SppLib.c, UM245UsbLib.c, and
UM245Tester.c) and additional source material are available here.
UM245SppLib.c includes all of the functions that access the
module through the parallel port—that is, reading and writing a
byte, setting and clearing the control bits, and reading the status bits.
UM245UsbLib.c includes functions that encapsulate several initialization
functions from FTDI’s API library—ftd2xx.dll. The third
file, UM245Tester.c, is the emulator main module. To work with
the FTDI API library, programmers should add the ftd2xx.lib file to
their project and copy the ftd2xx.dll to the working directory.
To illustrate the emulator’s operation, we built a graphical user
interface (GUI) that includes four buses: SPP Out, SPP In, USB
Out, and USB In (Fig. 3). When setting a bit in the SPP Out buttons,
the emulator read the entire eight bits and sent them, as a byte,
to the module through the parallel port. This action emulates data
transmission by the device to the host. In response, the host software
received the byte and represented it on the USB In indicators.
When setting a bit in the USB Out buttons, the host software
read the entire eight bits and sent them, as a byte, to the module
through the USB. In response, the emulator received the byte and
represented it on the SPP In indicators. This action emulates data
transmission by the host to the device.