Embedded USB Tower Of Babel

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.

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?