Counting milliseconds on PPC

  • Thread starter Thread starter Thomas Taylor
  • Start date Start date
T

Thomas Taylor

Is there a good way to (reliably) retrieve time on Pocket PC with resolution
of milliseconds?

I am implementing a stopwatch using the CF, and I have tried the following:

(1) System.DateTime.Now and GetSystemTime (in coredll.dll)
These always return zero for milliseconds.

(2) System.Environment.TickCount and GetTickCount (in coredll.dll)
These give milliseconds, but API documentation indicates that they are
accurate only to within 0.5 sec. Also, counting stops when the device is
turned off, which is unacceptable for my application.

(3) QueryPerformanceCounter (in coredll.dll)
Implementation of this one is OEM-specific, and it appears to me that most
manufacturers are not implementing it.

Any advice will be appreciated.
 
2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on our
devices, the resolution is 1ms and the accuracy is pretty good, unless a
misbehaving driver has been installed and is disabling the timer interrupt
for long periods of time.

If you're going to have to keep counting when the device is off, I think
you're *completely* out of luck. Why would a Pocket PC device want to use
battery, even when off, to count something that 99.99% of all people care
nothing about? You'd need special hardware to maintain the count while the
power was off, battery-backed hardware.

Paul T.
 
So you're after a ms resolution stopwatch that will track periods of time
long enough for the device to go to sleep? Even if the device supported it
(and it doesn't without a bit of hacking at best), then consider the fact
that the processor clock itself will have drift of up to several seconds per
day or more, which adds an error factor making milliseconds not terribly
significant.

Basically you're trying to use a screwdriver where a wrench is required.
What you need is a separate circuit, most likely a ms-resolution RTC that is
battery backed. Then you need some sort of interface bus to it, like a
serial connection.

A quick search shows that a DS87C530 would probably fit the bill quite
nicely, and it's I2C, so the communication could be cobbled together even
using the control lines of a standard serial port (an ugly hack, but
workable).

At any rate, an off the shelf Pocket PC isn't going to get you where you
need to be. Sorry.
 
Thanks Paul, I looked back at the documentation, and the point about
0.5-second accuracy comes from the Framework documentation for
System.Environment.TickCount
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html
/frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
resolution of the TickCount property cannot be less than 500 milliseconds."
Perhaps this is a fudge factor for the managed environment to get the count?

The practical reason for needing to keep counting when the device is off is
that users may want to time events that last longer than their auto-suspend
time. One could easily start the stopwatch and have the device turn itself
off in the middle of the event.

From a programming standpoint, I would not really need it to keep counting
while it is off if, for example, I could save the start time (e.g., if
DateTime.Now gave milliseconds) and then compute the elapsed time any time
later, including after the device had been turned off and back on.

Thomas
 
GetTickCount shouldn't suffer from that. As Chris indicated, only some sort
of external, battery-operated timer, is going to run when the device is
'off'.

Paul T.
 
Wait, wait... The RTC in PPC devices still runs when it's powered off. You
don't have to set your clock every time you hit a power button, do you?
While this is not necessarily so in the generic CE devices, creating a
stopwatch out of PPC is a feasible idea. With the caveat described by Chris
(accuracy), you can have a stopwatch functionality. Nobody needs the device
actually counting milliseconds between power-off and subsequent power-on.
All he needs is to be able to tell upon resume that so many seconds have
passed since the "Start" button in his application has been pressed. Now, if
he needs to be able to to something when a time interval has elapsed and the
device may be powered down at that point, then there is trouble since
CeRunAppAtTime accuracy is way lower than it is acceptable for a stopwatch.

So I'd go with GetTickCount - should work IMO
 
Not accurate to ms, though (most RTC clock chips aren't).

Paul T.

Alex Feinman said:
Wait, wait... The RTC in PPC devices still runs when it's powered off. You
don't have to set your clock every time you hit a power button, do you?
While this is not necessarily so in the generic CE devices, creating a
stopwatch out of PPC is a feasible idea. With the caveat described by
Chris (accuracy), you can have a stopwatch functionality. Nobody needs the
device actually counting milliseconds between power-off and subsequent
power-on. All he needs is to be able to tell upon resume that so many
seconds have passed since the "Start" button in his application has been
pressed. Now, if he needs to be able to to something when a time interval
has elapsed and the device may be powered down at that point, then there
is trouble since CeRunAppAtTime accuracy is way lower than it is
acceptable for a stopwatch.

So I'd go with GetTickCount - should work IMO

--
Alex Feinman
---
Visit http://www.opennetcf.org
Paul G. Tobey said:
GetTickCount shouldn't suffer from that. As Chris indicated, only some
sort of external, battery-operated timer, is going to run when the device
is 'off'.

Paul T.

Thomas Taylor said:
Thanks Paul, I looked back at the documentation, and the point about
0.5-second accuracy comes from the Framework documentation for
System.Environment.TickCount
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html
/frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
resolution of the TickCount property cannot be less than 500
milliseconds."
Perhaps this is a fudge factor for the managed environment to get the
count?

The practical reason for needing to keep counting when the device is off
is
that users may want to time events that last longer than their
auto-suspend
time. One could easily start the stopwatch and have the device turn
itself
off in the middle of the event.

From a programming standpoint, I would not really need it to keep
counting
while it is off if, for example, I could save the start time (e.g., if
DateTime.Now gave milliseconds) and then compute the elapsed time any
time
later, including after the device had been turned off and back on.

Thomas

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
our
devices, the resolution is 1ms and the accuracy is pretty good, unless
a
misbehaving driver has been installed and is disabling the timer
interrupt
for long periods of time.

If you're going to have to keep counting when the device is off, I
think
you're *completely* out of luck. Why would a Pocket PC device want to
use
battery, even when off, to count something that 99.99% of all people
care
nothing about? You'd need special hardware to maintain the count while
the
power was off, battery-backed hardware.

Paul T.
Click to expand...
Click to expand...
Click to expand...
 
No, it is not, but do you think the OP really needs msecs? I mean if you
have to use your finger to press start/stop button, what do you care about a
few hundred msec anyway?

--
Alex Feinman
---
Visit http://www.opennetcf.org
Paul G. Tobey said:
Not accurate to ms, though (most RTC clock chips aren't).

Paul T.

Alex Feinman said:
Wait, wait... The RTC in PPC devices still runs when it's powered off.
You don't have to set your clock every time you hit a power button, do
you? While this is not necessarily so in the generic CE devices, creating
a stopwatch out of PPC is a feasible idea. With the caveat described by
Chris (accuracy), you can have a stopwatch functionality. Nobody needs
the device actually counting milliseconds between power-off and
subsequent power-on. All he needs is to be able to tell upon resume that
so many seconds have passed since the "Start" button in his application
has been pressed. Now, if he needs to be able to to something when a time
interval has elapsed and the device may be powered down at that point,
then there is trouble since CeRunAppAtTime accuracy is way lower than it
is acceptable for a stopwatch.

So I'd go with GetTickCount - should work IMO

--
Alex Feinman
---
Visit http://www.opennetcf.org
Paul G. Tobey said:
GetTickCount shouldn't suffer from that. As Chris indicated, only some
sort of external, battery-operated timer, is going to run when the
device is 'off'.

Paul T.

Thanks Paul, I looked back at the documentation, and the point about
0.5-second accuracy comes from the Framework documentation for
System.Environment.TickCount
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html
/frlrfsystemenvironmentclasstickcounttopic.asp), which states "The
resolution of the TickCount property cannot be less than 500
milliseconds."
Perhaps this is a fudge factor for the managed environment to get the
count?

The practical reason for needing to keep counting when the device is
off is
that users may want to time events that last longer than their
auto-suspend
time. One could easily start the stopwatch and have the device turn
itself
off in the middle of the event.

From a programming standpoint, I would not really need it to keep
counting
while it is off if, for example, I could save the start time (e.g., if
DateTime.Now gave milliseconds) and then compute the elapsed time any
time
later, including after the device had been turned off and back on.

Thomas

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com>
wrote in message 2) I don't see anywhere that the accuracy is only 0.5s. Certainly, on
our
devices, the resolution is 1ms and the accuracy is pretty good, unless
a
misbehaving driver has been installed and is disabling the timer
interrupt
for long periods of time.

If you're going to have to keep counting when the device is off, I
think
you're *completely* out of luck. Why would a Pocket PC device want to
use
battery, even when off, to count something that 99.99% of all people
care
nothing about? You'd need special hardware to maintain the count
while
the
power was off, battery-backed hardware.

Paul T.
Click to expand...
Click to expand...
Click to expand...
 
Thanks Chris, Alex, and Paul. Your responses help a bunch, especially in
confirming that I was not missing something in the OS. Now I just have to
decide whether to try to bend that screwdriver into the shape of a wrench.

Thanks again,
Thomas Taylor

p.s., Great work at http://www.opennetcf.org.
 
Back
Top