Almost all the electronics I build rely on a USB HID connection. USB HID is built into all major operating systems and makes device connection much simpler. The downside is small transfer size, but my designs rarely move large amounts of data. While I could probably write an OS driver for other USB implementations, that is time I would rather dedicated to new ideas. On the Windows side I use RAD Studio (Delphi) to build the Windows Apps. ( I also use this for the Android Apps). For the USB HID component I have been using the JEDI project VCL controls, which include a USB HID non-visual control. Once I determined the correct configuration, this has performed quite well. It did take a few months to "wring out" all the nuances of the control.
Several months ago I started noticing issues when connecting to the device. Then apps with USB HID interfaces would not compile. This all began with a new version of the compiler (10.4.x). I backed up to the previous version and all was great, kind of. There were still issues on occasion. (In retrospect, it was only one computer, my HP Elitebook 850 G5, giving me issues on previously compiled apps.)
After too many days of researching this USB issue, I finally found
it. The USB HID component is part of the JEDI VCL library,
provided as source. The source is kept up to date through the JEDI group and has an extensive "ifdef" structure, to ensure backwards compatibility for many versions of RAD Studio. The
USB HID component is compiled when it is installed into the RAD Studio IDE component palette, this way it is compatible with multiple
versions of the compiler. Sometime after version 10.4.2 of the
compiler was released, several patches were released. Long story
short, when the USB HID was installed (without patches), the
compilation corrupted the registry access when enumerating the installed HID
devices. When I installed the latest version of the compiler on a
clean PC, updated all the patches and then installed the USB HID
component, it worked just fine, kind of....................
It worked on all the computers, except my HP Elitebook 850 G5 laptop,
that is my primary computer. I kept putting off working on it
because it looked like some kind of driver/registry corruption and
reinstalling windows and then all the software looked like the only solution. Well that was not
something I wanted to do. But today it got to be too much, so
before trying to reinstall Windows and rebuild the entire computer, I started debugging again.
What I noticed is that sometimes it would enumerate some HID
devices before failing and other times it failed immediately. So
then I started tracking Vendor ID/Product ID data on each device.
After several runs a trend started to appear, it was always the
same device failing, but at different points in the enumeration.
Something called "HID Sensor Collection V2". I disabled the
device and then all of the USB HID programs started working.
Looking at my other two computers, neither has this device.
Further digging showed that Windows would allow the generic HID
compatible driver to be attached to the device and that also
worked.
I have a USB HID exerciser that Microchip use to provide for PIC
USB HID development. It is a small Windows program that gives you
all the data on your device in order to verify operation. It
never shows this HID device, unless I use the generic HID driver.
What is happening is that a call to the Windows HID.dll is
returning a failure(HidD_GetAttributes), which is verified by the error message the
HID exerciser is showing. Looking into the open source code I am
using for the HID interface and tracing to the failure, it is the
same call to the HID.dll. So now I am pretty sure I have found
the problem.
So what does this device do? Dont know for sure, but it looks
like it controls several accessories like accelrometer, gyro, temp
etc. The list of devices implies it is for a tablet or tablet
mode of a PC. For now I will use the generic driver and see if
anything fails. The error checking at that point in the code is not robust enough
to handle that error and let the program continue to run. On the JEDI forum this problem had been previously noted and I added my data. A proposed solution is to ignore the error. Workable, but not elegant. Once I get a few more things done, I plan to return to this and see if I cant come up with a solution that will work for more people.
No comments:
Post a Comment