none
accessing i2c device through windows application RRS feed

  • Question

  • I am testing HID-I2C compliant device on windows 8. The device is connected over I2C interface but there is no interrupt line from our our I2C device to the x86 Machine.

    Is there any way i can still enumerate my HID-I2C device ?

    From the msdn website i came to know that for HID-I2C enumeration the HID-I2C class driver reads the Device information from ACPI table.

    Is there any way to re-enumerate HID-I2C devices from a user application ? or Is there any way to access i2c device using slave address.

    code sample of any such application can help me a lot.


    Suresh Vaishnav

    Thursday, May 16, 2013 6:48 AM

Answers

  • Since your device does not have an interrupt line (do you poll the device then?), it is not really compliant with HID-I2C, so you cannot expect it to work with the generic HID-over-I2C driver (hidi2c.sys).

    You are going to have to implement a custom HID minidriver. Start with this: KMDF HID Minidrivers or this: UMDF HID Minidrivers, whichever suits your needs. Samples are available in the WDK.

    This page: SPB Peripheral Device Drivers, describes how you can communicate with your device over I2C from your driver (in your case, your HID minidriver).

    After your HID device has finished enumerating (your minidriver should respond correctly to all the IOCTLs that the HID class driver will send to it. The samples and the linked pages will show you how), you can open any of the child HID devices created: HID Clients

    Note that your HID client will not be directly dealing with I2C (it will be bus agnostic). It is your minidriver that is responsible to translate the requests into I2C traffic via the SPB interface.

    Wednesday, June 19, 2013 6:41 PM

All replies

  • I would love to hear an answer to this question because I'm in a similar situation. I. developing a HID-over-I2C device that exposes a top level collection with a vendor-specific usage and I need to access this from an application. The device shows up nicely in Device Manager (the DSDT/ACPI settings are in place and correct as far as I can tell), I know it is enumerating correctly and Windows seems happy with it but when I run my application, its enumeration function doesn't see the device.

    The code I'm using is based on the HClient example. It obtains the HID GUID then calls SetupDiGetClassDevs() and loops calling SetupDiEnumDeviceInterfaces until it returns FALSE. For each device found, I call SetupDiGetDeviceInterfaceDetails to get the device path. In this loop, however, I never see my HID-over-I2C device. Just in case there is something odd about the path, I also open the device and call HidD_GetPreparsedData, HidP_GetCaps and HidD_GetAttributes to read the vendor ID and product ID but, again, nothing matches my device.

    At this point, I'm beginning to be concerned that Windows won't let me access either a HID-over-I2C device or, perhaps, a vendor-specific usage directly from an application.

    Wednesday, June 19, 2013 4:03 PM
  • are you expecting to find the TLC's device path (ie the child that is enumerated) or the parent stack's path? you will only get the child stacks, e.g. paths that are HID\Xxxx\Yyyy, the parent stack, ACPI\Xxxx\Yyyy, are not openable from an application

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

    Wednesday, June 19, 2013 5:45 PM
  • I'm expecting whatever it takes to allow me to receive input reports from my device and send it output reports :-) Given your response, it seems I need to do some more reading. Can you suggest where I can start?

    My goal here is to determine whether it is feasible to talk to a vendor-specific TLC on a HID-over-I2C device directly from an application or whether my attempts are futile and I need to delve into the murky depths of driver programming.

    Wednesday, June 19, 2013 6:35 PM
  • Since your device does not have an interrupt line (do you poll the device then?), it is not really compliant with HID-I2C, so you cannot expect it to work with the generic HID-over-I2C driver (hidi2c.sys).

    You are going to have to implement a custom HID minidriver. Start with this: KMDF HID Minidrivers or this: UMDF HID Minidrivers, whichever suits your needs. Samples are available in the WDK.

    This page: SPB Peripheral Device Drivers, describes how you can communicate with your device over I2C from your driver (in your case, your HID minidriver).

    After your HID device has finished enumerating (your minidriver should respond correctly to all the IOCTLs that the HID class driver will send to it. The samples and the linked pages will show you how), you can open any of the child HID devices created: HID Clients

    Note that your HID client will not be directly dealing with I2C (it will be bus agnostic). It is your minidriver that is responsible to translate the requests into I2C traffic via the SPB interface.

    Wednesday, June 19, 2013 6:41 PM
  • I presume this reply relates to Suresh's original question? I should point out that my HID-over-I2C device does implement a GPIO-based INT line as per the spec.

    Added later: Rereading your answer, I assume that hidi2c.sys should be able to handle my HID-over-I2C device and, as a result, my application should be able to open and communicate with that device using the standard HID APIs without me needing to develop any new driver.

    Taking a closer look at the HID devices listed in Device Manager, I've just noticed that, although I see the ACPI device, I don't see a new device entry for the HID TLC (I see these for the other HID-over-I2C device in the system) so I'll go and take another look at the HID descriptor and report descriptor I'm publishing to see if either of these contains an error. I'll also search for any references for debug logs generated during HID device enumeration in case there's some useful diagnostic information already available on my hard disk somewhere.

    Wednesday, June 19, 2013 6:44 PM
  • Yes, my reply was for the original question.

    When you run the sample HClient app, are you unable to see your device?

    Talking directly to the "HID over I2C" device (the one enumerated by ACPI, most likely) is both, impossible and meaningless. You need to talk to one of it's child devices, and the HClient app should be enumerating all such devices, unless your device is not reporting the TLCs correctly.

    Wednesday, June 19, 2013 7:13 PM
  • Thanks, Rahul - it's great to know that I'm not off on a completely pointless track here. I'll check my descriptors and see why the TLC isn't being reported via Device Manager or HClient correctly.
    Wednesday, June 19, 2013 7:26 PM