|
Rockbox mail archiveSubject: Re: Classic holdswitch pollingRe: Classic holdswitch polling
From: Michael Sparmann <theseven_at_gmx.net>
Date: Thu, 08 Mar 2012 22:01:39 +0100 >> 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. Please note that we're actually talking about reading the hold switch status here. The actual key reading is IRQ-driven, IIRC pushing down raw clickwheel data packets to a clickwheel/button handler thread. Reading actual key presses/wheel positions doesn't involve I2C at all. Reading the hold switch is not all that critical because it physically shuts down the clickwheel hardware. I think it's only neccessary to control the backlight and lock icon, and possibly to reset the clickwheel after the hold switch is turned off. Currently it's done from a tick task, and that's somewhat likely to clash with another, already ongoing, I2C access, e.g. to the codec. I fail to see how an async I2C driver could resolve that clash from IRQ mode. The least invasive way to fix this bug would probably be to figure out if I2C is already in use when trying to read the hold switch in the tick task, and if it is just skip updating the hold switch status for that tick.
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |