Real time inputs

  • Thread starter Thread starter Rob Perkins
  • Start date Start date
R

Rob Perkins

Hi,

I've been asked to consider writing a program which measures an elapsed
time based on eight physical inputs, (basically a start time sensor and
a stop time sensor) to half-millisecond precision. Yes, it's a racetrack
timer.

I'm left wondering if Windows can even do that accurately, given the way
it processes interrupts from hardware, or whether the event driven
architecture of the OS will get in the way of that kind of precision?

If not, I guess that it might require me to build or buy some timer
circuits which kept the time and asserted a flag to Windows when all the
"stop" inputs were reached. That's actually the "easy part" for me.

Rob
 
You could try running the program in windows in "realtime" priority, or use a realtime OS such as QNX.
 
Mike said:
You could try running the program in windows in "realtime" priority, or use a realtime OS such as QNX.

Well, QNX is right out, because Windows XP is on the specification.

I thought about the "realtime" priority thing, which in my experience
has always introduced massive strangenesses into how Windows works.
Certainly if the program could assert that priority only for the
duration of the time, then it would be acceptable, and useful for things
like drag races, where there aren't any laps. But for elapsed time
displays while a race is underway on a rounder track, not so much.

And even then, I don't know if I trust the clocks on a PC to keep
accurate time at that resolution, though that sort of thing is certainly
necessary for bridge bus timing.

I guess I'm still thinking about it.

Rob
 
Hi,

I've been asked to consider writing a program which measures an elapsed
time based on eight physical inputs, (basically a start time sensor and
a stop time sensor) to half-millisecond precision. Yes, it's a racetrack
timer.

I'm left wondering if Windows can even do that accurately, given the way
it processes interrupts from hardware, or whether the event driven
architecture of the OS will get in the way of that kind of precision?

If not, I guess that it might require me to build or buy some timer
circuits which kept the time and asserted a flag to Windows when all the
"stop" inputs were reached. That's actually the "easy part" for me.

Why not do it properly and just read the times from the clock box
instead of trying to implement something that can't be certified. Many
clock solutions can be certified and work well, all you have to do is
use a serial port to communicate with them.

Trying to do it in Windows, or even QNX, is not the path to take, buy a
clock module with a serial interface - it should even had a LCD/LED
display on it to confirm your program.
 
Leythos said:
Why not do it properly and just read the times from the clock box
instead of trying to implement something that can't be certified. Many
clock solutions can be certified and work well, all you have to do is
use a serial port to communicate with them.

That might be a way to go. Frankly reprioritizing threads under Windows
doesn't make me happy.

Any links to sites where I might make a study of the various clock boxes?

Rob
 
Back
Top