User's Manual

Enhanced Class 1 Bluetooth v2.1 Module
User’s Guide
Americas: [phone] Option 2
Europe: [phone]
Hong Kong: [phone]
www.lairdtech.com/wireless
135
CONN-GUIDE-BT740_v0.2
See description of the command CMD_BLOB_MANAGE for all the actions possible.
13.2 HID Connections
HID (Human Interface Device) was originally described in detail in a specification published by the USB
organization. The Bluetooth SIG has built on that idea but uses wireless instead of USB as the transport
mechanism.
The HID specifications are very dry and heavy tomes from a developer’s perspective, denying the user
experience, which is ‘it just works’ and ‘is simple’.
The objective of the HID functionality provided in the Laird Bluetooth module is to provide the same ‘it just
works’ and ‘is simple’ concept, but for developers.
With this in mind, Laird encourages that the developer view the module’s HID functionality as a black box
and the only concepts to be aware and fully understand are input reports, output reports, and how to
create a HID descriptor.
The terminology for input/output is HID Host centric where ‘input’ means information flow from the HID
Device to the HID Host, and vice versa ‘output’ means information flow from HID Host to HID Device.
USB developers are familiar with this concept.
Input and output are packets of information whose format and size are predefined in the HID Descriptor
that totally describes the devices functionality. For example, the standard PC keyboard is defined by a
HID Descriptor which specifies that when a key is pressed or unpressed, an 8 byte INPUT packet shall be
sent to the host and likewise, if the host wants to update one of the LEDs on the keyboard (for example
the numlock LED) then it shall send a 1 byre OUTPUT packet. How the bits in the INPUT and OUTPUT
packets are interpreted are specified in the HID Descriptor.
In a nutshell, when something happens at the device end, it informs the host via an INPUT packet, which
is also called ‘HID Input Report’ and likewise the host sends information at any time using OUTPUT
packets which are also called ‘HID Output Reports’.
This implies that a developer using HID supplied in the Laird module only needs to ask, “What is the
current active HID Descriptor” and then from there decide how to generate and process the reports. A
simple interface supplied at the UART of the module enables appropriate mapping of data into and out of
INPUT and OUTPUT reports. The same interface also enables the developer to upload custom HID
Descriptors into the non-volatile memory of the module.
If no HID Descriptor is uploaded, and the module is configured to expose a HID Device profile, then by
default a HID Descriptor for a 104 key keyboard is exposed, meaning INPUT reports are 8 bytes long and
OUTPUT reports are 1 byte long. In this case, when the host conveys a key press, an 8 byte data packet
has to submit to the module via the UART with data channel ID 0xA0. Likewise any OUTPUT packets
sent by the host appear on data channel 0xA0. If a HID Host profile is active, then the INPUT packets
appear on data channel 0x90 and it send OUTPUT reports as data on channel 0x90.
The built-in HID Device keyboard descriptor has been made even simpler to use if all you want is to send
ASCII characters in the range 0x00 to 0x7F inclusive. In that case, all you must do is send the ASCII
string in a data packet on channel 0x20. The data parser in the module generates two INPUT reports for
each ASCII character. The first INPUT report specifies a key press and the second INPUT report
specifies the unpress event.
Note: If S reg 3 specifies ONLY HID profile, and S Reg 39 specifies the built in keyboard HID
descriptor, then the device class for the device in S Reg 128 automatically overrides.