>-----Original Message-----
>From: Steve Lemke [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, June 17, 1999 5:15 PM
>To: [EMAIL PROTECTED]
>Subject: Re: How long can I spend in MyLibSleep()? Exactly?
>>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.
Yes, that's also true. On battpull, everything has to go bye-bye, stat.
>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.
Prove it! :) Not to sound belligerent at all - I'm asking because I'm
writing an article on shared libraries, and I'd love to have some cool
factoids on this issue. Nobody is able to give me actual numbers. I'm not
much of a hardware guy, or I'd dig them up myself. How big is the supercap?
Is there enough information to tell precisely how many instructions we can
execute when we're running from the supercap? Maybe a good approximation?
Does the size of the supercap differ from a Palm V and a Palm VII?
>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).
You're right. In my experience, even if you post an event in sleep(), you
won't see it upon waking. I know the queue is cleared before your sleep()
is called, but I was never able to see my key even after the device woke
back up. It just went away.
>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).
This is exactly why I used sleep() last time I was working with shared
libraries. We spent a bit more time than we should have in there, but it
seemed to work ok anyway, even during battpull tests. But man, you're
better safe than sorry with this one. I'd hate to field the tech support
calls from customers who lost all of their data because of a poorly-handled
lowbat or battpull situation!
>Hope this clears things up...
Yeah, it's become clear to me that the only thing you're safe doing in
sleep() is setting one or two variables somewhere. But I'm still not clear
exactly how many you can do before you'll run into problems, which was my
primary question.
Thanks for your input, Steve!
-Jeff Ishaq
The Windward Group
