Embedded Software Colin Walls
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More » USB – class driversOctober 17th, 2016 by Colin Walls
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. One Response to “USB – class drivers” |
[…] USB – Class Drivers […]