Do you speak USB? If so, then you’re using one
or more of the USB classes shown in the table. The
most popular classes tend to be the human interface
device (HID) and the mass storage device, since these
kinds of products are ubiquitous around PCs and
mobile devices like digital cameras. Details can be
found at the USB Implementers Forum.
The class approach works well by allowing device
driver and application developers to utilize any
third-party device with an impressive amount of
interchangeability. For example, almost any USB
flash drive will work in most PCs, cameras, and printers
with a USB socket. Incompatibilities tend to be
with older USB 1.0 devices.
There is a base protocol for USB, and the class
communication is built on top of it. For example, the
USB flash drives use the mass storage class. Each
class has its own application programming interface
(API) associated with it. Also, a USB device can
host more than one endpoint where each endpoint is
defined by a USB class. This allows a product like a
force feedback gaming joystick to look like a simple
joystick as well as provide a backchannel to handle
vibrations and force feedback.
USB devices have long been used for data acquisition.
However, many of the
products are provided by a single
vendor that also supplies matching
software, often only for PCbased
Windows platforms. There
are often special device drivers
that must be used.
This setup is usually fine for
many test and measurement
applications, though embedded
platforms run a host of operating
systems (OSs). Likewise,
the overhead that’s required for
many of these data acquisition
tools is large and doesn’t suit
smaller targets.
Embedded USB devices inside
the box have typically been conventional
USB devices such as
flash memory storage or serial
ports that can be dealt with using
standard USB class protocols.
The problem arises as the USBbased
data acquisition and control
devices start moving inside
the box where non-x86 hosts are
common.
LOOKING FOR EMBEDDED USB STANDARDS
Several recent changes are pushing the need
for embedded USB devices that aren’t covered by
the standard classes. These include the stackable
approaches to USB from the Small Form Factor SIG
and the Stackable USB organizations.
Additionally, there is more use of cabled USB
within the box with products like Acces IO’s USBDIO-
96 (see “USB Module Provides 96 Or 48 Digital
I/Os”) that follow the PC/104 form factor.
Many of these changes will follow the same approach
as those used outside the box where Windows drivers
are provided. This is fine for x86 platforms that run an
OS like Windows Standard (XP) Embedded, but other
options must be provided to handle platforms ranging
from QNX to Linux to uC/OS.
This could be a nightmare if the handling of each
device is unique, which is the case for most vendorspecific
solutions. It is already an issue when dealing
with different vendors even when using a Windowsbased
host.
One approach is to define a new class or subclass
that would address the needs of embedded community.
There are plenty of devices that need to be supported,
from parallel I/O to analog-to-digital converters
(ADCs) and digital-to-analog converters (DACs).
Another approach is to build definitions and a protocol
on top of an existing class. Either way, developers
should be presented with something like an
XML definition of the interface, not a vendor-specific
header file and runtime library.
USB and USB microcontrollers offer significant
benefits over alternatives such as serial interfaces
ranging from hot-plug support to a more intelligent
device. Providing a list of capabilities at runtime is a
trivial exercise.
As a result, having a single API to handle all ADCs,
for instance, should be possible. Likewise, replacing a
device with a similar unit should be as easy as swapping
one keyboard for another.
Now if we could just figure out what organization
should handle this, it might actually get done. Are
there any takers?
ACCES IO
www.accesio.com
SMALL FORM FACTOR SIG
www.sff-sig.org
STACKABLE USB
www.stackableusb.org
USB IMPLEMENTERS FORUM
www.usb.org