Jan Axelson, USB Complete

Подождите немного. Документ загружается.

277



*WOCP+PVGTHCEG&GXKEGU

7UKPI%QPVTQNCPF

+PVGTTWRV6TCPUHGTU

The human interface device (HID) class was one of the first USB classes sup-

ported under Windows. On PCs running Windows 98 or later, applications

can communicate with HIDs using the drivers built into the operating system.

Because the HID class supports exchanging data for application-specific pur-

poses, many special-purpose devices use the HID class.

Chapter 7 introduced the class. This chapter shows how to determine whether a

device can use the human-interface class, introduces HID-specific requests, and

discusses HID firmware options. Chapter 12 describes the reports that HIDs

use to exchange information and Chapter 13 shows how to access HIDs from

applications.

Chapter 11

278

9JCVKUC*+&!

The name human interface device suggests that HIDs interact directly with peo-

ple, and many HIDs do just that. A mouse detects when someone moves it or

presses a key. A host may send data that translates to an effect that a user senses

on a joystick. Besides keyboards, mice, and joysticks, devices with HID inter-

faces include remote controls; telephone keypads; game controls such as data

gloves and steering wheels; barcode readers; and UPS units. Devices with phys-

ical control panels can use a HID interface to send control-panel input to the

host. Devices with virtual control panels on the host can use a HID interface to

send control-panel data to the device. A virtual control panel can be cheaper to

implement than traditional physical controls on a device.

A HID doesn’t have to have a human interface. The device just needs to be able

to function within the limits of the HID class specification. These are the major

abilities and limits of HID-class devices:

• All data exchanged resides in fixed-length structures called reports. The

host sends and receives data by sending and requesting reports in control or

interrupt transfers. The report format is flexible and can handle just about

any type of data.

• A HID must have an interrupt IN endpoint for sending Input reports.

• A HID can have at most one interrupt IN endpoint and one interrupt

OUT endpoint. A device that requires more interrupt endpoints can be a

composite device with multiple HID interfaces. An application obtains sep-

arate handles for each HID in the device.

• The interrupt IN endpoint enables the HID to send information to the

host at unpredictable times. For example, there’s no way for the host com-

puter to know when a user will press a key on the keyboard, so the host’s

driver uses interrupt transactions to poll the device periodically to obtain

new data. SuperSpeed devices can send ERDY Transaction Packets to

request communications with the host.

• The rate of data exchange is limited. As Chapter 3 explained, a host can

guarantee a low-speed interrupt endpoint a maximum data transfer rate of

800 bytes/sec. For full-speed endpoints, the maximum is 64 kB/s.

High-speed and SuperSpeed endpoints support faster rates, but to comply

with the USB 2.0 and USB 3.0 specifications, the endpoints in the default

interface should request no more than 64 kB/s. Under Windows, support-

ing an alternate HID interface requires a vendor-provided driver, which

Human Interface Devices: Using Control and Interrupt Transfers

279

eliminates the advantage of using Windows-provided drivers. Control

transfers have no guaranteed bandwidth except for the bandwidth reserved

for all control transfers on the bus.

• Windows 98 Gold (original edition) supports USB 1.0, so interrupt OUT

transfers aren’t supported and all host-to-device reports must use control

transfers.

A HID may be just one of multiple interfaces in a device. For example, a USB

speaker might use isochronous transfers for audio and a HID interface for con-

trolling volume, balance, treble, and bass.

*CTFYCTG4GSWKTGOGPVU

To comply with the HID specification, the interface’s endpoints and descriptors

must meet several requirements.

'PFRQKPVU

All HID transfers use either the control endpoint or an interrupt endpoint.

Every HID must have an interrupt IN endpoint for sending data to the host.

An interrupt OUT endpoint is optional. Table 11-1 shows the transfer types

and their typical use in HIDs.

4GRQTVU

The requirement for an interrupt IN endpoint suggests that every HID must

have at least one Input report defined in the HID’s report descriptor. Output

and Feature reports are optional.

%QPVTQN6TCPUHGTU

The HID specification defines six class-specific requests. Two requests, Set

Report and Get Report, provide a way for the host and device to transfer

reports to and from the device using control transfers. Set Idle and Get Idle set

and read the Idle rate, which determines whether or not a device resends data

that hasn’t changed since the last report. Set Protocol and Get Protocol set and

read a protocol value, which can enable a device to function with a simplified

protocol when the full HID drivers aren’t loaded on the host, such as during

boot up.

Chapter 11

280

+PVGTTWRV6TCPUHGTU

Interrupt endpoints provide another way to exchange data, especially when the

receiver must get the data periodically and with minimum delay. Control trans-

fers can be delayed if the bus is very busy, while the bandwidth for interrupt

transfers is guaranteed to be available after successful enumeration.

The ability to do Interrupt OUT transfers was added in USB 1.1, and the

option to use an interrupt OUT pipe was added to version 1.1 of the HID

specification. Windows 98 SE was the first Windows edition to support USB

1.1 and HID 1.1.

(KTOYCTG4GSWKTGOGPVU

The device’s descriptors must include an interface descriptor for the HID class,

a class-specific HID descriptor, and an interrupt IN endpoint descriptor. An

interrupt OUT endpoint descriptor is optional. The firmware must also con-

tain a class-specific report descriptor with information about the format and use

of the report data.

A HID can support one or more reports. The report descriptor specifies the size

and contents of the data in a device’s report(s) and may also include informa-

tion about how the receiver of the data should use the data. Values in the

descriptor define each report as an Input, Output, or Feature report. The host

receives data in Input reports and sends data in Output reports. A Feature

report can travel in either direction.

Table 11-1: The transfer type used in a HID transfer depends on the chip’s

abilities and the requirements of the data being sent.

6TCPUHGT

6[RG

5QWTEGQH

&CVC

6[RKECN&CVC 4GSWKTGF

2KRG!

9+PFQYU

5WRRQTV

Control Device

(IN transfer)

Data that doesn’t have critical timing

requirements.

yes Windows 98

Gold and later

Host

(OUT transfer)

Data that doesn’t have critical timing

requirements, or any data if there is

no OUT interrupt pipe.

Interrupt Device

(IN transfer)

Periodic or low-latency data. yes

Host

(OUT transfer)

Periodic or low-latency data. no Windows 98

SE and later

Human Interface Devices: Using Control and Interrupt Transfers

281

Every device should support at least one Input report that the host can retrieve

using interrupt transfers or control requests. Output reports are optional. To be

compatible with Windows 98 Gold, devices that use Output reports should

support sending the reports using control transfers. Using interrupt transfers for

Output reports is optional. Feature reports always use control transfers and are

optional.

&GUETKRVQTU

As with any USB device, a HID’s descriptors tell the host what it needs to know

to communicate with the device. Listing 11-1 shows example device, configura-

tion, interface, class, and endpoint descriptors for a HID with a vendor-specific

function.

The host learns about the HID interface during enumeration by sending a Get

Descriptor request for the configuration containing the HID interface. An

interface descriptor specifies the HID interface. A HID class descriptor specifies

the combined number of report and physical descriptors supported by the

interface. During enumeration, the HID driver requests the report descriptor

and any physical descriptors.

2$2

In PICBASIC PRO, descriptor tables are in assembly code. Each table is a list

of values with each preceded by a retlw instruction, which places the literal

value that follows in the working register and returns to the calling code. You

don’t have to know assembly code to compose a descriptor. Start with an exam-

ple and edit the values as needed.

Chapter 11

282

Device Descriptor

12 bLength Descriptor size in bytes

01 bDescriptorType Descriptor type (Device)

0200 bcdUSB USB Specification release number (BCD) (2.00)

00 bDeviceClass Class Code (class is specified in interface descriptor)

00 bDeviceSubClass Subclass code

00 bDeviceProtocol Protocol code

08 bMaxPacketSize0 Endpoint zero maximum packet size

0925 idVendor Vendor ID (Lakeview Research)

1234 idProduct Product ID

0100 bcdDevice Device release number (BCD)

01 iManufacturer Manufacturer string index

02 iProduct Product string index

00 iSerialNumber Device serial number string index

01 bNumConfigurations Number of configurations

Configuration Descriptor

09 bLength Descriptor size in bytes

02 bDescriptorType Descriptor type (Configuration)

0029 wTotalLength Total length of this and subordinate descriptors

01 bNumInterfaces Number of interfaces in this configuration

01 bConfigurationValue Index of this configuration

00 iConfiguration Configuration string index

A0 bmAttributes Attributes (bus powered, remote wakeup supported)

32 bMaxPower Maximum power consumption (100 mA)

Interface Descriptor

09 bLength Descriptor size in bytes

04 bDescriptorType Descriptor type (Interface)

00 bInterfaceNumber Interface Number

00 bAlternateSetting Alternate Setting Number

02 bNumEndpoints Number of endpoints in this interface

03 bInterfaceClass Interface class (HID)

00 bInterfaceSubclass Interface subclass

00 bInterfaceProtocol Interface protocol

00 iInterface Interface string index

Listing 11-1: Example descriptors for a vendor-specific HID. All values are in

hexadecimal. (Part 1 of 2)

Human Interface Devices: Using Control and Interrupt Transfers

283

HID Descriptor

09 bLength Descriptor size in bytes

21 bDescriptorType Descriptor type (HID)

0110 bcdHID HID Spec. release number (BCD) (1.1)

00 bCountryCode Country code

01 bNumDescriptors Number of subordinate class descriptors

22 bDescriptorType Descriptor type (report)

002F wDescriptorLength Report descriptor size in bytes

Interrupt IN Endpoint Descriptor

07 bLength Descriptor size in bytes

05 bDescriptorType Descriptor type (Endpoint)

81 bEndpointAddress Endpoint number and direction (1 IN)

03 bmAttributes Transfer type (interrupt)

0040 wMaxPacketSize Maximum packet size

0A bInterval polling interval (milliseconds)

Interrupt OUT Endpoint Descriptor

07 bLength Descriptor size in bytes

05 bDescriptorType Descriptor type (Endpoint)

01 bEndpointAddress Endpoint number and direction (1 OUT)

03 bmAttributes Transfer type (interrupt)

0040 wMaxPacketSize Maximum packet size

0A bInterval polling interval (milliseconds)

Listing 11-1: Example descriptors for a vendor-specific HID. All values are in

hexadecimal. (Part 2 of 2)

Chapter 11

284

Here is Listing 11-1’s device descriptor for use in PICBASIC PRO:

DeviceDescriptor

retlw (EndDeviceDescriptor-DeviceDescriptor)/2; bLength

retlw 0x01 ; bDescriptorType

retlw 0x00 ; bcdUSB low byte

retlw 0x02 ; bcdUSB high byte

retlw 0x00 ; bDeviceClass

retlw 0x00 ; bDeviceSubClass

retlw 0x00 ; bDeviceProtocol

retlw 0x08 ; bMaxPacketSize0

retlw 0x25 ; idVendor low byte

retlw 0x09 ; idVendor high byte

retlw 0x34 ; idProduct low byte

retlw 0x12 ; idProduct high byte

retlw 0x00 ; bcdDevice low byte

retlw 0x01 ; bcdDevice high byte

retlw 0x01 ; iManufacturer

retlw 0x02 ; iProduct

retlw 0x00 ; iSerialNumber

retlw 0x01 ; bNumConfigurations

EndDeviceDescriptor

%

For Microchip’s MPLAB C18 compiler, descriptors can reside in structures.

This structure holds a device descriptor:

typedef struct __attribute__ ((packed)) _USB_DEVICE_DESCRIPTOR

{

BYTE bLength;

BYTE bDescriptorType;

WORD bcdUSB;

BYTE bDeviceClass;

BYTE bDeviceSubClass;

BYTE bDeviceProtocol;

BYTE bMaxPacketSize0;

WORD idVendor;

WORD idProduct;

WORD bcdDevice;

BYTE iManufacturer;

BYTE iProduct;

BYTE iSerialNumber;

BYTE bNumConfigurations;

} USB_DEVICE_DESCRIPTOR;

Human Interface Devices: Using Control and Interrupt Transfers

285

This is Listing 11-1’s device descriptor stored in a structure:

ROM USB_DEVICE_DESCRIPTOR device_dsc=

{

0x12, // bLength

0x01, // bDescriptorType

0x0200, // bcdUSB

0x00, // bDeviceClass

0x00, // bDeviceSubClass

0x00, // bDeviceProtocol

0x08, // bMaxPacketSize0

0x0925, // idVendor

0x1234, // idProduct

0x0100, // bcdDevice

0x01, // iManufacturer

0x02, // iProduct

0x00, // iSerialNumber

0x01 // bNumConfigurations

};

6JG*+&+PVGTHCEG

In the interface descriptor, bInterfaceclass = 03h to identify the interface as a

HID. Other fields that contain HID-specific information in the interface

descriptor are the bInterfaceSubclass and bInterfaceProtocol fields, which can

specify a boot interface.

If bInterfaceSubclass = 01h, the device supports a boot interface. A HID with a

boot interface can communicate with the host even when the host hasn’t loaded

its HID drivers. This situation might occur when the computer boots directly

to DOS or when viewing the system setup screens that you can access on

bootup, or when using Windows Safe mode for system troubleshooting.

A keyboard or mouse with a boot interface can use a simplified protocol sup-

ported by the BIOS in many hosts. The BIOS loads from ROM or other

non-volatile memory on bootup and is available in any operating-system mode.

The HID specification defines boot-interface protocols for keyboards and mice.

If a device has a boot interface, bInterfaceProtocol indicates if the HID sup-

ports a keyboard (01h) or mouse (02h) function.

The HID Usage Tables document defines the report format for keyboards and

mice that use the boot protocol. The BIOS understands the boot protocol and

assumes that a boot device will support the protocol, so the BIOS doesn’t need

to read a report descriptor from the device. Before sending or requesting