I'm all for simple <grin>... But I am still curious. I guess I'll need
to buy a IIIc and take it apart. I worked on some high end industrial
instrumentation awhile back that used similar display technology.
I did try a quick hack with POSE. I made the reported voltage
adjustable and watched for accesses to the display related hardware.
Nothing. I did expect the display to be dimmed as the power went
down... Maybe in a future version <bigger grin>... It does save a ton
of juice.
Regards,
-jjf
-----Original Message-----
From: Bob Ebert [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 23, 2000 6:14 AM
To: Palm Developer Forum
Cc: Palm Developer Forum
Subject: RE: CPU Throttle in OS 3.5?
At 11:48 PM +0100 22-03-00, Fitzpatrick, Joe wrote:
>I haven't looked at the ROM, but it sounds more like the
charge/transfer
>rate of the color display. I've deleted the original post, does the
>problem occur suddenly, at a particular power level, or does it get
>progressively worse over a range of power levels?
>
>If it is the former, I'd bet that there is a power conservation gimmick
>in the ROM for the color display. If it is the later, I'd look at the
>display hardware config itself. Presumably, any program that lists
>"frame rate" is pushing the display harder than the typical Palm app...
><grin>
Just so you know, we didn't play any tricks like this in software to try
to
conserve power. We talked about doing things like dimming the display
as
the batteries drained, but we did not do this.
The KISS philosophy is in play here... you drain batteries at whatever
rate
they drain until they're dead, then the device won't come on any more.
:-)
When your batteries get low, you'll start seeing low battery dialogs.
When
they get too low, you'll get more strenuous warnings. When they go
below a
certain threshold, the hardware won't allow the device to wake up any
more.
Once the device hits the 'don't power on' threshold, you've got at least
a
week and probably a lot longer to get the thing into a charger. I
forget
what the actual interval is, but it's a pretty long time on the IIIc,
because once the display is off there's plenty of juice left to keep RAM
alive.
If you try to reset the device to bring it back in this state, it will
wake
up, but only for a moment... then it will go back to the won't power on
state. Each time you reset like this, you drain the batteries a little
more, and this will cut into your keep-alive time.
Regarding this bizarre problem:
We've seen stuff like this before. One app looked like it ran twice as
fast when exposed to bright flourescent light! It turned out that the
app
was assuming that when it called EvtGetEvent with an idle interval, that
no
event would be generated until the interval had passed. In reality, the
bright light was causing some IR related events to occur, which kept the
event loop spinning and effectively disabled the delay timers for that
app!
The fix there is to stop assuming that a nilEvent will occur only when
you
want it to. The system can generate it's own nilEvents. So you've got
to
check the clock in addition to waiting. That is, the timeout passed to
EvtGetEvent is the *longest* time to wait, not necessarily the exact
time
to wait. This is old hat to anyone who's been reading the forum for a
while.
Perhaps it's something similar here. Since this problem is only
occurring
with a particular app, it's possible that something weird is going on
with
events that's causing the thing to slow down. Maybe it's related to a
battery test event?
This will be a little bit hard to debug, because you can't reproduce it
in
the Simulator or on Poser. One trick to try would be to put something
in
the main event loop that plays a sound. Then you can listen to the
thing
click every time an event is processed, and you'll hear changes in the
frequency of event processing.
I'm still really curious!
--Bob
________________________________________________________________________
Bob Ebert, Consulting Engineer, Palm Computing Europe V: +33 4 9952.4354
77 rue Samuel Morse, 34935 Montpellier Cedex 9 France F: +33 4 9952.4397
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
