My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

Post by Warren Postm » Fri, 03 Sep 1999 04:00:00



I am considering the tradeoffs involved in using QNX 4, QNX Neutrino or
Pharlap's Realtime ETS Kernel as a target
for porting an existing embedded DOS application that has significantly outgrown
it's single-process 640k roots.

The application is a single-task single-thread process running embedded, using
Datalight ROMDOS as the operating system.
We needed many "apparently concurrent" processes, so we used my own permutation
on the idea of state machines.

Every major function of the system is implemented as a big switch:

int myStateMachineFunc(StateRec *stateptr)
{
   switch(CurrentState)

      1:  DoSomething;
          return 2; // next state is state 2;

      2:  if ( CheckSomething()  )
            return 3;
          return 2; // stay here until something happens.

      3:  // blah blah blah...

    }
  return -1; // if we get here, the state machine has failed.

Quote:};

We have three key problems:
    - no multitasking or multithreading.
    - we're hitting the DOS 640k limit.
    - we need dialup PPP support and TCP/IP Ethernet support.

Additionally, inter-process memory protection would be nice.

Our hardware is Octagon 6012's (being dropped due to being 8086 based), Octagon
6040 (80386sx-20 Mhz), and other 386/486/586 PC compatible embedded hardware,
usually ISA-bus single board computer or PC-104 cpus.

As you can see our application will need to be largely rewritten once
multitasking is part of the picture.  In retrospect
we could have easily written a non-preemptive multitasking kernel and added it
to our MS-DOS program, or even attempted
a round-robin pre-emptive multitasker to our timer-interrupt code, except that
we'd need to add a pile of BeginCriticalSection() ... EndCriticalSection()
throughout our code.  Any critical sections we overlook would cause contentions,
deadlocks, and crashes.

So we need to port this application and we have six months to add a feature that
we need multitasking to add

Here are my problems:

Our current architecture is "monolothic, single-task with state machines" and I
am considering either QNX 4 or QNX Neutrino,
or Pharlap ETS. We have ETS on a 60 day evaluation, and are making the decision
this week to keep it or to go with QNX. We
have also seriously looked at the QNX model.

1. QNX 4 is good, but it's "Processes Only Please"... It encourages designs
around it's Send/Receive/Reply message architecture.   I can't get permission to
spend 12 months rearchitecting our system to work as a series of distributed
modules.  I know there is a Pthreads library on the qnx ftp site, but I don't
want to base my design on a piece of third-party code or implement threading
without support for it in the kernel. I'm also into writing Critical Section
code around all standard C library calls since QNX 4's standard libraries are
not threadsafe.

2. QNX Neutrino has threads so I could make a "monolithic application with
threads" and adapt our current codebase without a total rewrite. However, QNX
Neutrino is still in beta, and I'm sure their board support library is small.
I'm not happy about having to ship a feature on a new platform that might still
be in beta in six months.

3. QNX 4 offers a very meagre environment compared to Pharlap, no cross
development, and poor Windows integration. I don't know about you, but providing
me with my choice of either "vi" or "vedit" and then the ability to type "cc
hello.c" on the command line doesn't pass for a useable programming environment
in my books. Don't get me wrong, I would also be upset if I had a GUI and no
command line compiler or make tools, but either/or is not acceptable. QNX
Neutrino has potentially good set of tools, but then again like the Operating
System, Code Warrior for Neutrino is also still in beta. What's worse is that
their de* ("wd") won't start up when you are telnetting into the system. (I
guess vt100 terminal emulation is not supported by wd's curses' libraries.)

4. On the other hand, Pharlap is based on the idea of an essentially monolithic
hunk of code containing their runtime environment (linked into your application
as libraries) and you link in all your primary code, with the nice feature that
you can put some features in DLLs and make them modular.  You can't exactly
telnet into Pharlap, get a nice shell (either unix ksh,bash,etc, or nt cmd.exe
equivalent) and run little "unix-ish" mini apps and tools to help you maintain
or troubleshoot either, so you have to build all your troubleshooting options
into your main program. Our DOS program had a diagnostic mode, kind of like a
BBS, where you log in with a user name and password and you get a command line
interface to the system for troubleshooting. ALl the commands were internally
implementated as state machines. We will need to re-implement the equivalent
feature set wherever we port to, but a built in TelnetD would still be nice.

Has anyone else been in this kind of bind, and what did you do about it?

Warren

 
 
 

My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

Post by Peter Peterse » Fri, 03 Sep 1999 04:00:00


Warren,

Quote:>I am considering the tradeoffs involved in using QNX 4, QNX Neutrino or
>Pharlap's Realtime ETS Kernel as a target
>for porting an existing embedded DOS application that has significantly
>outgrown
>it's single-process 640k roots.

Did you take a look at On Time's stuff? I think it might have the right
solution for you. For MS-DOS, On Times has:

RTKernel-C:
   * Real mode, 16-bit protected mode (16MB), 32-bit protected mode (4Gig)
   * Preemptive or cooperative multithreading
   * TCP/IP available

For pure 32-bit embedded systems:

RTTarget-32/RTKernel-32:
   * 32-bit protected mode (4Gig), no DOS.
   * Preemptive or cooperative multithreading
   * TCP/IP available
   * Supports IDEs from Microsoft, Borland, Watcom under Win95/98/NT/2000

Full source code of everything is available and it's all royalty-free.

A free trial version of RTTarget-32 can be downloaded from
http://www.on-time.com.

Peter

 
 
 

My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

Post by Guy Mac » Fri, 03 Sep 1999 04:00:00



>I am considering the tradeoffs involved in using QNX 4, QNX Neutrino or
>Pharlap's Realtime ETS Kernel as a target
>for porting an existing embedded DOS application that has significantly outgrown
>it's single-process 640k roots.

(snip)

I happen to be in love with QNX, but I wonder if this is the right
app to make the switch on.  If I were you I would consider trying
one of the various ways to extend DOS so that it does what you want
and introducing QNX on your next fresh design.

Replacing a piston engine/propeller with a jet engine will indeed
give your aircraft better performance, but that doesn't mean that
putting a jet engine into your sopwith camel is the right way to
enter the jet age.

 
 
 

My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

Post by Val R. Krehbie » Sun, 05 Sep 1999 04:00:00


Does this mean that you think state programs are as antiquated as sopwith camels?


> >I am considering the tradeoffs involved in using QNX 4, QNX Neutrino or
> >Pharlap's Realtime ETS Kernel as a target
> >for porting an existing embedded DOS application that has significantly outgrown
> >it's single-process 640k roots.

> (snip)

> I happen to be in love with QNX, but I wonder if this is the right
> app to make the switch on.  If I were you I would consider trying
> one of the various ways to extend DOS so that it does what you want
> and introducing QNX on your next fresh design.

> Replacing a piston engine/propeller with a jet engine will indeed
> give your aircraft better performance, but that doesn't mean that
> putting a jet engine into your sopwith camel is the right way to
> enter the jet age.

 
 
 

My particular RTOS dilemma: QNX 4 versus QNX Neutrino versus Pharlap ETS

Post by Guy Mac » Mon, 06 Sep 1999 04:00:00



>Does this mean that you think state programs are as antiquated as sopwith camels?



>> >I am considering the tradeoffs involved in using QNX 4, QNX Neutrino or
>> >Pharlap's Realtime ETS Kernel as a target
>> >for porting an existing embedded DOS application that has significantly outgrown
>> >it's single-process 640k roots.

>> (snip)

>> I happen to be in love with QNX, but I wonder if this is the right
>> app to make the switch on.  If I were you I would consider trying
>> one of the various ways to extend DOS so that it does what you want
>> and introducing QNX on your next fresh design.

>> Replacing a piston engine/propeller with a jet engine will indeed
>> give your aircraft better performance, but that doesn't mean that
>> putting a jet engine into your sopwith camel is the right way to
>> enter the jet age.

>Does this mean that you think state programs are as antiquated

as sopwith camels?

By no means!  Many of my projects are implimented as state machines.
This forces a rigorous top down design and leads to making design
decisions that cut the number of states in half - cutting down the
number of states usually makes for a cleaner design.

I picked the sopwith camel instead of some other WW1 airplane because
the camel was superior in some ways, inferior in others, and used a
basic design that was very much unlike other planes of the day.
You see, the camel had a stationary crankshaft bolted the the frame
and a rotating engine block bolted to the propeller.  This meant
that a camel pilot could turn right whenever someone was on his
tail and that big gyroscope would allow him to take a path that
couldn't be followed by the enemy.  The problem with this is that
the enemy can turn left and the camel can't follow him.  The main
point is that the camel was *different*  Different to fly, different
fuel system, different engine mounts.  The pilots and mechanics
had to learn different skills.

In like manner a embedded DOS single-process 640k program is
*different* from a QNX program.  If you try a straight conversion
you will be tempted to try to shoehorn QNX into the DOS mold.
(If you want to do a new design, QNX would be a good choice, but
it doesn't seem from your description that you have time for this.)
Extending DOS to handle whatever limits you are bumping against
is technically inferior, but probably a lot less work.

I dislike changing operating systems, compilers, etc. in the middle
of a project.  I don't even like version changes much, unless the new
version has a must-have feature.