Craig Blome <cblome@yahoo.com> wrote:
>Windows' real Achilles heel for real time jobs is that
>it is a cooperative system (that is, one task can't
>run until the previous one gives up the system). If
>an errant application or device driver disables
>interrupts for a long time, there's no way to avoid
>dropping timer signals
!!Warning: Techie stuff follows; skip down a few paragraphs if not
interested in OS workings.
Well, yes and no. Win16 (Windows 3.x) was a non-preemptive multitasking OS,
so an app that didn't give up the processor could hang everything. Win32 (NT
and 9x) is a preemptive multitasking OS; every app (technically, thread) is
placed onto the processor for a given amount of time (quantum), then cycled
off. If an app hangs, it hangs only during its quantums, all other apps keep
running as their threads get switched onto the CPU.
N.B., 16-bit apps on Win9x share a Virtual DOS Machine (VDM), therefore one
16-bit app can hang the rest, the 32-bit apps keep running. On NT, you can
start 16-bit apps in seperate VDM's so that they don't hang each other, but
that's not the default behaviour. Check the "Run in Seperate Memory Space
box on the Start...Run dialog box to get a seperate VDM.
The real problem as far as timing is concerned is that all the apps are
being switched onto and off of the CPU by the OS task scheduler. You can
change how long a thread stays on the CPU by using priority levels and such,
but it will still be context switched off for some amount of time. While
it's off the CPU it can't do anything, like poll a port, etc. The more
things happening (apps running, disk activity, etc.), the more threads you
have and the more context switches need to take place. On a heavily loaded
box, a significant amount of CPU time can be spent by the scheduler just
moving thread context on and off the CPU, not even doing the threads' real
work.
Also, NT won't let User-mode code (applications) touch the hardware
directly, they have to talk to Kernel-mode code (OS kernel, device drivers,
VxD's, etc.). Win9x will let applications touch the hardware directly.
Now, the new "Embedded" flavor of NT that's targeted at true realtime
systems on custom Windows CE devices may be a completely different ball of
wax, I haven't looked into it in depth yet.
!!END maxi-zoom dweebie OS stuff
I still think the best all-around solution, _supposing_ _requirements_ _of_
+-.0005 timing and a nice familiar GUI to enter data (custom Win app, Excel,
etc.) is to have a serial device (laptop-friendly) that deals with the
actual start and finish light timing, and just sends timestamp data to the
serial port. An app can then pick up the data at its leisure. I think this
is at least simiar to what the JACircuits box supplies, but all you really
need is the data stream from the timing box; the displays, resets for false
start/stops, etc. can be all handled by a Windows app.
>NT at an autocross...the horror, the horror...
Hmm...
I just had an evil thought for The Timing System of The Future. I was going
to describe it, but I may want to get a patent first.
BWaaaaHaaaHaaaaa....
Dave Williamson
ctautox@hotmail.com
DS '96 Neon ACR
FCSCC T&S chair
MCSE, MCSD, MCDBA, MCT
|