At 5:15 PM -0700 6/17/99, Steve Lemke wrote:
>At 4:39 PM -0700 6/17/99, Jeff Ishaq wrote:
>>I've heard a few different things from Palm in the past on dilly-dallying
>>around in a shared library's sleep()/wake() entry point. The thesis is this
>>-- because they can be called from within an interrupt service provider
>>(ISP), you really shouldn't spend much time at all in either of them. If
>>you have a lot of stuff that needs to happen, post a key event and get out.
>>Then catch that key event in an EvtGetEvent() hook shortly, where you can
>>take your time doing whatever you need to do.
>>
>>I've had to debug code that crashed because it spent too much time here.
>>I've also gotten away with doing quite a bit in these functions before I saw
>>any trouble.
>>
>>Has anyone ever heard any numbers from Palm on this? Like, don't spend more
>>than 12 ms in the routine?
>>
>>Thanks,
>>-jeff ishaq
>>The Windward Group
>
>The MAIN issue here is the sleep routine. If the user removes the
>batteries from the device, the processor will be running off of the
>power in the supercap. The supercap is supposed to retain enough
>power to keep the memory alive until new batteries are inserted.
>The more code that executes in response to the batteries being
>removed, the less power there is to keep the memory alive. The name
>of the game is to shut the device down ASAP.
>
>12 ms is unacceptable. The entire device should be completely
>asleep in less than 1ms. In fact, there really isn't much more than
>1ms' worth of power available in the supercap.
Let me clarify this a bit... There is probably over a minute's worth
of power in the supercap if the hardware is asleep and the only thing
drawing power is the memory (in self-refresh mode).
However, if the hardware is active (CPU running, display on, etc.)
then the supercap won't keep it running for more than a few ms.
--Steve
