It's all working. I'm using
EvtGetEvent(&event, TimeUntilNextPeriod());
if (TimeUntilNextPeriod() == 0)
{
//do the do!
if (doRequests) RequestAllData();
UpdateStatus();
//Check for DB record write?
//update screen etc.
}
with my function looking like this:
static Long TimeUntilNextPeriod (void)
{
Long timeRemaining;
//Should I use this?
// if (/*what*/)
// return evtWaitForever;
timeRemaining = nextTimeInterval - TimGetTicks();
if (timeRemaining < 0)
timeRemaining = 0;
return timeRemaining;
}
void UpdateStatus(void)
{
ULong currentTime;
CharPtr message=MemPtrNew(16);
// The time between the last advance and the next is constant
nextTimeInterval = nextTimeInterval + advanceTimeInterval;
// If needs be resynch the period timer.
currentTime = TimGetTicks();
if ((Long) nextTimeInterval - currentTime <= 0)
{
nextTimeInterval = currentTime + advanceTimeInterval;
UpdateField(requestStatusField,"synching..");
}
}
and the RequestAllData is responsible for sending the requests, and dealing
with the replies. It's going every 2 seconds exactly, and I've set the value
for advanceTimeInterval in StartApplication() using
advanceTimeInterval=SysTicksPerSecond()*REQUESTRATE; where REQUESTRATE is
just defined as 2.
Any comments on the speed/power consumption issues. Would it be better to
use a API call that deals in seconds rather than ticks?
Look forward to hearing from you all!
Stuart Norton
-----Original Message-----
From: Jim Schram [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 15, 1999 12:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Automated serial output
At 3:33 PM -0400 1999/07/14, Dave Lippincott wrote:
>If you do it this way, you will have to intercept *every* message generated
>by the OS. That will suck up allot of CPU time. Just look for the
nilEvent
>message. When it is received, check the tick count or clock. If you set
>the EvtGetEvent timeout to some rate that is at least twice the required
>frequency, you will almost certainly get the desired timing period.
No, check the tick count at every event if you need to guarantee a specific
frequency. You'll burn more cycles halving the timeout frequency than you
will performing a simple "is it time now?" check on every received event.
A side effect of checking only during nil events is that the user may be
entering data or tapping the screen quickly, enqueueing each event within
the timeout frequency, thus starving your event loop of nil events.
Regards,
Jim Schram
3Com/Palm Computing
Partner Engineering
