-James Dabbs
The processing model of these two systems is very different.
VxWorks is (essentially) a single process, multi-threaded operating
system.
LynxOS is a multi-process, multi-threaded operating system.
LynxOS is very committed to the POSIX APIs (even if they are not
currently compliant).
VxWorks is (in my opinion) not as committed, or not as complete in
implementing them. This could partially be because of their processing
model.
VxWorks has a larger installed base.
VxWorks has a larger number of supported boards and processor types.
VxWorks has (I believe) a smaller memory footprint.
LynxOS will be an easier port if moving code from a Unix-like
environment.
Both are robust, commercial products.
Ted
j
In article <8hpnrl$62o$1...@slb2.atl.mindspring.net>,
"James Dabbs" <jdabb...@mindspring.com> wrote:
> Anyone with experience in both of these? What are the pro's and
con's of
> each?
>
> -James Dabbs
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
>The processing model of these two systems is very different.
>VxWorks is (essentially) a single process, multi-threaded operating
>system.
>LynxOS is a multi-process, multi-threaded operating system.
...
>
>Both are robust, commercial products.
VxWorks, at least historically, has not supported memory protection
whereas LynxOS does. The issue is, no doubt, that multiple threads are
supposed to play nice together as opposed to multiple processes which
might not be as well behaved. Therefore, if you have a wild pointer bug
or the like it is a whole lot easier to trash VxWorks than LynxOS
because you can nail the kernel from a user thread. We've done the
experiments to document this.
Note: VxWorks has been going to have memory protection available Real
Soon Now for quite a while. I know more than one group that gave up on
them because of lack of memory protection. Perhaps they have it now ...
I haven't kept up.
-- Phil
(Hi Ted -- long time no see.)
Phil Koopman -- koo...@cmu.edu -- http://www.ices.cmu.edu/koopman
> Are both products healthy and competitive? Anyone have experience with the
> companies -- financial condition, attitude, support, etc?
VxWorks is made by WindRiver, a long established company, that has
recently become, through some mergers (with Diab, SDS, Take-Five, EST
and a few others) RATHER large company (as far as content). They should
now be a major mover in the real-time embedded field.
Over the last few months, I defined a complete development environment
for an embedded system. Every time I blinked, WindRiver had acquired yet
another of the tools I wanted.
LynxOS is made by LynuxWorks (previously called Lynx), a company of
relatively long (and reliable) standing It is also a very robust system,
(They were the other option I was checking). They recently released
BlueCat - a RedHat Linux clone for embedded systems. Their road map
basically has these two RTOS converging - they will be API and Binary
compatible.
I have spoken to technical people at both these companies, and was
impressed by both.
I ended up choosing to go with WindRiver because of for the specific CPU
I wanted to use, Embedded specific tools were more readily available,
than Unix descended tools adapted to embedded use.
Just my opinion,
Shmuel Kahn.
--
Shmuel Kahn
Embedded Team Leader
Objet Geometries.
ShmuelK#Shpam#@objet.co.il
Spam isn't Kosher - Remove it to reach me.
:> Are both products healthy and competitive? Anyone have experience with the
:> companies -- financial condition, attitude, support, etc?
: Over the last few months, I defined a complete development environment
: for an embedded system. Every time I blinked, WindRiver had acquired yet
: another of the tools I wanted.
Yes, thank the maker there is still open source tools.
: BlueCat - a RedHat Linux clone for embedded systems. Their road map
: basically has these two RTOS converging - they will be API and Binary
: compatible.
I believe you mean upwards API compatible.
Alse there would be little use in maintaining both, would there?
More or less something like the Cygnus [now RedHat] EL/IX initiative.
(http://sourceware.cygnus.com/elix/)
: I ended up choosing to go with WindRiver because of for the specific CPU
: I wanted to use, Embedded specific tools were more readily available,
: than Unix descended tools adapted to embedded use.
Windriver has this CPU support because they hitch a free-ride on the
multiple of CPU targets supported by the GNU C Compiler. These tools
are - as you put it - U*IX descended. And again thank the maker they
are. At least then you can understand what they do and how. Plus, they
_work_ in every permutation of the problem you throw at them.
Which is more than the Windriver produced utilities does.
Now, we would defenitely prefer to have U*IX look and feel also on
the target. Our products containing OS are large enough to take the
memory impact of embedded Linux. With a Real Time scheduler from
Montavista (www.mvista.com) VxWorks is going to depart our department.
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
Gei...@invalid.and.so.forth
******************************************************
> : I ended up choosing to go with WindRiver because of for the specific CPU
> : I wanted to use, Embedded specific tools were more readily available,
> : than Unix descended tools adapted to embedded use.
>
> Windriver has this CPU support because they hitch a free-ride on the
> multiple of CPU targets supported by the GNU C Compiler. ...
> Which is more than the Windriver produced utilities does.
Well I don't know enough about GNU and its' derivatives to comment on
this, but both the Diab C++ compiler and the SingleStep debugger were
not "Windriver produced utilities" until recently, long after these
tools were considered very strong tools.
So I think your comment a bit unfair.
It was the CPU specific support by these tools that cut the cake.
Half a year ago there was VERY little support from
Unix/Linux/Embedded-Linux derivatives for Power-PC processors (I don't
know the current situation).
>Well I don't know enough about GNU and its' derivatives to comment on
>this, but both the Diab C++ compiler and the SingleStep debugger were
>not "Windriver produced utilities" until recently, long after these
>tools were considered very strong tools.
>So I think your comment a bit unfair.
Considered by whom? Maybe by people who never cared to look deeper
into the GNU tools.
>It was the CPU specific support by these tools that cut the cake.
>Half a year ago there was VERY little support from
>Unix/Linux/Embedded-Linux derivatives for Power-PC processors (I don't
>know the current situation).
What makes you think so?
LynxOS (the Real-Time Unix veteran) has been available on the PPC for
several years, including embedded architectures like the MPC8xx
family.
Linux has been running on PPC systems for years, too. Even the MPC8xx
port of Linux is stable and in use in shipping products since well
over a year.
What exactly do you mean by "VERY little support"? What do you miss?
Wolfgang
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
In the beginning, there was nothing, which exploded.
- Terry Pratchett, _Lords and Ladies_
:>Well I don't know enough about GNU and its' derivatives to comment on
:>this, but both the Diab C++ compiler and the SingleStep debugger were
:>not "Windriver produced utilities" until recently, long after these
:>tools were considered very strong tools.
:>So I think your comment a bit unfair.
: Considered by whom?
Good question. No use arguing over it.
It all boils down to attitude.
:>Unix/Linux/Embedded-Linux derivatives for Power-PC processors (I don't
:>know the current situation).
: Linux has been running on PPC systems for years, too. Even the MPC8xx
: port of Linux is stable and in use in shipping products since well
: over a year.
...which is exactly the one we are on the verge of adapting.