HID reports and data transfer

[mrast]

Hello Jan,

I'm trying to implement a Custom HID report in a device, for it to receive 2 bytes sporadically and acknowledge the reception of the data with the current state of the system, also with 2 bytes. For what I have been reading, a feature report would be the more appropriate to do so, but I have already implemented an HID with an output and an input report. In my code I have also created a new interface with two endpoints (1 and 2) for each report.

There are some things that still are not so clear for me. Would you be so kind to comment the following points:

1 - From the host I can write to the output report using a control transfer to endpoint 0 with a SET_REPORT flag - in this case, I will get an interruption on my device and can redirect the received data to wherever I want. In this case I would not need the endpoint 1.

2 - From the host I can write data to the output report using an interrupt transfer to endpoint 1. In this case my device does not receive an interruption (hardware interruption) the endpoint buffer needs to be polled from time to time, as it expects new data.

3 - For the input report, I can also use either a control or an interrupt transfer. If I use the control transfer I would also have no use for endpoint 2.

4 - Using the control transfer, seems to be the solution more easy to implement. Does it have any disadvantage for my goal? Is it better to have the 2 possible transfer types implemented?

5 - If using the interrupt transfer how do I connect my endpoints to my HID descriptor? Do I need to somehow connect them, or the HID descriptor is just informative about data format to the host? When the host receives an HID report, with several reports (a mouse and a keyboard, for instance), how does it associate each report to the respective endpoint? Is the report ID a key element in this association?

Miguel

[Jan Axelson]

1. yes

2. Whether you can implement an interrupt to signal that new data has arrived depends on the capabilities of the device hardware. Most USB controllers include this capability, however, for better efficiency. Check your device's data sheet.

3. Yes, if you use the control endpoint, you don't need the interrupt endpoint. The HID spec requires an interrupt IN endpoint on all devices, but you can comply by enabling the endpoint, giving it a low latency, and always returning NAK. I don't know if any hosts enforce the requirement, but it's always safe to comply.

4. Control endpoints are ideal for sporadic data that doesn't have strict timing needs. However, if you're going to implement the IN endpoint anyway, you might find it just as easy to use it.

5. A HID interface can have at most one IN endpoint and (optional) one OUT endpoint.

To support two functions, a device/chip can have two HID interfaces. In this case, each interface has its own endpoints, and the Setup stage of control transfers specifies the target interface.

Or a single HID interface can have a top-level collection for each function. In this case, the functions share HID endpoints and use report IDs to identify the target function.

[mrast]

Thanks, your page and replies are really helpful.