Reading and writing USB HID FeatureReports async.
-
Hi, I am trying to communicate with a HID device, using feature reports. When using normal input and output reports, I use the
FileStreamto read and write reports. This works great, even with async communication. My problem is that I am using feature reports instead. This means using theHidD_SetFeatureandHidD_GetFeaturefrom the Windows hid.dll file. This also works, but theHidD_GetFeaturecannot be used async. When called it does not block until there is a report, so I end up having to poll when I expect there to be data. So I am looking for a way to do feature reports async, or have theHidD_GetFeaturemethod to block until there actually is a report. Any insight is appreciated! -
Hi, I am trying to communicate with a HID device, using feature reports. When using normal input and output reports, I use the
FileStreamto read and write reports. This works great, even with async communication. My problem is that I am using feature reports instead. This means using theHidD_SetFeatureandHidD_GetFeaturefrom the Windows hid.dll file. This also works, but theHidD_GetFeaturecannot be used async. When called it does not block until there is a report, so I end up having to poll when I expect there to be data. So I am looking for a way to do feature reports async, or have theHidD_GetFeaturemethod to block until there actually is a report. Any insight is appreciated!I'm curious why you need to constantly get feature information from a HID device since the feature set of a device should be static and fetching it once in response to a connection event I would think would be sufficient. However, it's not for me to judge... ;) If the function doesn't support async there is no way to make it act that way without implementing some sort of polling. Unlike making an async call synchronous, there is no 'await' for functions that don't use a callback and immediately return. That being said, it isn't too hard to implement your own. Setting up a background worker or some other threading solution (even a system.threading.timer can be used) so you check at a given interval is very common. It used to be used a lot with serial comms to check the input buffer. The only gotcha is to make sure you have an abort so your app doesn't hang at close. If you use a timer with a polling interval it will automatically abort when your app shuts down. Also, make sure you handle the cross-thread marshal if anything is going up to the UI.
-
I'm curious why you need to constantly get feature information from a HID device since the feature set of a device should be static and fetching it once in response to a connection event I would think would be sufficient. However, it's not for me to judge... ;) If the function doesn't support async there is no way to make it act that way without implementing some sort of polling. Unlike making an async call synchronous, there is no 'await' for functions that don't use a callback and immediately return. That being said, it isn't too hard to implement your own. Setting up a background worker or some other threading solution (even a system.threading.timer can be used) so you check at a given interval is very common. It used to be used a lot with serial comms to check the input buffer. The only gotcha is to make sure you have an abort so your app doesn't hang at close. If you use a timer with a polling interval it will automatically abort when your app shuts down. Also, make sure you handle the cross-thread marshal if anything is going up to the UI.
Hi Jason Thank you for your input, appreciated! Unfortunately, I did not write the firmware for the device. It uses feature reports as a 'bidirectional' report instead of input/output reports. I have already implemented a polling solution, with best guess of how long to wait for, and what the polling frequency should be. It works, but burns a lot of clock cycles in an already loaded system. Thanks again and good luck with the fireworks - be careful :)
-
Hi Jason Thank you for your input, appreciated! Unfortunately, I did not write the firmware for the device. It uses feature reports as a 'bidirectional' report instead of input/output reports. I have already implemented a polling solution, with best guess of how long to wait for, and what the polling frequency should be. It works, but burns a lot of clock cycles in an already loaded system. Thanks again and good luck with the fireworks - be careful :)
Ugh! Why do some vendors insist on doing things their own way instead of the way everyone else in the world does it! Good luck. Polling is always a fine art of balancing responsiveness against overhead. Thanks for the good wishes. We are buried in snow here in the Midwest US and I am VERY ready for fireworks season to return!
-
Hi, I am trying to communicate with a HID device, using feature reports. When using normal input and output reports, I use the
FileStreamto read and write reports. This works great, even with async communication. My problem is that I am using feature reports instead. This means using theHidD_SetFeatureandHidD_GetFeaturefrom the Windows hid.dll file. This also works, but theHidD_GetFeaturecannot be used async. When called it does not block until there is a report, so I end up having to poll when I expect there to be data. So I am looking for a way to do feature reports async, or have theHidD_GetFeaturemethod to block until there actually is a report. Any insight is appreciated!What about polling in a different thread and adding a custom event when data are available? With the current multi-core computers, that should help to remove load from the main (UI) thread of the application. Beware of Control.Invoke/BeginInvoke when you then update the UI on data received from the device.