NXT Firmware Runloop behavior

[tcwan]

Hi,

I'm trying to understand the NXT Firmware Runloop mSchedCtrl() behavior, with regards to timing issues.
Upon booting the NXT, a press and continuous hold on the Arrow buttons would generate approximately four events (click sound playbacks) per second (counted using my watch), where the menu items would scroll based on the arrow direction.

If the NXT firmware were halted and control switched to an alternative runloop (which happens when I'm running the NXT debugger ) for a period of time, where only the cCommCtrl() module is called; when I resume execution to the normal NXT runloop, pressing and holding the Arrow button continuously would generate clicks at a much faster rate (> 10 events/sec), but eventually start to slow down and return to the 4 events/sec rate after 10-20 seconds.

I'm wondering if there is a event-timer token bucket which controls the rate of keypress repeats that is serviced (i.e., a timer generates tokens, and as long as tokens are available, the keypress repeat routine generates the key press event).

Are there other cXXXCtrl() modules that should be serviced from my runloop?

In addition, should I limit the rate at which that cCommCtrl() is called? Currently my runloop does not sleep or implement any waits, so it would invoke cCommCtrl() repeatedly if no user input or processing is required.