none
HID over I2C of HID descriptor RRS feed

  • Question

  • I'm developing a HID-over-I2C device but having some problems.
    In section 5.1.1 HID DESCRIPTOR FORMAT of the specification "hid-over-i2c-protocol-spec-v1-0.docx",
    it mention that wMaxInputLength is the length of the largest Input Report to be read from the Input Register.
    I want to design two Input Report by different Report ID and in different length for vendor specific.
    I wander that Host will always get the largest length of date from device no matter what the Report ID is.
    USB HID have the endpoint concept to distinguish from Report ID 1 and Report ID 2.
    Is any structure like endpoint to recognize different length from different Report ID.
    How can I achieve this target?

    Any comments would be highly appreciated.

    Best Regards,
    Thursday, July 25, 2013 12:02 AM

Answers

  • I don't quite follow the issue you are having. The HID-I2C descriptor should specify in wMaxInputLength the size of the largest possible input report that your device can generate. This is used just to figure out how many bytes we must attempt to read over the I2C bus. So even if your device supports one type of input report (A) of size 10, and another type of input report (B) of size 20, we will always attempt to read 20 bytes from the device when it interrupts. At that time, if the device only has an input report of type A, it is free to return just 10 bytes (and then generate a NACK at the I2C level). If your HID client has request an input report of type A (using HidD_GetInputReport or something else), we'll satisfy that request correctly.

    Does that answer your question?

    Friday, July 26, 2013 5:31 PM
  • I'm sorry, I was mistaken. You are right, the sender cannot NACK if it has no more data. So HIDI2C will always attempt to read wMaxInputLength bytes, but if the report that is currently available is smaller than that, your HID device can just return garbage bytes for the rest of the transfer (essentially your I2C slave should not drive the SDA line after it has finished delivering the input report).

    Take a look at section 6.2.2. in the HID over I2C spec. That describes what an input report should look like. The first two bytes should contain the actual size of the input report available. HIDI2C will use that value to indicate what the right size of the HID report is, so even though we read wMaxInputLength bytes from the device, the resulting HID report (as seen from the HID client application) will be correctly formatted with the right size.

    Wednesday, July 31, 2013 10:16 PM

All replies

  • I don't quite follow the issue you are having. The HID-I2C descriptor should specify in wMaxInputLength the size of the largest possible input report that your device can generate. This is used just to figure out how many bytes we must attempt to read over the I2C bus. So even if your device supports one type of input report (A) of size 10, and another type of input report (B) of size 20, we will always attempt to read 20 bytes from the device when it interrupts. At that time, if the device only has an input report of type A, it is free to return just 10 bytes (and then generate a NACK at the I2C level). If your HID client has request an input report of type A (using HidD_GetInputReport or something else), we'll satisfy that request correctly.

    Does that answer your question?

    Friday, July 26, 2013 5:31 PM
  • Thanks for your reply.

    You mention that "So even if your device supports one type of input report (A) of size 10, and another type of input report (B) of size 20, we will always attempt to read 20 bytes from the device when it interrupts. At that time, if the device only has an input report of type A, it is free to return just 10 bytes (and then generate a NACK at the I2C level)."

    In the I2C protocol, master and slave both can send and receive data. If master want to get data from slave, master generate clock to slave and slave send data to master. At the end of the time when slave send data to the master (master receive data from slave), master should trigger the state of ACK or NACK on the bus. Master trigger state ACK to imply the next data transmission. Master trigger state NACK to imply the STOP transmission. Is that right ?


    So I want to know if the NACK state can generate by the slave ?  

    Best Regards,

    Tuesday, July 30, 2013 2:01 AM
  • I'm sorry, I was mistaken. You are right, the sender cannot NACK if it has no more data. So HIDI2C will always attempt to read wMaxInputLength bytes, but if the report that is currently available is smaller than that, your HID device can just return garbage bytes for the rest of the transfer (essentially your I2C slave should not drive the SDA line after it has finished delivering the input report).

    Take a look at section 6.2.2. in the HID over I2C spec. That describes what an input report should look like. The first two bytes should contain the actual size of the input report available. HIDI2C will use that value to indicate what the right size of the HID report is, so even though we read wMaxInputLength bytes from the device, the resulting HID report (as seen from the HID client application) will be correctly formatted with the right size.

    Wednesday, July 31, 2013 10:16 PM
  • Thanks for your reply.

    You mention that "HID device can just return garbage bytes for the rest of the transfer." I understand your opinion.

    I design two input report by different report ID and in different length for different purpose. These two data channel has different frequency for host requirement.

    For example:
    Input report (A) of size 10, and another type of input report (B) of size 20. Host get data from input report (A) is more frequent than from input report (B). It waste more time to transfer garbage bytes for data transfers in input report (A).

    Is there any concept like endpoint in USB HID to recognize different length in different report ID? How to resolve this issue for improve the efficiency of data transfer in HID over I2C interface.

    Any comments would be highly appreciated.

    Best Regards,

    Thursday, August 1, 2013 10:21 AM
  • Unfortunately, that is a current limitation of the HIDI2C protocol. It will always attempt to read wMaxInputLength number of bytes.

    I understand that it is problematic in your case. Is it possible for you to design your device to actually have two separate I2C slave addresses and two separate GPIO interrupt lines? That way, instead of one HIDI2C device exposing two types of input reports, you could have two separate HIDI2C devices exposing one type of input report each. That way we will always read the correct number of bytes from a particular device. Note that this doesn't necessary mean two physically separate hardware devices; just that your device will respond to two different I2C slave addresses, and knows which GPIO interrupt to toggle based on what kind of input it has.

    Thursday, August 1, 2013 4:09 PM