Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Classic holdswitch polling

Re: Classic holdswitch polling

From: Cástor Muñoz <cmvidal_at_gmail.com>
Date: Sat, 10 Mar 2012 23:30:27 +0100

On Sat, Mar 10, 2012 at 10:37 PM, Michael Sevakis <jethead71_at_comcast.net> wrote:
>> 2) Async I2C: i will look at this code ASAP, seems it could be
>> implemented as a generic driver for all targets that HAVE_I2C_STACK?,
>> will it work for the holdswitch polling?
>>
>
> Not so bad really. No mutexes required. Just a quick interrupt disable to
> protect a linked list. Synchronous stuff can just init and wait on a
> semaphore. Additional complexity is minor and complex read/write cycles can
> be synthesized and be atomic against both threads and interrupts.
>
>
>> 3) Create a specific thread for Classic: other targets are using this
>> method, to factorize code a generic target thread (?) could be added,
>> all targets defining HAVE_TARGET_THREAD can use it to register some
>> specific tasks, and continue using the tick IRQ handler for other
>> tasks.
>>
>
> I don't own one and so long as it's not in the way of anything I do.
>
>
>> 4) Create a new button thread for all targets: should this option
>> include other input methods? (clickwheel, touchscreen, remotes...),
>> maybe some actions actually done on the target drivers should be moved
>> to a more generic input thread.
>
>
> No way I'll accept that and it would suck with scrollwheels. De-threading
> things if possible is better. Most have no need for this whatsoever. Thread
> structures are in IRAM on some targets (which helps keep scheduler overhead
> down significantly) and in many cases it is already pretty tight there.

Another way is to join options 2) and 3), then Rockbox 'core' will
offer other standard facilities (HAVE_I2C_QUEUE, HAVE_TARGET_THREAD)
in addition to the tick handler, each target can choose to use them or
not, after all there are some targets using it actually. No overhead
for the current targets that choose not to use these facilities, but
could be useful for future new targets or functionally, for example
suppose we need to poll PMU to know dock status or other info.
Received on 2012-03-10


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa