Subject:
Re: Traffic lights as extreme feedback device controlled by a PIC
via USB
From:
Peter Stuge ####@####.####
Date:
5 Aug 2012 13:55:36 -0000
Message-Id: <20120805135532.13902.qmail@stuge.se>
Hi Holger,
Full disclosure: I'm the current libusb maintainer.
Holger Oehm wrote:
> an USB HID firmware implementation that needs only gpasm
A gpasm USB firmware is really really awesome! Thank you for publishing!
Get your product id here: http://wiki.openmoko.org/wiki/USB_Product_IDs
I have reservations against using the HID bDeviceClass however.
The device is not a Human Input Device, so it is a poor fit to use
all the operating system code for handling input devices. I know
how easy it is to be lured into the HID mess because of Windows, but
if anything other than Windows matters in a project then there are
significantly better alternatives.
The HID class is not very portable and not very convenient, neither
for host software nor firmware. It is optimizing specifically for
Windows and if the kernel input subsystem is not intended to be used
with the device then HID seems like crossing the bridge to get water.
See also
http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass
> controlled by a java application on the host side
> (and the host software works on Linux and Windows).
Note that it is since Mac OS X 10.6 (or is it 10.7?) no longer
possible to communicate with HID class devices using libusb. On
previous versions it works, after writing a special codeless kext and
rebooting the system.
For cases where a given HID class device is unchangeable I strongly
recommend using the C library HIDAPI, which uses native HID APIs.
(Windows, Linux, Mac OS X, and BSD)
But when you can influence the firmware then I very strongly
recommend to skip the HID class and instead use the vendor specific
bDeviceClass, 0xff.
This allows completely effortless programming from userspace, with or
without libusb, on Linux, Mac OS X, and BSD. No drivers involved.
> There is no need to install any drivers or similar on the host side.
This is true also with a vendor specific bDeviceClass, on all
systems, including Windows, starting with Windows 8.
Windows XP (sp3 IIRC) and later sends a request for string descriptor
number 0xee the first time that a device is attached.
Microsoft has created this extension to standard USB descriptors
called MOD, Microsoft Operating system Descriptor. The string
descriptor contains structured information which together with one
type=vendor destination=device control request will tell Windows
which driver should be used for the device. Microsoft calls a
device which implements the descriptor and the control request per
their extension a "WinUSB Device" [1] and for such devices Windows
loads and binds the driver automatically, without any user
interaction. Plug and play for USB finally also on Windows.
The requirement for this to work is that the driver that the device
says should be used has been set up correctly in the Windows registry
- note driver, not device. The setup is needed only one time per
driver, regardless of how many different devices use that driver.
Windows 8 ships with Microsoft's WinUSB driver (for userspace USB
communication) set up correctly for this out of the box. This means
that if your device has the correct 0xee string descriptor and the
correct control request, according to the Microsoft USB extension,
meaning that it is a WinUSB device, then WinUSB is loaded and bound
to your device immediately and transparent to the user when the
device is plugged in to a Windows 8 system.
Previous Windows versions (since XP sp3 IIRC) can be set up to have
the same user experience as Windows 8 comes with out of the box. In
the libusb community we have some little hope that Microsoft will
sometime roll out this WinUSB driver setup as part of a Windows
Update also for the older systems. That would be very nice. Meanwhile
it is easy to do manually or in an application, thanks to the libwdi [2]
project.
libusb-1.0 works on Windows since some time, with all devices that
use the WinUSB driver. (Please don't confuse libusb-1.0 with the
separate libusb-win32, libusbK, and libusbx projects. libusb-1.0
is the continuation of the original libusb-0.1 project, and is
actively developed.) libusb does not care *how* the WinUSB driver
was bound to a device, the Microsoft OS descriptor and control
request is not required for libusb to work, only for the WinUSB
driver to be loaded automatically.
The libusb-1.0 API is (like the libusb-0.1 API) intended for USB
level communication with devices which have no driver in the kernel,
meaning that the API offers primitives such as
libusb_control_transfer(), libusb_interrupt_transfer(), and so on,
which all device classes build on, and which are very easy to use.
It's a lot simpler than dealing with the HID class encapsulation and
restrictions for what can be done over USB.
One of the authors of WinUSB support in libusb-1.0 is also the author
of the libwdi project. He invented and uses the term "WCID device"
instead of using Microsoft's term "WinUSB Device". (He doesn't want
to work with me and libusb anymore, and strongly promotes his fork
libusbx.) I prefer Microsoft's terminology "WinUSB Device" since it
is after all their extension. Anyway, on the libwdi wiki [3] there is
more detail about how WinUSB Devices work, and links to Microsoft's
authoritative documentation.
IMO, bDeviceClass=0xff plus WinUSB Device Microsoft extension is an
excellent alternative to using HID class, because the device becomes
truly portable, and developing both host software and device firmware
allows working directly with the USB layer instead of caring about
limits introduced by the HID class.
Kind regards
//Peter
[1] http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799(v=vs.85).aspx
[2] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Main_Page
[3] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=WCID_devices
