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
