Access to HID devices on USB

543 views
Skip to first unread message

Tom Unsicker

unread,
Aug 15, 2003, 3:48:39 PM8/15/03
to
I am creating a USB device that will be HID compliant. I
have tested the device communication on a PC and verified
the USB data with a protocol analyzer.

How do I connect to the device in CE 4.1? I will need to
receive the the IN packets and send OUT packets.

-Tom

Jeff Rosenfeld

unread,
Aug 15, 2003, 4:00:09 PM8/15/03
to
Huh? Your HID device never sends IN or OUT packets, only DATA, ACK, NAK, and
STALL packets.

In any case, you connect a device in exactly the same way you do on a PC;
plug it into one of the USB ports. Most (all?) CE devices with USB host
functionality ship with a HID driver.

A HID-compliant device must also be USB-compliant. The data getting
transferred correctly is a necessary but insufficient test. Setup and
response times, for example, must be within spec.

- Jeff.

"Tom Unsicker" <tuns...@coinco.com> wrote in message
news:01cb01c36366$397d1aa0$a501...@phx.gbl...

Tom Unsicker

unread,
Aug 15, 2003, 4:34:04 PM8/15/03
to
Let me clarify my original post. By IN or OUT packets, I
was refering to the data portion of the IN and OUT
transactions, not the IN/OUT tokens. Our application is a
gateway between USB and a proprietary bus used in the
vending industry. The CE device will be the host, it will
issue an OUT transaction to our device which will then
convert and transmit the data. When the response is
received, it will be returned to the host during the next
IN transaction.

With a PC, I can obtain the device path through the normal
SetupDi function calls. To my knowledge, these function
calls are not available on a CE platform. I am looking
for guidance on the following questions.

1. What is the best way to parse through the active device
list to find my HID device?
2. Once I find the device, how do I setup the system to
send and receive data?

Regards
-Tom

Steve Schrock [MS]

unread,
Aug 15, 2003, 8:00:45 PM8/15/03
to
For 4.1, you will need to either modify the sample USB HID driver so that it
supports your device, or write a complete USB client driver that is keyed on
your device and product ID. There is no good way in 4.1 to do this in an
easier way through APIs.

--
Steve Schrock
Windows CE Device Drivers

This posting is provided "AS IS" with no warranties, and confers no rights.

"Tom Unsicker" <tuns...@coinco.com> wrote in message

news:01fe01c3636c$9140d9b0$a601...@phx.gbl...

Tom

unread,
Aug 16, 2003, 9:07:34 AM8/16/03
to
One of the supposed benefits of creating HID compliant
devices (at least on the PC) is the ability to just write
application software and let the default HID driver do the
rest. From Steve's post, I gather that this does not yet
apply to CE. In order to just receive data from our
device, we will need to write a new HID driver or write a
HID class driver.

If our device is the only device connected to USB, is there
any way an application can receive the data sent by the
device using only the default HID driver?


>-----Original Message-----
>For 4.1, you will need to either modify the sample USB HID
driver so that it
>supports your device, or write a complete USB client
driver that is keyed on
>your device and product ID. There is no good way in 4.1 to
do this in an
>easier way through APIs.
>
>--
>Steve Schrock
>Windows CE Device Drivers
>
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>

>"Tom Unsicker" <tuns...@coinco.com> wrote in message

>news:01fe01c3636c$9140d9b0$a601...@phx.gbl...

>.
>

Steve Schrock [MS]

unread,
Aug 18, 2003, 12:14:04 PM8/18/03
to
If you want an application to be able to comminicate with a HID device, you
will need to modify the USB HID driver or write a new one. If your device
will only use this one HID device, then the changes you would need to make
to the USB HID driver will probably be simpler.

This task would be much easier in 4.2, since the HID drivers are already
abstracted from the USB driver.

--
Steve Schrock
Windows CE Device Drivers

This posting is provided "AS IS" with no warranties, and confers no rights.

"Tom" <tuns...@coinco.com> wrote in message
news:096101c363f7$5b876e20$a301...@phx.gbl...

Tom Unsicker

unread,
Aug 18, 2003, 12:29:06 PM8/18/03
to
Thanks for your help; I have a few additional questions?

I would still need to modify the existing driver or create
a class driver in 4.2, correct?

What is a good example to look at for creating a class
driver, if necessary?

Is platform builder still recommended, or would it be
enough removed that other tools such as eVC++ may be used?

Best regards,
Tom Unsicker

Steve Schrock [MS]

unread,
Aug 19, 2003, 11:59:38 PM8/19/03
to
In 4.2, there is another level added to the stack. It goes usbd -> usbhid ->
kbdhid. So you would be required to write a HID client driver instead of a
USB client driver. Writing a HID client driver is much easier. Also, the 4.2
USB HID driver is structured in such a way that it would not be very
difficult to add a desktop-like device access interface to it, if you wish
to go that route.

You could use the USB HID driver as an example, of course, but it can be
confusing. The USB printer class driver is much simpler, and in fact, that
is what I used as a template when I re-wrote the USB HID driver for 4.2.

You should be using Platform Builder to debug device drivers.

--
Steve Schrock
Windows CE Device Drivers

This posting is provided "AS IS" with no warranties, and confers no rights.

"Tom Unsicker" <tuns...@coinco.com> wrote in message
news:0af801c365a5$d80325c0$a501...@phx.gbl...

Jeff Rosenfeld

unread,
Aug 21, 2003, 12:53:06 PM8/21/03
to
Your device is a bridge onto a proprietary bus (by your own statement). That
doesn't really fit the notion of a HID-class device in any case, but I'll
ignore that for now. CE doesn't use HID usage codes internally except within
the actual USBHID driver. Because the number of HID usages exceeds - by
far - the number of VK codes, the only way to get general HID responses up
to an application is with DirectInput. Older versions of CE shipped with a
stripped-down version of DirectInput but even that only supported devices
that were similar to keyboards, mice, or joysticks (which yours probably
isn't). In other words, the OS provides no way to move HID reports between
applications and the device driver.

The benefit for building compliant devices is that they *can* work in a
sufficiently powerful and flexible environment, not that they *will* work
with zero additional effort.

You might not need to write a whole new driver and you certainly don't need
to write a new HID-class driver. Just make your driver load for only the
VID/PID of your device and let USBHID keep getting loaded for other HID
devices.

- Jeff.

"Tom" <tuns...@coinco.com> wrote in message
news:096101c363f7$5b876e20$a301...@phx.gbl...

Reply all
Reply to author
Forward
0 new messages