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!news.mathworks.com!panix!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!cs.utexas.edu!utnut!nott!uotcsi2!revcan!quantum!danh
From: danh@qnx.com (Dan Hildebrand)
Subject: Re: Real-time systems:  Windows-NT or QNX
Message-ID: <d620hjs@qnx.com>
Date: Thu, 20 Oct 94 02:43:23 GMT
Organization: QNX Software Systems
References: <FriOct14102309EST1994@eric> <PLM.94Oct17160537@nijmegen3.atcmp.nl>
Lines: 110
Xref: glinda.oz.cs.cmu.edu comp.realtime:7269 comp.os.qnx:2305 comp.os.ms-windows.advocacy:41058 comp.robotics:14586

In article <PLM.94Oct17160537@nijmegen3.atcmp.nl>,
Peter Mutsaers <plm@atcmp.nl> wrote:
>
>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.

Assuming the loop rate represents essentially that interrupt rate with some 
computation per interrupt, a 2000 Hz interrupt rate is roughly equivalent 
to a 19.2K baud serial line.  A 486 can easily handle several serial lines 
at this rate, provided it is using an OS with a reasonable interrupt 
latency.  As long as the computation loop associated with the control loop 
is not overly complex, a 486 should be able to handle a control application 
with an incoming data rate of 2000 samples/second without difficulty.

>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).

Can you describe the control loop algorithm and how it was coded (C, 
assembler, etc) ?  I can only assume that you must have had a large amount 
of computation per interrupt in that system.  At what clock speed was the 
68040 running?  With 486/66 chips at the same price now as 486/33 chips, a 
486/66 should have a fair bit more integer computational power than a 68040 
at a lower clock speed.

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

Can you explain why this is necessarily so?  

>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).

As long as the OS can guarantee worst-case interrupt latencies and process 
pre-emption latencies, and as long as that high-priority realtime 
processing still leaves enough processor left over to run the GUI with 
sufficient snappiness for the user interface, why not do it all on a single 
processor under an OS that can provide both the GUI and the realtime 
response needs?  If one of the RTOS's you named were running as the 
realtime OS on the processor running the control loop, then as long as the 
GUI was running at a lower priority, the GUI would have no impact on the 
realtime processing.

>  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.

Again, I don't think this necessarily needs to be the case.  While you 
could do some of the work in the interrupt handler, as long as the OS can 
make guarantees about how long it will be until execution begins of a 
higher priority process readied by the interrupt handler, you could have 
the work done at process time, with the interrupt handler providing the 
first level interrupt response, and triggering the higher priority prcoess 
to preempt whatever lower priority process was running at that moment.

>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).

Possibly true - everything I've been proposing so far assumes the OS is a 
realtime OS hosting both the GUI and the realtime processes.

>  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.

Again, as long as the realtime OS can guarantee that the realtime processes
can preempt the non-realtime GUI processing quickly enough to maintain the
required event rate, why use another CPU?  The GUI should be just as 
controllable as any other lower-priority process, stepping out of the way 
when the high priority process needs to run.

>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).

There are many examples of PC's running a mix of both realtime processes 
and GUI's (just not with mainstream desktop OS's).  While the "low-cost" PC 
is capable of doing this, I would expect you'd want to spend more for an 
industrial PC, not because it will be faster or more deterministic, but 
simply because the hardware will be more reliable.  There's an incredible 
variety of embeddable and industrial-class PC's now, all of which are 
logically equivalent to the PC on your desk, and able to run the software 
that runs there (realtime or otherwise).
-- 
Dan Hildebrand      danh@qnx.com         QNX Software Systems, Ltd.   
phone: (613) 591-0931 x204 (voice)       175 Terence Matthews          
       (613) 591-3579      (fax)         Kanata, Ontario, Canada K2M 1W8
