Nick,
Yes, the approach you suggest works and that's what I'm doing at the moment.
There are some drawbacks:
a) it takes ~1 second to synchronise after coming out of sleep mode, so
during this period there is loss of accuracy.
b) I have a concern that that the synchronisation algorithm may be upset if
pre-emption occurs at a critical point, i.e. during rollover detection. As
far as I can tell this is not a problem, but if it may occur very
infrequently. If I knew how to do it, I would disable interrupts during this
section.
Dave
-----Original Message-----
From: Nick Hammond [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 11, 2000 12:25 PM
To: [EMAIL PROTECTED]
Subject: RE: getting accurate elapsed time
David,
Off the top of my head, how about periodically checking the synchronisation
of the tick counter by watching for the seconds counter to rollover to the
next value and noting both seconds and ticks?
If these stay in step (i.e. if ticks increment by sysTicksPerSecond while
seconds increment by 1) then the device has not been in sleep mode since the
previous check and accurate time intervals can be calculated from seconds
and ticks. If they don't then a correction for the tick counter can be
calculated, still allowing accurate times
For example, with the following measurements:
s1, t1 at the seconds rollover immediately prior to the measurement
sx, tx at the start event
<device may go to sleep during this period>
sy, ty at the end event
s2, t2 at the seconds rollover immediately following the measurement
then (ignoring complications like overflow):
correction = (t1 - t2) % sysTicksPerSecond;
startTime = sx * sysTicksPerSecond + (tx - t1) % sysTicksPerSecond;
stopTime = sy * sysTicksPerSecond + (ty - t1 + correction) %
sysTicksPerSecond;
duration = (sy - sx) * sysTicksPerSecond + (ty - tx + correction) %
sysTicksPerSecond;
Regards, Nick
-----Original Message-----
From: David Maclay [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 8 January 2000 2:42
To: '[EMAIL PROTECTED]'
Subject: getting accurate elapsed time
The palm SDK describes the functions TimGetTicks and TimGetSeconds.
The former has a resolution of 1/100 second, however, it only increments
when the device is not in sleep mode.
TimGetSeconds has a resolution of 1 second, although I've done some tests
and the underlying accuracy appears to be better than 1 second - even when
the device has been in sleep mode.
My question is, how can I get accuracy AND resolution better than 1/10
second. Are there any undocumented calls to look at a counter on the CPU?
I'd appreciate any advice on this.
Thanks,
Dave Maclay
