Objective Development Forums

Hi all,

I'm rather new to AVR-USB, I downloaded the HIDKeys demo one hour ago, adapted it to my little ATmega8 test setup and just added a loop that increments the "pressed" button every 45 timer overflows, so I should get A...B...C... and so on, spaced by about one second. This works, but I get each character 8 times in a row or so.
This has obviously something to do with the timer overflow loop also setting keyDidChange=1 (which I also used to indicate that a new letter shoule be sent)

But before I simply kick out this idleRate-stuff as other people seem to
do I'd like to know what it is exactly for.

When I'm done, it will be a small board with 24 ruggedized contact-closure inputs to trigger sound effects in a fair stall, I'll put it onto my web site along with some other ideas for which it could be used.

shaun wrote:But before I simply kick out this idleRate-stuff as other people seem to do I'd like to know what it is exactly for.

Device Class Definition for HID, chap. 7.2.4 Set_Idle Request wrote:The Set_Idle request silences a particular report on the Interrupt In pipe until a new event occurs or the specified amount of time passes. [..]

This request is used to limit the reporting frequency of an interrupt in endpoint. Specifically, this request causes the endpoint to NAK any polls on an interrupt in endpoint while its current report remains unchanged. In the absence of a change, polling will continue to be NAKed for a given time-based duration. [..]

The recommended default idle rate (rate when the device is initialized) is 500 milliseconds for keyboards (delay before first repeat rate) and infinity for joysticks and mice.

Ok.... I'll have to read this another time to fully get it, it's not only my first contact with AVR-USB, but also USB on the lower levels. I've used FTDI chips before (USB->RS232, to name it) and written some Linux programs to talk with hardware enabled for USB with FTDI chips on the usblib level.

In the example of the HIDKeys the keyDidChange=1 is just in the wait loop to send the lastKey another time after the defined time has elapsed although the actual key did not change to implement a key repeat feature - right?
Now I'll think what I will do with this information. Maybe nothing, as my program handles the input polling, puts every new incoming event onto a stack of 32 and sends them to the USB host with some delay in between.