Rockbox mail archiveSubject: Re: Use SLEEP instruction for longer (?) runtime
Re: Use SLEEP instruction for longer (?) runtime
From: Andrew Jamieson <andrew.jamieson_at_projectlab.net>
Date: Wed, 22 Jan 2003 09:29:50 +1100
If you can get me a compiled AJB version, I can create an extended data
table of current consumption over an arbitary period of time (~ 3 samples
per second), or graph it really acurately over a shorter period of time
(with a DSO).
----- Original Message -----
From: "Simon ElÚn" <simel346_at_student.liu.se>
Sent: Wednesday, January 22, 2003 8:40 AM
Subject: Re: Use SLEEP instruction for longer (?) runtime
> Bj÷rn Stenberg wrote:
> > Yeah, I was curious about your choice of method. We have discussed
> > this method previously, but rejected it since so very little time (a
> > fraction of a tick) is actually spent sleeping.
> True, but not very much is done before it goes to sleep again. Also, when
> playing it still needs to wake up every 1ms to poll the MAS, right?
> > We didn't think it
> > would make any noticeable difference on power use. Have you made any
> > measurements?
> Since I've just made the patch, I haven't been able to check the runtime
> yet. I was hoping someone would have a more exact way of checking it,
> runtime varies by at least an hour depending on the bitrate of the MP3:s I
> Try compiling with USE_LED_FOR_CPU_BUSY #defined. This is probably a
> inaccurate way of checking, but it was the best debugging aid I could come
> up with. I just tried inverting it to make it light up when sleeping
> of when busy, and it is generally brighter this way. This should at least
> indicate that the CPU is sleeping more than half of the time, which should
> already have some impact on the power consumption. I welcome any better
> ideas for checking this without opening the Archos.
> > The more efficient, but also more difficult, solution is to rewrite
> > the scheduler to use a sorted sleep queue with a timeout for each
> > thread and a wakeup timer interrupt. That way we can sleep for farily
> > long periods of time. (At least on Recorder.)
> And at least while not playing, unless we can successfully guess when the
> MAS will want more data sent to it.
> Simon ElÚn
Received on 2003-01-21