Академический Документы
Профессиональный Документы
Культура Документы
USB is now a mature technology yet many people are not using it since they perceive
it as “too complicated.” To date, all USB books and most USB technical articles
have presented USB as a “technical wonder” and the reader is flooded with details
such as packet types and descriptor parsing. Not surprisingly, many people who
could take advantage of USB are holding back. This paper treats USB as a tool that
can be used to solve real world problems in embedded systems design.
This paper works through a range of examples, starting with a single button and ending with an
embedded USB host controller. There are three distinct sections; this introduction covers
essential USB terminology but explained relative to RS232 which you already know; I then build
a range of embedded devices that attach to a USB host such as a PC, Mac, Linux, or any USB-
aware OS; I then add a mass storage device to an existing embedded product. You will discover
that all of the low-level USB issues have been already solved and you can use these building
blocks to solve your unique embedded system design challenges. These examples are
downloadable from www.USB-By-Example.com.
Lets first compare and contrast a USB solution with an RS232 solution. Figure 1 shows a PC
with four connected devices, two serial and two USB devices. A serial connection has two
signal wires and a ground while a USB connection has two signal wires, a power and a ground.
A USB connection has one extra wire but otherwise the hardware looks similar.
The operating system running on the PC (Windows, MacOS, Linux, or other OS) has built-in
support for both types of devices and the layered structure of the software on this PC is also
shown in Figure 1. I use Windows names in the figure but the layered architecture for MacOS,
Linux and others is the same, they just change the names to keep us hardware folks on our toes!
PC Applications
User
Win32api
COM1 COM2 USB1 USB2
Windows Kernel
And
Bar Code Flash Play
Device Driver Manager
Reader Drive
Port Driver
Internet
Modem
Phone
Note that I have a scanner attached to com1 and a modem attached to com2. The application
programmer needs to know this and the baud rate of each of these devices (read the manual) and
also needs to know the data exchange protocol for each device (study the manual in detail). This
is all quite straight forward and programs have been written like this for a long time.
But now look what happens if I swap the connections of com1 and com2. The scanner
application will be connected to the modem and the modem application will be connected to the
scanner. Both devices will be initialized incorrectly, the data exchange will be garbled and both
applications will fail. This is the price we pay for allowing the user to bind the application
program with the hardware connection.
Now lets look at the two USB devices. Many users want to do a
Handle = CreateFile (“USB1”,…)
but this is NOT how it works. We wanted to remove the user from the hardware binding process
and let the OS do this work. When a USB device is attached to a PC the OS enumerates the
device - it sends a series of commands to the USB device that discover what the device is. The
USB device responds with fixed-format data structures, called descriptors that identify it
completely. The OS uses this descriptor information to load the supporting device driver. It then
places this information into the OS’s PlugAndPlay tables.
Figure 2 shows the descriptors of my two devices (100% Flash Drive, 70% Internet Phone).
Now lets turn our attention back to the applications programmer who wants to open one of these
USB devices. The initial problem is that the programmer doesn’t know the name of the device to
use in the CreateFile API call. But the programmer knows the TYPE of device that they need to
connect to, so they ask the PlugAndPlay manager “do you have any MassStorageClass devices
attached.” The PnP manager responds with a list and we use some algorithm to isolate our
chosen device - in this example we would select the removable device. Similarly the audio
application would search for, and open, an AudioClass device.
So with USB devices we have an extra step to identify our device since it doesn’t have a pre-
declared name such as COM1 or LPT4. The benefit is that the user could swap the USB cables
and both applications would still work. Additionally there was no need to read the manual of
either device to discover their characteristics - these were read by the OS during the enumeration
process and are available to the applications programmer
Bottom Line: a USB device contains descriptors that the OS reads so that it can load the
correct device driver. The PlugAndPlay manager makes this information available to the
applications programmer so that it can be initialized or changed.
A USB Button
“But all I want is a simple button. This used to be easy with a parallel port and I don’t have time
to learn USB. What other options do I have?”
I get questions like this almost every week at my website and people are surprised when I
explain that you don’t have to be a USB guru to solve this kind of problem. They tell me how
they have hacked a USB mouse or keyboard to get a simple button but have then fallen into the
“system input device” trap of Windows.
I am going to solve some typical USB interfacing problems and you won’t have to buy any new
development tools over what you already have for serial and parallel port interfacing. I shall use
readily available commercial products to implement these solutions so that you should have no
problems adapting them for your particular application.
My first example is a simple push button and matching LED to show that the button has been
pressed. This button press will be recognized by a PC, and the PC can also independently light
the LED. To solve this interfacing problem I am going to use a special USB-to-Serial cable
manufactured by FTDI – note that this TTL232R cable does not use RS232 levels, it uses TTL
levels to enable it to interface directly with microcontrollers and other TTL circuitry. My
application is not what this product is specifically designed for but it is fully tested and
warranted - it is also quite cheap! This cable is shown in Figure 3.
The cable in Figure 3 looks like an innocent USB cable except for the fact that it has 6 wires
instead of the standard 4 wires. Figure 3 also shows the detail of the electronics embedded into
the USB plug - it contains an FT232 USB-to-Serial component plus the support circuitry
mounted on a tiny PCB. The 6 wires are Vbus, TX, RX, RTS, CTS and Gnd but we won’t be
using them in this mode until example 3. My first two examples configure the cable into
“BitBang” mode and this provides 4 independent IO lines that I can read and write.
Figure 4 shows the passive components attached to the end of my FTDI cable for my first
example. I will demonstrate two example programs on my Windows PC, one in Visual C++ and
the other in Visual Basic. I have the same example also available for the MacOS and for Linux.
The program first asks the OS if there are any FTDI cables attached and when it finds one it
opens it and reads/writes to it every 100 msec. Button presses are shown on the PC screen and
PC commands can independently turn on the LED.
Active
Green
Insert
Yellow
Orange
Red
Vbus or
Brown
Gnd
Black
Figure 4: USB device with up to 4 bits of IO.
Notice that you didn’t see any descriptors or had to deal with any USB-ness at all. The OS
recognized the FTDI cable and loaded the FTDI driver (FTDI supply certified drivers for all
major OS’s). I first configured the cable to support BitBang mode then used standard ReadFile
and WriteFile commands in a timer/sleep loop. Pretty easy.
VCC
Address
10K
10K
10K
Select
TXD.0 SCL
RTS.2 1K0
SDA
RXD.1 PCA9554
CTS.3 INT
330
330
330
330
330
330
330
330
GND
So, with this cable and a few standard components I can simply access 64 bits of IO - enough for
many control panels, system configuration, or even a distributed data gathering system. I have
this up and running and I didn’t have to even open the USB spec! All the USB-ness is handled
by the device, and the device driver, allowing me to concentrate on my application.
Now is a good time to discuss USB power considerations. Power can be drawn from the Vbus
line but you must understand the rules. A USB host port is required to supply up to 100mA at
5.0 Volts for any device - mice and keyboards can run off this power. If your device requires
more power you are allowed to request up to 500mA once your device is configured. A PC or a
powered hub will have no problems supplying this power but an un-powered hub (which I
recommend you do not use!) will not be able to do this and this creates user confusion. If your
device needs more than 500mA then it should contain its own power source - the USB spec calls
this a self-powered device but this is still allowed to request up to 500mA from the bus.
At the other end of the scale a device must not consume more that 0.5mA when it is suspended.
As a PC is powering down it stops sending signals on USB and devices must interpret no USB
activity for 3msec to mean “suspend yourself”. There is no point having a peripheral device
powered on if the PC is powered off. A powered down device can have the ability to send a
“WakeUp” signal to the PC to bring it back to its powered-on state.
In the center diagram of Figure 6 I have replaced the serial cable with the FTDI cable. This
cable drives TTL levels so there is no need for the RS232 voltage converters. We have a
problem with the connector however since the industry expects RS232 voltage levels on the 9
pin (or 25 pin) serial connector; I shall deal with this issue in a moment.
What impact does changing the cable have on the PC and the application software? The OS will
now enumerate a USB device instead of a COM device and will load the FTDI drivers again.
These drivers include a Virtual Comport driver - which means that a device called COMxx will
be added by the PlugAndPlay manager. So, the application program now opens, say, COM8
rather than COM1 - there are no other changes needed.
Now look at the third diagram in Figure 6 - I have moved the FT232 part from the “PC end” of
the cable to the “device end” of the cable. This FT232 part replaces the RS232 voltage converter
and I replace the serial port connector with a USB B connector (standard size or mini-B). This
means that I use a standard USB cable to connect me new device to the PC.
9-Pin D IO
PC
COM1
RS232
Buffers uC
IO
??? IO
PC
USB1
uC
IO
USB-B IO
PC
USB1
FT232 uC
IO
If needed, we could increase the baud rate to the device. Standard serial cables can easily
support 56K baud and some can do 192Kbaud. The FT232 can run at 3,000K baud due to the
higher data transfer rate of USB. If your device moves a lot of data then this “upgrade” would be
worth implementing.
A USB cable can also supply up to 500mA at 5Volts. If your device can operate at this power
level then you could eliminate the power source from your device and thus reduce its
manufacturing cost. And since you will charge more for a USB version then you get a double
cost benefit as well as a simpler product. This is also “low hanging fruit” and is easy to
implement.
RS232 Buffers
RX
TX A B
RS232 Buffers RX
FT2232
A B
FT2232
USB USB
Figure 7: An FT2232 can be used for a passive or active serial spy cable.
TLC7528
TLC272
A
USB FT2232
WR
RD
B TX
The FT2232 has direct support for I2C and SPI serial protocols. Another interesting application
of the FT2232 is as a fully programmable device as shown in Figure 9. Here the personality of
the device is downloaded from the PC into an FPGA. A complete development kit, called
Morph, is available from FTDI. During run-time the FPGA has a parallel data path into and out
of the PC. Good examples of the use of this technology are the high performance oscilloscopes,
data loggers and other USB instrumentation from EasySync.
The major issue is, of course, that a flash drive is a USB device and therefore, to control it, you
need a USB host controller. The USB specification deliberately put most of the communications
complexity within the host controller, since there is only ever one in a system, and this enables
USB devices to be simpler and therefore lower cost. A flash drive is a Mass Storage Class
device and, although these specifications are a free download from www.usb.org, they are not
easy to read. This is not surprising because they are specifications and not implementation
guides. Additionally, these Mass Storage Class specifications only define basic track/sector,
read/write operations so we also need to understand specifications of the FAT file system, as
used on all commercial flash drives, to be able to read and write user data. The amount of
information that we need to understand how to “just connect a flash drive” is becoming over
whelming. What we need is a component that implements all of these specifications for us; after
all, they are industry agreed specifications that we have no freedom to change anyway, we just
want to use them.
Select
Figure 10: The Vinculum provides a DOS-like command interface to a Flash Drive
The board will sign on and offer a D: > prompt. Now, in HyperTerminal, enter “DIR” and, Hey
Presto, the contents of the drive are displayed. Now enter the following commands:
OPW test1
IPA
WRF 12
Hello World!
CLF test1
These commands first opens a file called “test1” for write, then tells Vinculum that 12 bytes of
data are coming. “Hello World!” is the data that is written, and CLF closes the data file.
Now remove the flash drive and connect it to your PC, Mac or Linux system and open test1.
Notice that the data written by the Vinculum is present. Now edit test1 to add a message “Hello
from my PC, Mac or Linux”
Now reattach the flash drive to the Vinculum board and enter “RD test1”. Voila, the text is
displayed!
We have written, read and exchanged data files between a PC, Mac or Linux system and an
embedded system using a flash drive. We did not have to learn USB, the Mass Storage Class
specification or even the FAT file system. It was as easy as entering DOS-like commands on a
serial connection.
Pretty amazing.
The Vinculum powers up in Extended Command mode where all the commands and data are
ASCII; some of these commands are summarized in Figure 12. It can be switched into Short
Command mode where binary commands and data can be exchanged. The VMusic board only
provides access to the UART connection but this will be enough for my first set of examples.
The Vinculum is also available in an OEM 24 pin DIP and this additionally provides access to
the SPI port, the parallel port FIFO and the other USB port.
Figure 12: This table shows some of the monitor’s DOS-like commands.
There are two types of project suitable for a Vinculum – data distribution and data collection and
I have examples of each category. Typically, data to be distributed is created on a PC using
specialist tools and then copied onto a flash drive; an embedded system then accesses this
information and presents it to a user or a machine. My example is a small JPEG viewer and MP3
player – something that we would take on a business trip and that plays back images and sounds
of our family, or our favorite music. If I had used a larger display I would have called this an
“active photo frame” (it is on my TODO list!). My data collection example is a portable data
logger that collects field data for later analysis by a PC. In both cases an application
microcontroller is used to drive the Vinculum (it is a peripheral device) and other circuitry. I am
confident that you can dream up many more applications for this easy-to-use part.
The size of the graphical display determines the complexity and choice of the PSoC. Since this
is a paper about embedded flash drive applications I chose the simplest display to implement
here and I will cover interfacing to a larger display in a future article. I found a serial-interface,
micro-LCD at www.dontronics-shop.com and was very impressed with ease of use of these
128x128 color displays. These 1.5” x 1.5” displays are not expensive – you should get some and
experiment with them. I am sure that you will soon find many uses for them, just as I did. I
personally found the OLED displays much better to look at when compared with the LCD
displays but the firmware to drive the both displays is identical. The micro-LCD module is a
very capable subsystem that supports graphics rending and several fonts. My example uses
about 5% of its capability as I just download images to it. These images are 128x128 by 16-bit
From an application software perspective we have a PSoC interfacing two serial connections,
the Vinculum and a micro-LCD connection. The application starts by looking for 001.img and
copies it to the display. If it finds 001.MP3 then it will play it, else it will wait for 60 seconds
(easy to modify) before moving onto 002.img. The application keeps incrementing through
filenames until one is not found then it starts at 001.img again. To change the photos and/or
music you just swap the flash drive. The complete PSoC project is downloadable from my
website and, as you will see, it supports the basic function. It is easy to expand this design to add
functions – I plan to add a feature-rich alarm clock once I get some spare time. It would be easy
to make this battery powered however displays tend to consume a lot of power so I would also
add a battery charger in this case. A battery charger uses a few analog and digital resources of a
PSoC, a few FETs, an inductor and R’s and C’s. This design extension is covered in detail in
Cypress’s application note collection.
The CCS compiler was specifically designed to create optimized code for the PIC family of
microcontrollers. As well as all of the standard features that you would expect from a quality C
compiler it includes built-in functions to support the on-chip features of a PIC microcontroller.
A good example is the #use RS232 directive; here you specify that you need to use a serial port
and you give the compiler details such as baud rate and the IO pins that will be used for TX and
RX. If the chosen PIC device has a hardware UART then the compiler will use this for printf
and scanf functions, else it will include subroutines to manage the low-level bit manipulations
for you. Your main program uses printf statements as before. The CCS compiler also contains
built-in functions to drive the on-chip ADC and the real time clock. This way you can focus
upon WHAT your program is doing and not the lower level HOW.
Don designed the battery powered data logger shown in Figure 11 to demonstrate the capabilities
of the Vinculum. The example program uses RS232 to control the Vinculum, which writes data
to the flash drive. Better still, the hardware connection is a standard 4-wire serial port using TX,
RX, RTS and CTS.
The PIC runs an application program that has access to a flash drive using the Vinculum, a real
time clock, a temperature and humidity sensor and two analog input channels. A connector for
FTDI’s TTL-232R-3V3 cable is included, as it a connector for a PIC debugger such as CCS’s
ICD-U40 unit.
The application program first checks to see if a flash drive is present – if one is not found then
the PIC goes back to sleep since there is no point collecting data if there is no where to store it.
Once a flash drive is found the PIC starts a data collection cycle: it first reads the real time from
the Dallas/Maxim DS1302, then the two analog signals and the battery voltage, then the
temperature and humidity. This data is then written to the flash drive and the system goes back to
sleep to save battery power. This cycle repeats while a flash drive is present and the battery is
charged. The flash drive may be removed at any time and the collected data may then be
analyzed using a PC.
The source code for the application is available with the Development Kit so that you can
customize the data collected and the time interval between samples. Don designed the board as
an evaluation tool for Vinculum designs but I can see many applications where this battery-
operated, portable data logger would be a great fit as is.
If you can read and write to a serial port then, with Vinculum, you can read and write data files
on flash drives. I would be interested to hear about projects in which you have creatively used a
Vinculum and a flash drive.
Happy developing!