Rockbox mail archiveSubject: Re: Testers wanted: up to 50% greater battery life
Re: Testers wanted: up to 50% greater battery life
From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Tue, 29 Jul 2003 13:42:01 -0400
> > 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
> > 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
> > 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
> > 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!Received on 2003-07-29