prajwal wrote:
BenLunt wrote:
There is an "Interval" value in the descriptor that tells you how often to "poll" for data via an interrupt request. You should only send a single request once per this interval. If you send two within this interval, the device may clear its internal buffer thinking you already read the next keystroke.
I fail to understand this part - in my case, I have a TR ring of size 64. if I have a scheduled task/timer task which will create an 'Interrupt In' transaction every "interval" while I don't press any keys at all for say next 64 * "interval" period - wouldn't the TR ring be full with all the "Interrupt In" TRBs ? Wouldn't that be same situation as 'schedule all at once' ?
An HID device, a keyboard for example, returns reports to the Host. These reports contain information about the state of the HID device. A keyboard, for example, will return key status changes in a report. The Keyboard may have a small buffer to contain multiple reports so that they are buffered until the Host reads them. Once the Host reads a report, via the interrupt request, it removes it from the buffer giving room for the next report.
However, when a report is ready, it does not return an interrupt as the PS/2 style keyboard does. Therefore, the host has no way of knowing that a key has been pressed or released. The Host must poll the device by sending out an interrupt request. How does the Host know how often to send out this request? The interrupt endpoint descriptor. Within this descriptor is an interval member.
The one I use for an example with in my
book has an interval value of 24ms, meaning that I should send out an interrupt request once every 24ms. This means the the keyboard is capable of creating a report every 24ms, giving a report with a possible change in the status of the keyboard every 24ms. Can you type fast enough to make a key status change once every 24ms?
The keyboard may respond with the same report even though no change has taken place. Therefore, most keyboards support the Set Idle request. This request tells the keyboard to only return a report if there is a change in the state of the keyboard. Sending this request can tell the keyboard to only return a report when a key is pressed or released.
A note: If you send out an interrupt request every 24ms and there is no change which means there is no report to receive, the keyboard may/should return a NAK. Be prepared to expect it.
Once you have setup the keyboard via this Set Idle request, you have parsed the HID report to get the format of the report returned, you can then place an interrupt request on your schedule every 24ms. Most of the interrupt requests will NAK since you can't type fast enough to keep up with a 24ms cycle. However, some of them will return a report.
Pressing a key may return:
00 00 05 00 00 00 00 00
while releasing that key may return:
00 00 00 00 00 00 00 00
There was a change when the key was pressed, so the report was generated and returned. Then there was a change in the report when the key was released, so another report was generated and returned, though this time all zeros because there is nothing to report, other than, there was a change.
If you do not send the Set Idle request, the keyboard may return:
00 00 05 00 00 00 00 00
00 00 05 00 00 00 00 00
...
00 00 05 00 00 00 00 00
00 00 05 00 00 00 00 00
repeatedly until the key is released. Then the keyboard may return:
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
...
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
repeatedly until there is another change in the keyboard.
Look up the Set Idle request to see more about it. It should be sent as:
21 0A 00 00 00 00 00 00
Does this now make sense? Kind of?
Ben
http://www.fysnet.net/the_universal_serial_bus.htm