Main > Main Forum

I-PAC / Keyboard Encoder polling rate?

<< < (4/6) > >>

RandyT:
(continued)

Microcontrollers have things called "hardware interrupts".  These are usually useful features built in that can be enabled/disabled by the user code.  On the particular microcontroller talked about so much, there are a few of interest.  There are 2 time based HW interrupts, one that occurs every 128us (that's millionths of a second) and one that occurs every 1.024ms(thousandths of a second).  Come hell or high water :) any code pointed to by those start to execute at those intervals, within the restraints of the above.  If you have code to evaluate the states of the pins on a microcontroller that executes at these intervals, this is really no different than "polling".  The difference is that they will ALWAYS be polled at those intervals.

The thing that is interesting to note here is the following comparison:

A scheme that uses an interrupt to check the state of the ports at 1ms intervals, sees what is going on there at 1000 times per second, very regularly.

However, a scheme that uses a loop to scan the port at irregular intervals 2000 times a second is still going to be close to twice as fast/accurate :)


There is also one other interesting hardware interrupt available on the microcontroller in question.  This one is the "General Purpose Input/Output Interrupt".  This one is capable of generating an interrupt when ANY of the 32 I/O pins change state.  The important thing to note here is that the microcontroller DOES NOT generate a seperate interrupt for each and every pin, and therefore can't tell the user code which pin (input) generated the interrupt.  It is now the responsibility of the user code executed by this interrupt to "poll" the pins individually and decide what has changed.  At this point, well written code will examine (poll) ALL inputs and act on the changes appropriately.  During this time, no other inputs can generate a GPIO interrupt but the time a well-written piece of code will spend here is so small, it is unimportant.

(continued on next->)

RandyT:
(continued)

Also, for the sake of the "big picture", it is important to note that the interrupt for polling the inputs needs to be turned off when the processor is performing a time critical task like transmitting to or receiving from the computer (or any external device which may also be connected to the controller, such as keyboards, mice, etc.)  During this time, it is highly likely that no transitions of the I/O port would be sensed regardless of the means used to check them.


Here is another interesting comparison:

Using a GPIO interrupt, unless in "transmit", "receive" or some other "state", the microcontroller will immediately "poll" the pins to see which one (or more) of them changed state and generated the interrupt.

Using a fast-polling method, also unless in "transmit", "receive" or some other "state", the "main loop" of the code will be constantly and      very, very quickly (perhaps thousands of times per second) polling the pins to see if something has changed.

So using this example, one can see that the use of interrupts (or the lack thereof) doesn't have as large an effect on performance as limiting the amount of time spent by the microcontroller in alternate "states" where it is unable to monitor the pins.  In other words, the more time-critical functions being handled by the microcontroller, the less time it can look at the pins, as it can always only do one timing-critical thing at a time.


So to summarize, "polling" of individual input pins takes place regardless of whether the routines are executed by result of an interrupt or by a constant loop outside of one.  If a microcontroller does little outside of polling the pins when not in an interrupt service routine, the increase in performance realized will be very small, if any.  In fact, any of the methods written here will probably be able to monitor far more transitions than are humanly possible.


If anyone has any corrections, questions, or needs further elaboration on anything I have written here, you know the drill :).

RandyT



BTW, for anyone who might be interested, the max throughput of the PS/2 interface is over 1500 characters per second.  More than fast enough to keep up with just about any type of controls you could dream of throwing at it, regardless of the I/O monitoring scheme.


TheManuel:

--- Quote from: AndyWarne on June 01, 2003, 05:52:02 am ---This is a big issue with fighing games and about a year ago, a regular on this board looked at this extensively and did some testing which revealed some deficiencies in some encoders, although newer arrivals probably don't have this problem.

--- End quote ---

Is this newer IPac arrivals or newer encoder arrivals?

TheManuel:

--- Quote from: AndyWarne on June 01, 2003, 05:52:02 am ---Back at the encoder side, another issue is de-bounce. There needs to be a limit on how quickly sucessive presses of the SAME key are sent. So after pressing a key, we send it but if we get any activity on that key for 30 milliseconds we ignore it. Otherwise we would have multiple key repeats all over the place owing to switch bounce.

--- End quote ---

I insist.
Why should the 30 milliseconds restriction should be a problem for gamers?
If you can make successive presses (even for a few) within 30ms, that is a rate of 33 presses per secons.
Who the hell can do this?

Pulsewidth:
On Linux, it is possible to set the USB mouse polling rate, and almost all mice can work with 500Hz polling.  There's no official support for increased polling speed of other HID devices (and I assume the I-PAC is a standard HID device), but with a simple modification to drivers/usb/input/hid-core.c you can increase the polling rate for those too.  I poll my USB keyboard at 250Hz and it works perfectly, but I haven't tested other keyboards, and it's likely that it won't work with all devices.  I assume an analogous hack exists for Windows too.

Will the I-PAC work with USB polling speeds faster than the default 100Hz?

Also, is it possible to tune the debounce time, preferably with different debounce on different inputs?  30ms could be a problem when you need to tap a button for an extremely short time, as it will register as held down for at least one frame longer than it should.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version