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



Donate

Rockbox mail archive

Subject: Re: Testers wanted: up to 50% greater battery life
From: TP Diffenbach (rockbox_at_diffenbach.org)
Date: 2003-07-29

Quoting idc-dragon_at_gmx.de:

> > The magic is pretty simple: the wps thread does more mork than we want.
>
> This does have such a dramatic effect? Whoa! Did you measure the current?

For 13 hours and then 9 hours, and then 5 hours and then 6 hours I periodically when to Debug View Battery and read the voltage and typed it into my pda. My pda's spreadsheet sodftware (Hancom Sheet) is a bit buggy: entering or calculating invalid values (such as a time >= 1 (time is a fraction)) caused it to abend, so I initialy lost a bunch of data points.

> > The first cut battery extension just suspends scolling (without destroying
> > the scroll infomation already calculated) and blocks the wps thread by
> > waiting for keyboard input, after the backlight timeout has elapsed.
>
> > The second cut will restore scrolling and screen updates, but defer
> > settings savings.
>
> You may exploit partial screen update instead of the full thing, if not
> already done.

I suspect that if we're going to update, we should just update.

> > A good compromise might be to save only that information that really can
> > change, and save it (or as much as possible) to the RTC memory, if in fact
> > saving to the RTC memory is faster.
>
> Please bear in mind that not all models have RTC. (The players)

Yeah, I know.

 
> > Another compromise would be to defer
> > saving settings (perhaps in another thread for code cleanliness) to
> something
> > like once a minute. Another would be to save changes on power down.
>
> For RTC setting, this is the way to go, I think (save on power down). Do we
> get the stop button first? In that case, we can save it on stop.

That's a problem. There's a hardware off, so in some cases we'd be racing against that deadline.

> > Each possibility has tradeoffs in terms of work done versus loss of
> > settings changes in the case of power down. I'm willing to lose the last
> minute
> > of volume changes and track offset for 50% more battery.
>
> Please not the track position, this would render resume useless.

If being off by a minute really perturbs you, you could turn this power-saving off. But I think saving to the RTC (unless that's really expensive) should suffice ofr Recorders and FMs. Or just go through software shutdown. You'll have to pay somewhere, and I expect lonbger batery life will win over quick shutdown for most people.

> > A related problem is that the wps thread is responsible for polling the
> > mpeg thread for track changes, and updating directory information. I'd
> rather
> > have the mpeg thread take care of this, as it's not really related to
> > /display/ issues, and the mpeg thread, I think, wouldn't have to poll.
>
> Yeah, send a message from the mpeg thread to the wps or so.

The wps doesn't need to care at all. Let the mpeg thread update the structure, employing a mutex, and let the wps thread just display whatever's writtem

> > Thought and comments on the above are of course invited.
>
> I just tried. ;-)

And thank you! 

-- 
Archos FM has a Rockbox!

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