HID doesn't require a special driver?

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
westfw wrote:
The usual alternative is to have your device register as a HID device (mouse/keyboard) and have the host software send/receive configuration request/reports...

I'd usually encountered HID in the phrase "custom HID" and
inferred that using HID always required custom drivers.
If HID does not require custom drivers,
would a kind someone point me to TFM on how to handle HID on the host side?

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michael,

It kind of depends what form of HID the device is producing. HID=Human Interface Device. The definite two and possible 3 USB HID devices already attached to your PC as the keyboard, the mouse and maybe a joystick. So if you produce a HID device that says "I'm a keyboard" and later "here comes some keycodes" then any "normal" PC software running on your PC won't actually know if the key presses it's seeing are coming from your normal keyboard or from the USB device you have designed. So software that just uses stdio/getchar/gets/scanf/etc. needs no special programming to interface with your HID device. It just does standard keyboard input and sees what your device is saying. Of course there is the isue of "keyboard focus". If the focus switches away from the program you meant to receive the keys to a word processor (say) then the HID device will just start "typing" its output into your word processor document.

Another form of HID device you might make is one that says it is a HID mouse. In that case what it pumps out are x,y positions. Again if you write a GUI program and it has the focus then the OS will just pass the "mouse events" it is seeing from your device into that program that can then interpret the data as mouse movements (if that's really what was intended) or it might interpret the data stream in some other way.

If your USB device says it is a HID joystick then "normal" PC software is not going to see the data it produces. It has to specically interact wit hthe OS to get "joystick events" then it will see the data your device is producing. Once again the data stream might have nothing to do with joystick movement at all. Say you were sending AADC 0..255 readings these could be passed as the joystick X co-ordinate but in reality both ends know they are really some other form of ADC reading. Of course if you ran a PC game that also used joystick input it might start reading this data as game movements instead.

I guess that most people who use HID without "special" software at the PC end program the device to be a keyboard in fact.

Interestingly on my PC I have a security key I use to connect to my corporate VPN. I start OpenVPN then when it asks for the password I touch a switch on the USB device and it feeds a security key into the keyboard buffer of the OpenVPN app that has the current keyboard context.

For other examples of what people do with USB-HID see:

http://www.obdev.at/products/vus...

Those are all V-USB based projects but they show the range of things that are possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.
I'd had hopes the situation was better than that.
For me, the joystick is the only one without the potential conflicts mentions.
While waiting for a response, I found additional reason for optimism: http://www.pjrc.com/teensy/rawhid.html
Of course, on Linux, CDC-based virtual serial ports are fairly easy,
though it's not always easy to figure out which one one wants.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may also want to take a look at an avrdude source tree. Several of the devices it interacts with are USB and I believe some may be using HID as a simple data channel.

Personally I've always thought of CDC or MSD as the "easy" option as it's not only easy in most OS to open a COM port or a disk/directory/file but in testing you can even do so with no "special" software. Just use a terminal to test the interface to a CDC or even just explorer/nautilus/dolphin or some other "file explorer" to interact with something offering MSD.