Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Choice of QNX 4, 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 application.

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 state machines
 every major function of the system is
implemented as a big:

  void myFunc(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...

    };

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.

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 has bad tools. I don't know about you, but providing me with the
ability to "cc hello.c" on the command line doesn't pass 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.

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

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

Warren

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by A. Steinhof » Fri, 03 Sep 1999 04:00:00



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

>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 state machines
> every major function of the system is
>implemented as a big:

>  void myFunc(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...

>    };

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

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

It depends on your current design. If you have collected all common used data in
one module ... put it in one big shared memory segment and make it available to
all processes. Well, the access to that data segment has a slightly overhead ..

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

Forgett it ... you can't use the Watcom de* if you use the kernel Pthreads.

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

I have heard that Neutrino 2.0 will be released in a short timeframe ...

Quote:>3. QNX 4 has bad tools. I don't know about you, but providing me with the
>ability to "cc hello.c" on the command line doesn't pass 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.

yes ... it's still in beta for some weeks (?)

Quote:>4. 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.

I don't know about their real-time capabilities. Pharlap is a kernel system ...
QNX4 and Neutrino are very complete operating systems.

Your are in the process to leave a dead-end street ... IMHO, with Pharlap you
will wend in an other one.

Armin Steinhoff

http://www.veryComputer.com/

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Sam Robert » Fri, 03 Sep 1999 04:00:00


Previously, Warren Postma wrote in comp.os.qnx:

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

> 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 state machines
>  every major function of the system is
> implemented as a big:

>   void myFunc(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...

>     };

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

> 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 don't see how making your app be multi-threaded is going to be any
less of a re-write. If you are thinking that all your threads will be able
to access all your current (global) data structures, that is achievable
trivially between processes as well: put the data in a shared memory area,
insert semaphores into it to control access to critial sections, and you have
pretty much the same as a multi-threaded app, with each thread having its
own protected heap, timers, files, etc. They share *only* the data you
want shared everything else is protected/private, look at either way. Privacy
is good.

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

Some people have reported success with this library, and been happy, but I
tend to agree with you, and critical sections wouldn't necessary help either,
its possible for routines to be non-thread safe for reasons other than
reentrancy, like strtok(), or sleep(), (an example, I don't know it those
two are thread-safe in the latest library).

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

Neutrino is coming along well, and inherited much of the board support from
QNX4, check your list of requirements against what it has, if they match,
and you really want threads, this may be the way.

Quote:> 3. QNX 4 has bad tools. I don't know about you, but providing me with the
> ability to "cc hello.c" on the command line doesn't pass 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.

I, personally, flat out disagree. Only crazy people compile their apps from the
command line, in any OS, and in QNX you use 'make', a tool with a long and
feature-rich history. If you want a cute GUI, and don't pull you hair out
every time you have to try and do anything in MS Windows (like me) then get
one QNX4 development station, and run phindows (it displays a full QNX
desktop in a window on an MS OS). Run your favorite editor in Windows, export
your source code from a shared filesystem, and do your builds in the QNX/Phindows
window. Works well.

In my opinion, cross-development sucks, and one of the biggest advantages of QNX
is the self-hosted development. That said, Neutrino has the codewarrior stuff
for NT, so if you like it...

Quote:

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

I prefer the flexibility of a full, real-time, scalable OS, that can grow
with your application, and where the experience gained on one project can
be leveraged for the next, since the O/S will grow to accomadate it.

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

> Warren

--

"News is very popular among its readers." - RFC 977 (NNTP)
 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Mike Lacke » Fri, 03 Sep 1999 04:00:00



> <snip>

> I, personally, flat out disagree. Only crazy people compile their apps from the
> command line, in any OS, and in QNX you use 'make', a tool with a long and
> feature-rich history. If you want a cute GUI, and don't pull you hair out
> every time you have to try and do anything in MS Windows (like me) then get
> one QNX4 development station, and run phindows (it displays a full QNX
> desktop in a window on an MS OS). Run your favorite editor in Windows, export
> your source code from a shared filesystem, and do your builds in the QNX/Phindows
> window. Works well.

> <snip>

Ditto.  I use this environment every day,  for me it's the best of both worlds.

Mike

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Mario Chares » Fri, 03 Sep 1999 04:00:00



Quote:> Previously, Warren Postma wrote in comp.os.qnx:

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

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

Then why do you need a multi-tasking for, thread are nice but processes are
better ;-)
If you have experience with multi-tasking it shouldn't take you too long to
come up
with a new design.  How big is you program?   I'm guessing it's not that big
since
you a hitting the 640k. In my opinion in 1 day or so one can have a pretty
good
idea how thinks be organised.

Quote:> I don't see how making your app be multi-threaded is going to be any
> less of a re-write. If you are thinking that all your threads will be able
> to access all your current (global) data structures, that is achievable
> trivially between processes as well: put the data in a shared memory area,
> insert semaphores into it to control access to critial sections, and you
have
> pretty much the same as a multi-threaded app, with each thread having its
> own protected heap, timers, files, etc. They share *only* the data you
> want shared everything else is protected/private, look at either way.
Privacy
> is good.

I second that!

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

95% of them are.  And you don't have to use the pthreads library.

Quote:> Some people have reported success with this library, and been happy, but I
> tend to agree with you, and critical sections wouldn't necessary help
either,
> its possible for routines to be non-thread safe for reasons other than
> reentrancy, like strtok(), or sleep(), (an example, I don't know it those
> two are thread-safe in the latest library).

I'm not using the pthread library (unsupported) but rather the
_beginthread() stuff,
works very well for me.  Most the the C library function are thread-safe
(this is
documented).  Threads are a little more difficult to debug.

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

Neutrino 2.0 is out.

Quote:> > 3. QNX 4 has bad tools. I don't know about you, but providing me with
the
> > ability to "cc hello.c" on the command line doesn't pass 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.

That's a sensitive topic ;-) personnaly i'm real happy with pterm and
makefiles!

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

What you haven't told us is what is your current knowledge about the various
OS you
have in mind.  Personnaly I tend to stick with what I know because the
learning
curve can kill you, unless the product requires a feature that the OS
doesn't provide.

- Show quoted text -

> > Warren

> --

> "News is very popular among its readers." - RFC 977 (NNTP)

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Henrique » Fri, 03 Sep 1999 04:00:00


    I worked with DOS/WINDOWS for a long time.  I still do a few things here
and there.

    For just about two years, I have been working with QNX 4, to port our
Data Acquisition System (DAS) from DOS to QNX 4.  In a few words, QNX 4
works great.  It is very reliable, boots fast.  The IRQ latency will blow
your mind!

    I was able to do an eval of QNX 4 and prove to myself and my boss that
QNX 4 would handle all the tasks that we needed to perform for our DAS.  The
hardest part was choosing the GUI.

    Dialup PPP is no problem with QNX 4.

    The Send/Receive/Reply message architecture is easy.  If you want, you
can take the Real Time course which I found to be a must for anyone doing
QNX work.  I would still do the QNX eval first!

    You can even run QNX from a Windows machine (laptop) over a program
called Phindows.  You can do your development or test your app.

    If your product is an embedded system, then QNX Neutrino might be the
way to go.  Don't worry about the beta products.  QNX beta products are
great.  I have been using beta products since I started (you get upgrades as
often as they bring them out).

    Get their phone number, give them a call and talk to a pre sales
technical support engineer.

    I would stay away from Pharlap.  I did an eval a few years ago, an ran
into a lot of problems with their stuff.  It is not real-time at all.  They
have to do some memory context switching stuff that seems to take forever.

    I don't work for QNX, I just love using it...

    Augie Henriques
    SEA, Inc.

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by D J Hawkey » Sat, 04 Sep 1999 04:00:00




> Previously, Warren Postma wrote in comp.os.qnx:

>> 3. QNX 4 has bad tools. I don't know about you, but providing me with the
>> ability to "cc hello.c" on the command line doesn't pass 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.

> I, personally, flat out disagree. Only crazy people compile their apps from the
> command line, in any OS, and in QNX you use 'make', a tool with a long and
> feature-rich history. If you want a cute GUI, and don't pull you hair out
> every time you have to try and do anything in MS Windows (like me) then get
> one QNX4 development station, and run phindows (it displays a full QNX
> desktop in a window on an MS OS). Run your favorite editor in Windows, export
> your source code from a shared filesystem, and do your builds in the QNX/Phindows
> window. Works well.

> In my opinion, cross-development sucks, and one of the biggest advantages of QNX
> is the self-hosted development. That said, Neutrino has the codewarrior stuff
> for NT, so if you like it...



I agree with Sam whole-heartedly. Cross-developement does suck.

Besides, and Sam addresses this a bit, the Watcom 10.6 C/C++ package
is actually a very solid piece of work. Yeah, rather anachronistic, as
it isn't GUI'd all together into a seamless GDE (that you wish was done
differently anyway), but solid. Creates tight code, too. And there is
an upshot to CLI tools: Run X on QNX, get familiar with the xc*
editor, and you get an approximation of a GDE, that you _can_ tailor!

Dave

--
  ______________________                         ______________________
  \__________________   \    D. J. HAWKEY JR.   /   __________________/

                      http://www.veryComputer.com/~hawkeyd/

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Lawrence Wissi » Sat, 04 Sep 1999 04:00:00



Quote:

>     If your product is an embedded system, then QNX Neutrino might be the
> way to go.

Why is this? What about Neutrino makes it better for real time systems?
We are currently building the next generation of a real time locomotive
control system.
(Pentium,VME)

Quote:> Don't worry about the beta products.  QNX beta products are
> great.  I have been using beta products since I started (you get upgrades
as
> often as they bring them out).

The first generation used QNX and we are all but decided to go the same way
again, primarily because it has been so rock stable.
We are hesitant to go to Neutrino, because of how new and uproven it is, and
by it's lack of X support (which limits our choice of UI tools).

But the Codewarrior development environment available for Neutrino is very
compelling.
The native tools, Watcom C++ compiler & de*, Vedit are primitive.
Given our tight schedule, anything that enhances developer productivity is
attractive.

Is there something else about Neutrino that we should know that makes it
better for embedded systems?

// Larry Wissig
// GE-Harris Railway Electronics

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Armin Steinhof » Sun, 05 Sep 1999 04:00:00





>>     If your product is an embedded system, then QNX Neutrino might be the
>> way to go.

>Why is this? What about Neutrino makes it better for real time systems?
>We are currently building the next generation of a real time locomotive
>control system.
>(Pentium,VME)

>> Don't worry about the beta products.  QNX beta products are
>> great.  I have been using beta products since I started (you get upgrades
>as
>> often as they bring them out).

>The first generation used QNX and we are all but decided to go the same way
>again, primarily because it has been so rock stable.
>We are hesitant to go to Neutrino, because of how new and uproven it is, and
>by it's lack of X support (which limits our choice of UI tools).

>But the Codewarrior development environment available for Neutrino is very
>compelling.
>The native tools, Watcom C++ compiler & de*, Vedit are primitive.
>Given our tight schedule, anything that enhances developer productivity is
>attractive.

>Is there something else about Neutrino that we should know that makes it
>better for embedded systems?

Igor posted that comparison weeks ago ... I have added some additional points.

Feature                 QNX4            NTO
-------------------------------------------------------------------------------
Threads                 Unsupported     Yes
SMP                     No              Yes
Multiplatform           No              Yes [x86, PPC, MIPS (ARM and SH
may follow later)]
Dynamic linking/loading No              Yes
Supplementary groups    No              Yes
Photon                  Yes             Yes
Memory mapped files     No              Incomplete
Native networking       Yes             Incomplete
TCP/IP                  Yes             Incomplete              
Self-hosted             Yes             Incomplete
Swapping                No              Maybe
Disk quotas             No              Maybe
+kernel preemptive      No              Yes      
+No. of priorites       32              64

* Unsupported   - useable, but not officially supported or encouraged.
* Incomeplete   - not ready or not fully functional for release 2.0, will
                  be completed in next release.
* Maybe         - design allows implementation, but not scheduled yet.

Some of these features are important for embedded systems ... some are not.

IMHO ... one important point is that Neutrino is more compatible to the rest of
the UNIX world than QNX4.

Armin Steinhoff

- Show quoted text -

Quote:

>// Larry Wissig
>// GE-Harris Railway Electronics

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Henrique » Sun, 05 Sep 1999 04:00:00





>>     If your product is an embedded system, then QNX Neutrino might be the
>> way to go.

>Why is this? What about Neutrino makes it better for real time systems?
>We are currently building the next generation of a real time locomotive
>control system.
>(Pentium,VME)

Smaller footprint than QNX, less memory requirements, etc...  QNX Neutrino,
from what I understand is a product specifically developed with embedded
systems in mind.

Quote:

>> Don't worry about the beta products.  QNX beta products are
>> great.  I have been using beta products since I started (you get upgrades
>as
>> often as they bring them out).

>The first generation used QNX and we are all but decided to go the same way
>again, primarily because it has been so rock stable.
>We are hesitant to go to Neutrino, because of how new and uproven it is,
and
>by it's lack of X support (which limits our choice of UI tools).

If you need X support, then stay with QNX 4.
Quote:>But the Codewarrior development environment available for Neutrino is very
>compelling.
>The native tools, Watcom C++ compiler & de*, Vedit are primitive.
>Given our tight schedule, anything that enhances developer productivity is
>attractive.

>Is there something else about Neutrino that we should know that makes it
>better for embedded systems?

>// Larry Wissig
>// GE-Harris Railway Electronics

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Igor Kovalenk » Sun, 05 Sep 1999 04:00:00



> Why is this? What about Neutrino makes it better for real time systems?
> We are currently building the next generation of a real time locomotive
> control system.
> (Pentium,VME)

Several things.
1. You can eliminate ISRs totally. Instead of attaching an interrupt
handler you may ask kernel to send you an event when interrupt occurs.
So, NOTHING runs in kernel space.
2. More prioriry levels (64)
3. Pulses are much more convinient than proxies.
4. Real good POSIX threads
5. Richer API. Lot of Unix'98 calls supported as well as legacy Unix
calls.

Quote:> The first generation used QNX and we are all but decided to go the same way
> again, primarily because it has been so rock stable.
> We are hesitant to go to Neutrino, because of how new and uproven it is, and
> by it's lack of X support (which limits our choice of UI tools).

Xfree86 3.3.4 has been ported to NTO already.
See http://www.veryComputer.com/~qnxfree86

Quote:> But the Codewarrior development environment available for Neutrino is very
> compelling.
> The native tools, Watcom C++ compiler & de*, Vedit are primitive.
> Given our tight schedule, anything that enhances developer productivity is
> attractive.

The Metrowerks suite is not ready yet. May be it will become better with
time, but for now I prefer Nedit + GCC + GDB + DDD. Makes a good enough
IDE ;)

Quote:> Is there something else about Neutrino that we should know that makes it
> better for embedded systems?

Generally, to work with NTO is much more fun at the moment ;)
By the way, does anyone know the NTO 2.0 has been released? The do not
seem to announce it anywhere except for beta conference at QUICS. Weird
enough...

- Igor

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by ddout.. » Mon, 06 Sep 1999 04:00:00




<snip>

Quote:> Generally, to work with NTO is much more fun at the moment ;)
> By the way, does anyone know the NTO 2.0 has been released? The do not
> seem to announce it anywhere except for beta conference at QUICS.
Weird
> enough...

> - Igor

Igor, a while back, you made a comparison list for QNX4 and NTO.  Was
that list based on released NTO at the time?  How, if at all, would
your list change with NTO 2.0 now released?

Dean

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Mario Chares » Mon, 06 Sep 1999 04:00:00





> >     If your product is an embedded system, then QNX Neutrino might be
the
> > way to go.

> Why is this? What about Neutrino makes it better for real time systems?
> We are currently building the next generation of a real time locomotive
> control system.
> (Pentium,VME)

> > Don't worry about the beta products.  QNX beta products are
> > great.  I have been using beta products since I started (you get
upgrades
> as
> > often as they bring them out).

> The first generation used QNX and we are all but decided to go the same
way
> again, primarily because it has been so rock stable.
> We are hesitant to go to Neutrino, because of how new and uproven it is,
and
> by it's lack of X support (which limits our choice of UI tools).

> But the Codewarrior development environment available for Neutrino is very
> compelling.
> The native tools, Watcom C++ compiler & de*, Vedit are primitive.
> Given our tight schedule, anything that enhances developer productivity is
> attractive.

IMHO,  however good or wonderfull an IDE is, it will never
allow you to recover the lurning curve of switching to a new OS.  If
you're happy with QNX4 and you new design doesn't required a feature
thet QNX4 can't provide you with, stick with it.

You'd probably better off writing your own Macro to improve vedit.  I just
got vedit pro to work with the lastest ctags, I'm doing stuff that even
the guy using the Visual C++ editor (for editing text file on QNX4)
can't do, because they would have to compile it to get to the real fun
goodies.

Oh and you might want to know that a competitor of your (can't give names)
is switching to Neutrino.

- Show quoted text -

Quote:

> Is there something else about Neutrino that we should know that makes it
> better for embedded systems?

> // Larry Wissig
> // GE-Harris Railway Electronics

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Roger William » Tue, 07 Sep 1999 04:00:00


  > The Metrowerks suite is not ready yet. May be it will become
  > better with time, but for now I prefer Nedit + GCC + GDB +
  > DDD.

AFAIK, Metrowerks doesn't intend to support any host platform but
Windows.  I doubt if it'll provide any particular improvement over the
quality of the code produced by GCC, and you'll have to put up with
Windows to use it.

  > By the way, does anyone know the NTO 2.0 has been released?

Yes, 2.00 + patch A began shipping a week ago.  Order P/N 008019.

FWIW, if you're accustomed to programming in a modern POSIX-compliant
environment, Neutrino is a real joy to work with.

--
Roger Williams                         finger me for my PGP public key
Coelacanth Engineering Inc    consulting & turnkey product development
Middleborough, Massachusetts           wireless * datacomm * DSP * ATE
tel +1 508 947-5585 * fax +1 508 861-0278 * http://www.coelacanth.com/

 
 
 

Choice of QNX 4, QNX/Neutrino versus Pharlap ETS

Post by Sam Robert » Wed, 08 Sep 1999 04:00:00


Previously, Igor Kovalenko wrote in comp.os.qnx:


> > Why is this? What about Neutrino makes it better for real time systems?
> > We are currently building the next generation of a real time locomotive
> > control system.
> > (Pentium,VME)

> Several things.
> 1. You can eliminate ISRs totally. Instead of attaching an interrupt
> handler you may ask kernel to send you an event when interrupt occurs.
> So, NOTHING runs in kernel space.

I don't know if there's a "general case", but some of the interrupts I've
written code to handle *require* acknowledgement before the ISR returns,
or it continues to be asserted, and this acknowledgement is board specific.

Does Nto deal with this, or is it a case where you'd still need to write
an ISR?

Sam