The IBM PC has a interval timer that is programmable to (and don't quote me
on this) to 65,000 interrupts/second. This is the interrupt generator that
generates the interrupts which Windows/DOS only worry about every
18milliseconds. I've written code to generate interrupts every 4000 seconds
on a 16Mhz 286 machine that seems to very reproducible times to .01 seconds
when processing interrupts from timing equipment via the serial port. I
don't have any test equipment to very anything faster.
Steve
----- Original Message -----
From: Paul Foster <pfoster@gdi.net>
To: team.net <autox@autox.team.net>; <dennis@raceamerica.com>
Sent: Wednesday, September 29, 1999 11:39 AM
Subject: Re: Autocross Timing/Scoring Software
> Dennis Laczny of RACEAMERICA Timing Systems states:
>
> <<<John's point of having to reset the PC time-of-day is right on. A PC
> is
> driven by an interrupt system and the I/O ports where sensors are
> connected
> and the internal time-of-day clock are the lowest priorities due to the
> slow data rates (compared to what is going on inside the PC at 200Mhz +)
> and this lower priority causes the time-of-day clock (and the .001
> second
> requirement) to vary slightly.
>
> All of the software timing solutions are cost effective (if you don't
> count
> the cost of the PC) and offer the driver registration and scoring, some
> offer the timing also. Software timing will vary slightly from one PC
> to
> another based on what's in the PC, so comparing results from one region
> to
> another would not be accurate to .001 seconds. Comparing results from
> one
> event to another would require using the same PC hardware for both
> events,
> but even then, that would not guarantee .001 second accuracy for both
> events.>>>
>
> Sorry but this is total BS. The fact that the PC clock is inaccurate
> under Windows or MSDOS has nothing to do with what the hardware is
> capable of doing given the proper realtime programming. I agree there is
> no Win32 API call that will give you millisecond accuracy, but there a
> loads of realtime OSes for the PC that will give you much greater
> accuracy than that - I'd be willing to guess at the microsecond level.
>
> The real time clock inaccuracies can be circumvented in a number of
> ways. Probably the best way would be to purchase a programmable interval
> timer that would provide hardware interrupts on a regular basis. A
> device driver would have to be written to make the results available to
> a PC based application but this isn't rocket science...
>
> Paul Foster
> 25 years of realtime programming...
|