looking for USB HID example
ManAtWork
Posts: 2,176
As you probably know I'm working on a flight simulator. So for the cockpit dashboard I need a lot of knobs, switches, pushbuttons and encoders which all need to be connected to the PC. Everybody in the simmer community seems to handle this with Arduinos but as Propeller enthusiast I'd like to avoid that.
I think with the abundance of freely configurable IO pins and the built in USB interface the P2 is ideally suited for that and should reduce the part and board count significantly. I'm sure somebody has already built a HID device with the P2 for gaming but I haven't followed the discussions. I browsed the new OBEX but haven't found anything.
I think the hardware input side is no problem. There are ready to use objects for encoder and analogue input or I could write my own if necessary.
But how about the USB device implementation? I think nobody likes paying for a individual VID/PID numbers. So is it possible to use existing IDs and still having control over the number of input channels?
EDIT: Found an HID driver in the OBEX. It's in the protocol category, not in "human input". 
Comments
If you meant this one….
https://obex.parallax.com/obex/usb-human-interface-device-driver/
I’ve added the human tag
That's neat. Thanks @VonSzarvas. Not sure I knew about these even though appears new...
Ooh yes, the last updated date shown just got bumped
That might not be ideal, but I guess it promotes the neat object!
Obex isn't letting me log in to make adjustments - keeps telling me my password is incorrect even after I updated it. Thanks Von for fixing the category. I'm attaching the latest versions here, quite a bit has changed; it's still a work-in-progress.
The joystick object uses the standard class, which provides virtually unlimited buttons and up to nine axes. If you need more axes you can run multiple instances connected to a hub, or it should be possible to create a virtual hub though I haven't gotten to that part yet.
As for the VID and PID, as long as it's for personal use it shouldn't be an issue to re-use existing ones. Windows does check for valid numbers and might cause conflicts if the numbers are for a different type of device, or a device using proprietary drivers, but otherwise no problem.
From experience working on usbnew I know that some companies just hijack Microsoft Xbox360 USB and Nintendo Pro Controller VID/PIDs (the former being very common as a way to get windows to load XInput drivers - dire situation there) and no one seems to be stopping them. So maybe paying for a VID is just a polite suggestion and you can just decide which number is yours now.
I've e-mailed you a password reset, and will PM you to carry on this chat!
Ok, thanks, I'll check it out. Nine analogue or encoder axes should be enough, maybe not for the entire cockpit but for one panel at least. How is it handled if I connect multiple devices with the same VID/PID to a hub? Can they be distinguished by a serial number or is the USB enumeration the only way? I know from using multiple ProgPlugs that windows remembers the serial numbers and always assigns the same COM port number to an individual serial number.
@ChrisGadd About the layout of the USB packet (see joystick descriptor.spin2 makeReport() )...
I don't have much experience with USB and HID stuff so I asked my son. He says that there are two possible options if I like to make my own device.
1. Use an existing device that is commonly used and for which a windows driver already exists and replicate that bit-for-bit (same VID/PID and report layout). It's no problem if my device has less axes or buttons. The ones not implemented then simply return 0 and don't work but the rest should.
2. Use a VID/PID combination that windows doesn't already know. It then loads a generic HID driver and I should theoretically be able use any report layout I want.
Can you confirm this?
He also said that many games nowadays have anti-cheat features that check hidden features or bug-for-bug compatibility with gamepads. So a replicated one might not work because it has subtle timing differences or different reaction to non-standard USB requests. So a P2 based joystick might not work with all games. But I think that's not an issue for flight simulators because theese are designed to work even with very special and DIY made equipment.
The joystick object is based on the enumeration from a Saitek Cyborg, possessing 5 axes, hat switch, and 14 buttons running at low speed. I modified the descriptors to give it 9 axes, hat switch, and 32 buttons running at full speed, and Windows is completely unconcerned.
I swapped in the VID/PID for a full-speed Thrustmaster T1600 4-axes, 1-hat, 16-buttons and that also works fine, as does using Atmel's joystick demo VID/PID.
I've been trying for a couple hours to get flight sim to use a genuine T1600 and a P2 copy, or a genuine Saitek and a P2 copy of that, and while it works immediately after the configuration, it does not maintain after unplugging and re-plugging. A genuine Thrustmaster and emulated Saitek does work.
While the USB device descriptor does have a provision for a serial number string, that field is set to zero (not used) in both the Saitek and Thrustmaster. I know it's possible; they even sell a dual Thrustmaster T1600 package.
Ah thanks, good to know.
Yes, serial number = 0 means "do not distinguish". If a serial number != 0 is assigned, windows should theoretically remember the instance and assign the devices correctly even if they are re-plugged to a different USB port. But it's not important if that actually works. I will likely have multiple instances of control devices but they always remain plugged to the same ports. So they should enumerate consistently even without serial number.
Moments after posting about the dual T16000 setup, I remembered that there's a slide switch on the bottom for left or right handed.
The enumeration data is the exact same regardless of the switch position, but it does send a packet whenever the switch is flipped.
There's a short vendor-specific section in the report descriptor that I don't know the meaning of, but I'd wager that's how it differentiates between two devices with the same identifiers.
I tested it some more and the left/right bits don't seem to have any affect with the default Windows driver, as flightsim appears to assign profiles depending on the order they're connected.
Good news, it seems you can use VID/PIDs of devices that Windows doesn't know; it'll use a standard driver based on the enumeration descriptors, and from then on it'll recognize it as whatever's in the product string descriptor.
My flightsim now has a profile for a nine-axes 32-button device that it recognizes as P2 joystick.