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!pipex!uunet!olivea!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!bagpiper
From: bagpiper@netcom.com (Michael Hunter)
Subject: Re: Real-time systems:  Windows-NT or QNX
Message-ID: <bagpiperCxp41x.8s9@netcom.com>
Followup-To: comp.realtime,comp.os.qnx,comp.os.ms-windows.advocacy,comp.robotics
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <FriOct14102309EST1994@eric>
Date: Sat, 15 Oct 1994 03:51:32 GMT
Lines: 252
Xref: glinda.oz.cs.cmu.edu comp.realtime:7148 comp.os.qnx:2206 comp.os.ms-windows.advocacy:40439 comp.robotics:14385

Bernie Kirby (bernie@ecr.mu.OZ.AU) wrote:
: Greetings Fellow Netters,

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

I hate to be the one to tell you this but VxWorks does run on
intel platforms.  It is a cross compilation environment though 
(you develope on one platform and upload the code to the actual
execution environment).  I don't personally like the design of
VxWorks much so I wouldn't recommend it.  I'm a bit biased toward
QNX so you might take my opinion with a small grain of salt.

: for a company who is trying to develop this work commercially so we'd
: prefer a commercial system so they'd have someone to blame when things go
: wrong.  Third the system should be able to run multiple tasks so I guess

Most of these OS' will have disclaimers.  I've noticed on QNX' that 
there are some special terms for medical (life critical) apps.  My
guess is you could contact them for special information if you app
is one of these.

: MS-DOS is out of the question, though some people here (I suppose they
: include myself) think it might be a good choice if for no other reason
: than it's robustness.

If you model of robustness is MS-DOS then I've got something to sell
you...

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

And if you think windows is even close to being stable (much less robust)
then you havn't tried to write code on it.  Those GPF based coffee break
every few hours (or more often) are really fun.  I don't know much
about NT.

: In essence what we want to do is run a variety of tasks some at very regular
: intervals, so for these determinacy is a key issue, and others
: when certain events take place such as a key-hit. Each of these tasks might

QNX (when I say QNX I alway mean QNX 4.x) has several scheduling schemes
that will make this kind of thing as easy as it can be.  Now that
you have a reasonable OS, take a look in comp.realtime or you favorite
realtime text if you want to get a taste as to how hard the problem
reall is (hint: systems get comples real fast - thats why an OS that
is predictable is a life saver).

: higher level and so on. The highest level would be a graphical user
: interface of some type though its not quite clear what is required at that
: level. The lowest levels (PID loops and force control loops) would be the

QNX has 3 choices for GUIs. 
X Windows - X11r5 w/Motif 1.2+
QNX Windows - a Open Look compliant distributed GUI (nice)
Photon - just coming out of Beta; I believe the description is something
like an "X inspired GUI w/ realtime and embedded support".  This looks
*hot*.  Its small also (but then of course all of QNX is).

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

That shouldn't be a big deal.  As the Forth guy said, these rates are
not that big.  QNX does have the ability (fairly new) to run the system
clock off an external source (contact QNX for details).

btw, Forth is a viable option.  I like Forth.  I program in Forth
as a hobby.  I wouldn't build our 7-24 system solely on Forth due to
its uniqueness.  But I am using it as a state machine driver in part
of my QNX code.

: I understand QNX use a strategy called pre-emptive scheduling where a
: highest priority task runs where as Windows and Windows/NT have a

There are 3 different scheduling types:
1) priority driven pre-emptive time sliced means that each task has a numerical
priority given to it.  Whenever a task becomes "ready" (via an ISR
providing input to it, somebody unblocking it via IPC, etc.) it time
slices with other tasks at its priority.  If there is somebody at
a higher prio that becomes ready, they get the CPU.  Tasks at the same
prio time slice (each get a block of time to execute).
2) FIFO - much like the above but when a task gets the CPU it keeps
it until it blocks (issues IO, IPC, etc. - unique to QNX and other 
messaging passing OS almost all blocking is done via a message pass).
3) Adaptive - don't use this one much, but it is useful for GP computing.
It adjusts tasks "effective" prio up or down if it appears that task has
gotten a lot of CPU.
 
: different approach called (I think- but dont quite me :-]) threads (I don't

threads are a different (well same:) beast - processes under QNX have
separate address space.  One process crashing cannot bring down another
process. Comapre this to VxWorks and Psos which do not necessarily
have protected address spaces.  The concept of a thread is, well, 
poorly defined but usu. means that a group of processes share some
resource (usu memory).  QNX has threads (right Dans).

Threads are a hack, but useful and dangerous.  IN 99.9% of the cases
you will use full processes and shared memory.

: quite know how they work so if someone could compare the two that would be
: very helpful).  Is "preemption" a good strategy for this type problem? I

yes

: guess it must take some time for tasks to be swapped back to the processor
: so that must be a key-factor, though if I run my servo-loops as interrupt
: service routines that surely would be the overcome any problems  with
: context switching times. Are there any disadvantages of the interrupt

context switching times are *fast* under QNX - for simular hardware they
beat the OS' that I comapred a while back (OS/9, VxWorks, pSOS).  Now
that I've thrown flame bait, let me say that context switch times are
only a small part of the whole system.

: service routine approach. I'd sure be interested to know what people think
: is the most sensible strategy for doing this type of real-time
: programming. Robustness is an important consideration so bearing this in
: mind which scheduling approach is best suited to our problem.

There was an interesting argument in comp.realtime a ways back that
NPS (non preemtive shceudler) could provide better robustness...
Interesting argument if just to get one to think.

I would opt for using syncronous IPC with QNX style scheduling.  But
then I've already made that choice...

: One of the most important considerations is ease of writing device
: drivers.  We don't really want to get bogged down in this area. Both

QNX has several different types of "device drivers".  You can write
full up POSIX compliant "serial" style drivers if you want (looks
of medium difficulty to me).  They also have a style of device driver
they call an IO Manager that are great for many apps and easy to write.
Those also have some special support that I've never investigated for
Data Acquisition type of stuff.

: systems claim some level of POSIX compatibility so I guess devices are
: accessed in both by open/read/write etc calls. How do the systems compare

Wiht IO Managers this is a breeze...  I wrote an IO Manager that
"file mapped" a UDP connection in a few hours as a first try.  It
support read/write/dup/open/close and a few others.  Lately I have
been writting an IO Manager that allows you to reroute what a filename
"points" at and this supports most calls including select.

: in terms of ease of writing device drivers for things like A/D boards
: Digital I/O boards, etc. Are drivers readily available?

Depends on the type of board.  Your best bet is to take your list of
potential board, telnet to qnx.com, and post a question to user2user/qnx4
asking if anybody has written a driver.

: When it comes to the windowing tasks I suspect that windows has the
: performance advantage since that's what it's really designed for.  What we

Windows is a dog.  I run doom under QNX 4 X-Windows while doing other
stuff in the background.  Try that under Windoze.  I get the feeling
it wasn't designed.  On the other hand I often hack up little VB
apps for office support tasks that make the accountants happy.

: need to make sure of here is that the processor doesn't get bogged down
: updating the screen or running the user  interface when the servo control
: tasks must run.  That would lead to big problems with the controller. Is

With Photon I believe you have good control over this type of thing.
With X, you have less, but you can move your interface to another 
machine and remove some of this problem.

: preemption or threads the better suited strategy here. Would windows be
: better or QNX? What are the key things to look at. Does QNX have a
: windowing system or do we need by one from some other seller. Do they

I forgot one windowing system you might be interested in.  You can
run Windows 3.1 standard under QNX and have QNX tasks talking to 
windows tasks.  If you really like windows, you can use it.

: exist at all? I suppose Windows is the de-facto standard for Graphical user
: interfaces (correct me if I'm wrong) so how close is QNX to windows in
: this area?

de-facto standard?  Hmmm...I don't like to say this, but if your selling
business apps out there Windows is the standard.  Robotics is a
verticle market though so going with the market leader shouldn't be
a big selling point.  Having your product work should be.

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

Call QNX and get them to talk to you about this.  Have them send you
some back issues of QNX news that talk about apps that QNX is used in.
I think Beckman uses QNX in some of their medical instrumentation.

: QNX calls isself a real-time operating system whereas Windows and Windows
: NT seem to be much more general and broader operating systems that provide
: facilities for real time control. Is is better to go for the generality

QNX has two sides.  I personally think that its distributed nature is
very well thought out.  Most RT OS' will add TCP/IP and call themself
distributed.  Hogwash!  TCP/IP is a nice internetworking protocol but
sucks on a LAN for general distirbuted computing.  QNX' RT nature
is alos very well thought out.  I think that the RT community is a little
farther along is deciding how to do things right then the distributed
community so you will probably find that the RTOS comarpe more equally
then the distributed OS.  btw, QNX distributed nature could make keeping
your graphical user IF out of your way easier.  So don't think it won't
be useful.

: wide spread applicability and large software base of Windows or do you
: think that QNX is better suited for the type of work we intend to do?  Of

If your doing any RT work leave Microsoft in the business office.

: course almost everyone uses windows to some extent or another but I want
: to know which system is the best all-round choice for real-time control
: where the controller must also run a graphical user interface. I would

real-time => no Windows

: really like to know the pros and cons of each system and whether there is
: general consensus that one is better than the other. I have an open mind
: but I don't have the experience necessary to make the best decision.  So
: in summary what I'm asking is which operating system is better for the
: work we are going to do. Does anyone else  use either of these operating
: systems for real-time control of robots.

: Any thoughts what-so-ever would be greatly appreciated.

: Bernie.

Good luck.  I would suggest that you find people that you can trust
to sit down with you and analyze your task.  Many times you can
winow the real-timedness of a system down to a very small section.
Depending on how successful you at this and how tight your consraints
are you might choose QNX or possible some combo of QNX and Windows.

		Michael Hunter
-- 
* Michael Hunter	bagpiper@netcom.com or QUICS: mphunter
