[libhid-discuss] HID vs. vendor specific class

[John Parsons]

Thank you Peter and Xiaofan for your replies.  I'm encouraged to wade
into the vendor-specific class jungle!

[Now that I'm getting off the HID topic, would you prefer that I
continue this discussion in some other venue?]

> With vendor specific, libusb-1.0 and WinUSB, it's still very easy to
> access the device on Windows. libwdi can even be used to transparently
> and automatically bind the WinUSB.sys driver to the device.
> ...
> One of the points I try to make about vendor specific is that it
> actually means *less* requirements than a standard device class.
> There's no kernel driver that will hog the device and there are no
> restrictions on how to write descriptors or how to transfer data.

Good.  I'm into easy.  I don't mind digging into USB details, but given
that we're a Ma & Pa shop, and Ma and I both have day jobs, I need to
spend my time carefully.

I've had a look at http://sourceforge.net/projects/libusb-win32 (thank
you, Xiaofan) and am ready to give it a try.  I've never written a
windows app, so we'll see how it goes.

> I'm happy to help with suggestions about what endpoints to choose, as
> are several others. Please describe the major characteristics of the
> data flow between PC and your device?

Thanks.  This device is a dual proximity sensor, it senses the presence
or absence of objects at two locations.

It reports to the host the presence/absence status of the two sensors,
plus some timing and device configuration data.  All this fits in 6
bytes.  Currently communication is done via the interrupt end point.

The device also accepts 8 configuration commands from the host.  One of
the commands is to return the above status info, which currently (HID)
is done by returning a 64-byte packet.

Thanks again,
John 
-- 


-- 
http://www.fastmail.fm - The way an email service should be