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.
Posting an event is not an option -- the code is executing at
interrupt time. The event queue is not going to run until after the
device wakes up again. Don't bother posting your key until the wake
routine, since you can't assume that any code will run in response to
it in your EvtGetEvent() hook (before the device shuts off).
The bottom line is that the sleep routine (for libraries) is provided
ONLY for libraries that are (directly or indirectly) talking to
hardware. Typically this means that they should turn off whatever
hardware is on, and typically that should be accomplished by whacking
some power-enable bit (a few lines of code at most).
Hope this clears things up...
--Steve
