Author Topic: HID bInterval  (Read 11839 times)

towlerg

  • Member
  • ***
  • Posts: 24
HID bInterval
« on: January 12, 2014, 01:29:23 pm »
Hi

I'm looking for info about the descriptor entry, bInterval (polling interval).

I've read elsewhere that bInterval is is only used by interrupt transfers and may be any value between 1 and 255. Is this true?


I'm confused because in your book, in the section on Host communication, you state
Quote
An OHCI controller will poll an interrupt endpoint at least once every 32 ms even if the endpoint descriptor requests
a maximum latency of 255 ms, while UHCI controllers can, but don’t have to, support less-frequent polling.

Maybe I've misunderstood and this refers to something else.


Also, all example I've seen have this field set to either 1 or 10

What would be the impact of making this field 20 or 30?


BTW I'm interested because I'm trying using a one wire bit bang interface which can be really slow.

Rgds    George

 

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: HID bInterval
« Reply #1 on: January 12, 2014, 02:09:00 pm »
For interrupt endpoints, bInterval is the _maximum_ latency, or time between transaction attempts by the host. If bInterval = 10, the host may schedule a transacation every 10 ms or less. So with bInterval = 255, polling every 32 ms, or every 1 ms, or every 255 ms is allowed.

More frequent polling does no harm except waste some bandwidth. The device endpoint returns NAK if not ready to send or receive data.


Barry Twycross

  • Frequent Contributor
  • ****
  • Posts: 263
Re: HID bInterval
« Reply #2 on: January 12, 2014, 04:26:56 pm »
Jab is correct, the actual polling interval must be no longer than the bInterval. Writing controller drivers I've taken advantage of that to make my life easier or to work around a controller bug.

The use of bInterval also depends on the USB spec version and the speed. At high speed (per the USB 2 spec) the bInterval is a power of two in micro-frame units.

The bInterval is also used by Isoc endpoints. USB 1 allowed only 1, USB 2 allowed larger intervals.

For bulk endpoints it must be zero in the usb 1.x spec, usb 2 allowed other values which were supposed to be the maximum number of NAKs which the endpoint produced. I know of no devices which implemented that, or hosts which took any notice of it.

You've probably only seen 1 or 10 as that's the minimum allowed of full speed interrupt endpoints (1) or low speed interrupt endpoints (10). They're common values for devices to use, though there are devices which use other values. Mice are particularly fond of using 10.

If he field were made 20 or 30 the device might be polled at a longer interval like 16ms or they might not, depending on the controller and driver. The device has to be able to cope with shorter polling intervals up to the minimum for the device's speed. Not all of them will if you poll too fast.