The Human Interface Device Class (HID) is mainly used for devices that allow human control over a PC. Using these devices, the host is able to react on human input (e.g. movements of a mouse or keypresses). This response has to happen quickly, so that the computer user does not notice a significant delay between his action and the expected feedback. Typical examples for HID class devices are:

Keyboards and pointing devices (such as mouse devices, joysticks and trackballs)
Front-panel controls (for example buttons, knobs, sliders, and switches)
Simulation devices (such as steering wheels, pedals, other VR input devices)
Remote controls and telephone keypads
Other low data-rate devices that provide for example environmental data (such as thermometers, energy meters or even bar-code readers)

A detailed description about HID is provided by the USB Implementers Forum (USB-IF).

HID Class Features

The HID class is not necessarily a human interface. But a device using the HID class has to be able to work within the limits of the HID class. These HID class implementation of the USB Component has the following features:

All data is exchanged in reports. These are fixed-length structures that sent or requested by the USB Host in control or interrupt transfers. Reports have a flexible format and can contain any type of data. Every HID device needs to have one input report in its report descriptor. Output and feature reports are optional.
An interrupt IN endpoint is required for sending input reports to the USB Host.
The maximum number of interrupt IN and OUT endpoints is limited to 1.
The interrupt OUT endpoint is optional.
As the HID device can send data at any point in time using the interrupt IN endpoint, the USB Host driver needs to make sure that the data is polled periodically.
The USB Component supports the HID Class for USB Device and USB Host (MDK-Professional only) applications.

Control Transfers

The HID specification defines six class-specific requests. They enable the USB Host to inquire about the capabilities and the current state of the device. Furthermore, the host can set the state of output and feature items. All six requests are transmitted using the control pipe.

The Get_Report request enables the USB Host to receive a report via the control pipe
The Set_Report request allows the USB Host to send a report to the device (for example for setting device states)
The device's current idle rate can be read using the Get_Idle request. The idle rate determines how often a device resends data that has not changed since the last report.
The idle rate can be set using the Set_Idle request. This is used to limit the reporting frequency of an interrupt IN endpoint. Default idle rates are 500 milliseconds for keyboards (delay before first repeat rate) and infinity for joysticks and mouse devices.
During booting of the USB Host, a simplified protocol can be used for communication. The Get_Protocol request reads which protocol is currently active. The Set_Protocol request switches between the boot protocol and the report protocol.

Interrupt Transfers

To ensure minimum data delay, interrupt endpoints are used. The bandwidth for interrupt transfers is guaranteed for every device after successful enumeration. Control endpoints may face data delivery delay in case the bus is busy.

USB Descriptors

The following descriptors are required in an USB HID Device:

Standard Device Descriptor
Standard Configuration Descriptor
Standard Interface Descriptor for the HID Class
Class-Specific HID Descriptor
Standard Endpoint Descriptor for Interrupt IN endpoint
Class-Specific Report Descriptor

The necessary descriptors are automatically generated by the USB Middleware Component. The report descriptor is built based on the settings in the USBD_Config_HID_x.h file. The number of reports and their maximum size are specified in this file. The page USB Descriptors provides more information on the topic.

Note

Further information on how to use HID is given in the Reference section: