May
2004, Issue 166
USB
in Embedded Design (Part 2):
HIDmaker
Converts an Application
by
Jeff Bachiochi
Jeff
makes converting to USB an attractive option with
HIDmaker, a highly efficient program that does all
the work for you. Creating USB software has never
been easier.
Start
•
Software
Changes
• Human
Interface Device
• HIDmaker
Device Output
•
HIDmaker
Host Output
•
Time
To Convert
•
Sources
and PDF
Many
of you will say they were too young, that they were
struck down in the prime of their lives. What a shame,
you’ll say. They hadn’t even reached the age of 50.
Are
serial and parallel ports dead? I believe that nothing
can really die unless it’s forgotten. All of us have
family and friends who have passed on, but we keep them
alive by sporting their pictures on our walls, visiting
gravesites, talking about them, and memorializing them
in various public and private ways.
I
remember the rumblings that TV would kill radio. (I
can’t imagine riding in my car without tunes.) But today’s
technology continues to assure radio’s success via satellite.
Although my kid’s kids probably won’t even know what
serial and parallel ports are, that’s at least a decade
away. Although it’s getting tougher to foresee what
the future holds, I doubt that they will totally disappear
anytime soon. It’s more likely that they will become
obsolete because of nonsupport in much the same way
DOS has been neglected (although still used by some).
“If
it ain’t broke, don’t fix it.” I’m a big believer in
that statement. But I also understand that much of the
world economy’s growth is based on the development of
new technology and the harnessing of its potential.
If we stand still, we run the risk of falling behind.
Do you want to run that risk?
BECOME
A USB CONVERT
If
you aren’t convinced that you need USB after last month’s
column, you’re standing still. Last time, I briefly
discussed the reasons for the development of USB and
how you can benefit from its implementation. You observed
the physical attributes of the USB connection and how
a USB device makes itself known to the host through
enumeration. Furthermore, I explained how tiered interconnections
allow the host to communicate with each USB device on
a one-to-one basis using data packets stuffed into 1-ms
frames. I also introduced a previously designed X10
project.
X10
uses the AC power lines in your home to transmit control
codes to specially designed outlets that respond to
the codes. X10 codes can turn on and off appliance modules
(relay-based). They also turn on and off—as well as
dim and brighten—lamp modules (triac-based). These modules
can be purchased in an AC outlet form factor or as plug-in
modules.
The
project consists of a serially connected dongle, which
translates serial X10 commands into the appropriate
control signals to drive a TW523 isolated power line
interface. A PC application feeds user-selected X10
commands, as TX serial data, to the dongle while monitoring
the RX serial input for X10 commands received from the
power line.
Any
X10 command can be sent by transferring 3 bytes (HouseCode,
UnitFunctionCode, and RepeatCode) to the dongle over
the serial interface. An X10 command seen by the TW523
on the power line is returned to the application by
the dongle transferring 2 bytes (HouseCode and UnitFunctionCode)
back via the serial interface.
To
replace the serial interface with a USB equivalent requires
hardware and software design changes. These changes,
which are not minor, may require choosing a new processor
for your design.
HARDWARE
CHANGES
The
most visually dramatic changes to a project are physical
ones. The area needed for a USB interface is considerably
less than that of serial and parallel ports. Besides
the connector size shrinking to about 25% of a DB25,
only a few discrete parts are needed instead of level
shifters or buffers. You can free up a few square inches
of real estate on your PCB. Furthermore, you can really
luck out if the manufacturer of your microcontroller
makes a version with a USB peripheral. More and more
manufacturers are jumping on this bandwagon. If not,
you may be able to add a USB interface chip (e.g., the
Philips ISP110x) to your micro, assuming it has the
horsepower and buffers to support all of the necessary
USB functions. The great part about using a micro integrated
with USB is that all the low-level stuff is done for
you.
USB
hardware handles detecting and decoding incoming packets.
It determines which transactions to ignore (no matching
address) and which to react to, flagging the type for
endpoint 0. Incoming data is stored in the appropriate
buffer or flagged as an error. The number of bytes received
and the data-toggle state is stored. The hardware calculates
and compares CRC values, and takes the appropriate action
on errors. It automatically sends any necessary handshaking
to the host and triggers an interrupt for the firmware
to take action. Outgoing data is encoded for transmission
along with the byte count and data-toggle code.
The
hardware also calculates a CRC and appends it to the
data packet. After receiving a handshake from the host,
it triggers an interrupt for the firmware to take action.
I’m sure you’ll concede that this functioning is something
to be avoided if possible. You can sidestep this entirely
by designing with a microcontroller that has USB support.
