Xiaofan Chen wrote:
> You might want to consider move to either Microsoft's
> WinUSB (but it does not support Windows 2k) or the
> open source libusb-win32.

I always thought that was a Linux thing until yesterday when Martin told me
there was something like that available for Windows.  Is there some overvie=
w
description of what libusb is on the order of one or two page level of
detail?

I've thought for a long time it would be really useful if someone
(Microsoft?) created a generic USB driver that surfaces all the raw USB
capabilities of a device to the app level and otherwise gets out of the way
after enumeration.  The app could enquire which endpoints the device
supports, what their characteristics are, and open separate connections to
each.

Our standard driver is a stripped down version of that since our devices
currently only use endpoints 1 in and out configured for bulk transfers to
set up a bi-direction stream of bytes.  I like controlling custom devices
with a bi-directional byte stream because there are various ways to
implement that which can be largely transparent to upper layer software.
Examples are a serial port, a TCP connection, and a in/out pair of USB
endpoints.

One thing our driver does that would likely be missing from a generic drive=
r
is to gather a list of all compatible devices.  We use pipe 0 for private
communication between the device and the driver.  This currently only used
at startup, but I would like to add more.  The driver gets the name string
of each device this way and keeps it in a table.  A separate control
connection to the driver allows any app to enumerate the connected devices,
even if they are in use by other apps.  This is how our PICPRG_LIST program
works, for example.

Eventually I would like to add notification via the private driver channel
of a app opening and closing the byte stream connection.  Unfortunately
there is nothing like app layer open/close notification built into USB.  Yo=
u
get data or you don't get data, but you don't know that one app finished an=
d
the next packet is coming from a different app.  Having such notification
would allow for firmware cleanup and state resetting that is currently not
done, but probably should be.

It would be really nice if a generic driver could support this model, but I
don't know how to generalize it without imposing policy on a device.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.