USB – class drivers

I have frequently written about various aspects of USB and presented many seminar and conference sessions on the topic. I find it interesting that, considering that USB is such a straightforward technology for most users to utilize, its deployment in devices can be quite challenging.

A particular area of confusion is USB Class Drivers. The word “class” is very overloaded in the software world – it has numerous meanings. And the term “driver” is far from precise. So, it is unsurprising that the subject provokes discussion …

In the world of USB we talk about “hosts”, which sit at one end of the bus and are in control – a PC is a typical host. We also talk about “functions”, which are peripheral devices at the other end of the bus; mice, keyboards, storage devices, scanners and printers are all common examples of USB functions.

Both the USB host and function need USB support software – a USB stack. On a Windows PC, the (host) USB stack is provided by Microsoft as part of the operating system. For a function, the USB stack is part of the embedded software that controls the device and would be typically supplied by a vendor of embedded software IP, such as Mentor Graphics. Incidentally, although a peripheral typically needs a USB function stack, an embedded device might be required to function as a host, in which case a USB host stack is required (as well as a function stack, perhaps). Again, this is likely to be available from a company like Mentor.

Part of a USB stack (on both ends of the bus) characterizes what kind of device is being interfaced – this is the USB Class Driver. A number of standard class drivers have been defined and may be expected to be available with any USB stack. These include: audio, communications, human interface, mass storage, still image and video. Some others are more specialized and less widely implemented, such as personal healthcare and device firmware upgrade.

If you are designing a device with a USB interface, it needs to be associated with a class driver on both ends of the bus. Although you can create a custom class driver for the function stack, it is generally much less work to make your device look as much like a standard as possible and, hence, make use of a supplied class driver. A strong incentive to follow this path is the requirement for a matching class driver at the host end. If you create a custom class driver for the function, you might need to also need to do more work for the host, which could include Windows, macOS, Linux etc.

I have an example of a USB device where the designers clearly took this approach: a wireless remote control device for PowerPoint on my laptop. I can hold this tiny device in my hand and advance slides during a presentation without having to approach my computer. It transmits signals to a tiny receiver which is plugged into a USB port. When this is connected to the PC, it “pretends” to be a keyboard, so the standard human interface class driver in the Windows USB stack is used. The device only generates three possible keystrokes: right-arrow, left-arrow and ESC. This is a good example of how to economically deploy USB and result in a device which is simplicity itself for the user.

This entry was posted on Monday, October 17th, 2016 at 5:11 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.