From: Michael Sevakis <jethead71_at_comcast.net>
Date: Thu, 8 Mar 2012 12:52:12 -0500

> Tick tasks are run from ISR. There is absolutely no need to read keys
> in ISR IMO, reading in ISR gives no benefits in this case.

As far as I can see, there's no reason at all to poll keys all the time
except in the sense of generating consistent repeat behavior, which means
the button tick is only needed when a key is pressed. ISR should be the
defacto method. It's also lower in overhead and can consistently capture
input into the queue.

Gigabeat S employs a mismash of PMU key reading for the power button in ISR,
GPIO polling for the hold/battery switch and a special thread for the remote
(at a max rate of 20Hz). In the last case, it's not strictly necessary but
it involves the ADC and that code would have to become asynchronously
queueable to work without a thread (maybe I'll give it a spin if I'm bored
enough). I can't say it's quite as nice and crisp as standard key scanning
in ISR. Some things were done before async drivers to just get them working
initially.

So, two SoCs that may interest anyone in async techniques would be AS3525
and i.MX31.

> Changing the behavior for only one target while there are no technical
> barriers to do this consistently on all targets is a hack in my
> nomenclature.

Why does it matter? Any number of methods should be available to adapt to
the what the hardware is capable of, the willingness of the developer to
bend over backwards to do something or the desired performance.

Mike
Received on 2012-03-08