[libhid-discuss] HID vs. vendor specific class

John Parsons jfparsons at fastmail.fm
Thu Jul 22 02:51:05 UTC 2010


I've been reading the recent discussion here re HID vs. vendor specific
classes with great interest.  Like Rene, I am primarily a hardware
designer.  I plan to add USB connectivity to an existing product.  BTW,
I am also the firmware developer, chief marketer and bean counter!

The product is a proximity sensor, and is built around a Microchip
PIC18F14K50, their low cost 20-pin device with USB connection.  Though
this device is not exactly human interactive, I initially planned to
release this as a HID because it only transfers a few bytes of data, HID
routines are included in Microchip's example code libraries, all OS's
come with HID drivers, and it seems very simple to implement, at least
on Windows.

Statements such as the following seemed to validate my reasoning:
"If you have the time and funds you can implement using “vendor
defined” interfaces which are included within the USB specification as
an option.  But while you are moving along this difficult and
time-consuming path don’t be surprised if your competitor introduces a
similar product using a collection of standard drivers and captures most
of the available customer base.  I am a STRONG advocate of OS-supplied
and vendor-supplied drivers and always recommend that everyone use this
route.  I maintain that you need an extremely compelling reason to
embark on writing your own device driver; most people don’t."
-- John Hyde, _Embedded USB Design by Example_ p. 13.

But I want Mac and Linux app writers to be able to use this product with
the same ease as Windows app writers.  Peter Stuge makes a strong case
for vendor-specific class devices.  I am willing to go that route, but
could use some help getting started.  Pointers to resources would be
appreciated... something like "USB vendor specific classes for dummies!"

Thanks in advance,
John
-- 


-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again




More information about the libhid-discuss mailing list