Newsgroups: comp.realtime,comp.os.qnx,comp.os.ms-windows.advocacy,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!sun4nl!sci.kun.nl!plm
From: plm@atcmp.nl (Peter Mutsaers)
Subject: Re: Real-time systems:  Windows-NT or QNX
In-Reply-To: bernie@ecr.mu.OZ.AU's message of Fri, 14 Oct 1994 00:23:09 GMT
Message-ID: <PLM.94Oct17160537@nijmegen3.atcmp.nl>
X-Attribution: PLM
Lines: 111
Sender: news@sci.kun.nl (News owner)
Nntp-Posting-Host: atcmpg.atcmp.kun.nl
Organization: AT Computing
References: <FriOct14102309EST1994@eric>
Date: Mon, 17 Oct 1994 14:06:53 GMT
Xref: glinda.oz.cs.cmu.edu comp.realtime:7185 comp.os.qnx:2238 comp.os.ms-windows.advocacy:40620 comp.robotics:14448

>> On Fri, 14 Oct 1994 00:23:09 GMT, bernie@ecr.mu.OZ.AU (Bernie
>> Kirby) said:

  BK> to a wide variety of real-time controller situations. The first
  BK> thing is it must run on an IBM PC so this rules out systems
  BK> based on other architectures like VxWorks.  The second point is
  BK> that we're doing the work for a company who is trying to develop

2000Hz loop you mention a bit later. That is very fast. I doubt if a
486 can handle that, and if it can, then without doing anything else.
I have made a robot controller running at 300Hz, and we used a 68040
for that (on a VME bus) dedicated for this 300Hz loop (interrupt level
code).

If you need 1000Hz or more, you should use special purpose hardware
such as some DSP board for the inner loop.

  BK> Anyway I've narrowed it down to two (or three) operating
  BK> systems: Microsoft Windows, Windows NT, and the QNX operating
  BK> system from Quantum Computer systems.  What I'm really seeking
  BK> is knowledgeable advice on the best approach, or failing that
  BK> peoples opinions on how best to do what we are trying to do.

If you really want one of these, than QNX is the only possible
choice. MS-Windows has no preemtive scheduling and Windows NT has no
determinacy and also is slow and heavy.

  BK> Force control will be at the next level and trajectory
  BK> generation at a higher level and so on. The highest level would
  BK> be a graphical user interface of some type though its not quite
  BK> clear what is required at that level. The lowest levels (PID

You should separate your GUI part from the rest. I would use an
embedded controller for the real-time stuff, with a real real-time OS
such as QNX, VRTX or VxWorks, use special purpose hardware for the
innel control loop, and connect this front-end via a serial line or
ethernet to a PC or workstation where you run your GUI software (for
example X11).

  BK> loops and force control loops) would be the most important parts
  BK> of the system so they would have to get priority.  They need to
  BK> run at rates between 1000 to 2000 Hz so I suppose accurate
  BK> facilities for timing are needed. Should these tasks run inside
  BK> interrupts connected to a clock or should they run as separate
  BK> tasks?  Is it best to have a rate generator board or can be the
  BK> PC's clock be used?

If you run with this rates on a 'normal' CPU, you should definately
run these inside interrupts.

For general purpose OSses like NT your context switch time plus
interrupt latency plus semafore operation (or whatever you use to kick
the thread) will probably be of the same order of magnitute than the
500us you have available (if not much more).

  BK> programming. Robustness is an important consideration so bearing
  BK> this in mind which scheduling approach is best suited to our
  BK> problem.

If you want robustness you *must* separate at least the real-time part
from the GUI part, and best also the inner fast loop from the slower
real-time part. This way you reduce the complexity for each
CPU. Especially slow I/O processes and virtual memory can make fast
real-time parts very complex and give a lot of disturbance. It is best
to use a cross-development system (like VxWorks) so that the real-time
code can run on a simple embedded board without disk or other I/O.

  BK> One of the most important considerations is ease of writing
  BK> device drivers.  We don't really want to get bogged down in this
  BK> area. Both systems claim some level of POSIX compatibility so I
  BK> guess devices are accessed in both by open/read/write etc
  BK> calls. How do the systems compare in terms of ease of writing
  BK> device drivers for things like A/D boards Digital I/O boards,
  BK> etc. Are drivers readily available?

This POSIX compatability says how the user processes access the
driver, not what the driver itself looks like. I think you'll have to
make your own drivers. If you use I/O boards on a reasonable bus (like
VME, unlike ISA) then making a driver is very easy. But make sure you
buy boards that come with decent documentation of course.

  BK> When it comes to the windowing tasks I suspect that windows has
  BK> the performance advantage since that's what it's really designed
  BK> for.  What we need to make sure of here is that the processor
  BK> doesn't get bogged down updating the screen or running the user
  BK> interface when the servo control tasks must run.  That would

Completely impossible (for reasons I mentioned above). Maybe if you
have a dedicated PC for your GUI you could consider MS-Windows. You
could also think of X-windows.

  BK> The intended application for the robot is hazardous and if the
  BK> software failed the potential for disaster is great. I know we
  BK> have to take responsibility for our own bugs but which systems
  BK> is more reliable or robust. Is there any type of certification
  BK> for computer systems that must run in hazardous
  BK> environments. Does either windows NT or QNX have such
  BK> certification. Failing that, it would be nice to know which
  BK> operating systems has the best track record. Are there well
  BK> known examples where each is used in a dangerous environment.

If you really want such great performance, want to make a complex
system that needs multiple tasks/threads, want a nice GUI, and next to
that have such strict reliability needs, then don't expect that you
can achieve that with the most low-cost solution (i.e. just PC
hardware).
-- 
Peter Mutsaers                  |  AT Computing bv,  P.O. Box 1428,
plm@atcmp.nl                    |  6501 BK  Nijmegen, The Netherlands
tel. work: +31 (0)80 527248     |
tel. home: +31 (0)3405 71093    |  "... En..., doet ie het al?"
