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)
return 2; // next state is state 2;
2: if ( CheckSomething() )
return 2; // stay here until something happens.
3: // blah blah blah...
return -1; // if we get here, the state machine has failed.
We have three key problems:Quote:};
- 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
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?