( ELSE 06 Item 5 ) --------------------------------------------- [ 06/23/06 ]
Subject: Mentor Nucleus, Wind River VxWorks, Green Hills, ARM Realview
LINUX VS. MICROSOFT -- These comments from the embedded RTOS users made for
some interesting reading. Apparently Wind River VxWorks is the Microsoft of
the RTOS world; it's big, bloated, secretive, easy-to-use, and proprietary;
plus it owns an awful large part of the market and they collects royalties.
In contrast, Mentor Nucleus is the Linux of the RTOS world -- they let you
see the Nucleus source code and they don't collect any royalties! (Just on
the use model and open source code alone, I'm cheering for Mentor here.)
Nucleus seems to have a good reputation and is shipping in a lot of
STBs. We certainly see it a lot more than Green Hills's Integrity OS.
The Greenhills IDE/Compiler/Debugger, however, gets a lot more traction.
- [ An Anon Engineer ]
Nucleus and most of it's middleware is a good value especially since the
sources are provided. Nucleus and Green Hills RTOS are not in the same
category as VxWorks because of differences in the use models.
So, I won't include VxWorks in my answer, however I will add ThreadX.
Green Hills:
It's a source base that is strongly dependent upon the Green Hills tools;
If you are already investing in the most expensive tool chain available
(Green Hills) then it is OK. It isn't portable, doesn't have as many
middleware features and doesn't have the longevity and stability that
Nucleus has.
ThreadX:
ThreadX is Nucleus. (Don't tell a Nucleus person this; it will upset
them.) ThreadX and Nucleus were both written by the same guy. The
value that ThreadX has is that they are hungry and therefore nimble
and flexible. There is less middleware available so the cost of entry
for many application may be greater than Nucleus.
Nucleus Plus 1.x
Nucleus, as stated above is seasoned. This has resulted in many bug
fixes and a wider community to help or get experienced developers from.
They are actively pursuing the usability of the product and tooling
related. The middleware is stable and integrates well.
Mentor isn't Accelerated Technologies; they lack the small-hungry
attitude that begets the nimble attitude that ATI and ThreadX had in
common. Nucleus isn't that bad (yet) although their ability to be
responsive is reduced by both Mentor bureaucracy and that the code
base that represents what may be all that the customer needs (the
kernel) isn't the real product that Mentor is selling -- it is merely
enabling the sale of the bigger ticket items like compilers, and EDA
tools.
Wind River VxWorks:
Here's why it shouldn't be in the list:
1) VxWorks is not a source-based product. This means that VxWorks
cannot be developer optimized. The application cannot be trimmed
for FAA certification (dead code elimination). There is no way of
using good tools to improve code quality. Basically, what you
bought in library form and unalterable it is "as good as they are
willing to make it".
2) VxWorks is too large for most of the applications that the other
three apply as they have a very small footprint. The code is too
large to fit into most controller systems where memory/power are
critical Since they cannot fit into the space/power critical
applications they don't try to do so.
However, to appease the unwashed masses...
VxWorks is the Microsoft of RTOS'. They needn't be any better nor fix
their problems as their market is locked in (ala Synopsys). The
useability of VxWorks is wonderful. It is feature rich as well. The
cost for this is quite large (relative to the others). This cost is in
all areas except for talent. The average college grad can build an
application in VxWorks and it will have the bloat associated with
linking unneeded code that allows the fresh grad to create a system and
not know how the thing works. VxWorks as a product BASE KERNEL ALONE
generally occupies a footprint that is consumed by the base kernel and
application code for a full featured application built with the other
kernels. VxWorks isn't as large as embedded Linux (yet).
Personally I use mostly Gnu or the variant that is 'tweeked' by the IP
vendor (sde-GNU or xt-GNU, or the base). I am an old-time developer
who feels that an RTOS is 40% of my headroom lost. So, I use one where
I need to partition the project over several mid-to-junior engineers.
- [ An Anon Engineer ]
We can only say that we are happy with the Nucleus OS and we use
the TI Code Composer Studio.
- Scott Constien of Enfora LP
Nucleus is good.
- [ An Anon Engineer ]
Nucleus IDE tool is poor than Wind River. I had used Wind River
before. It is a good IDE environment. Now, we use Trace 32 to
debug our target.
- [ An Anon Engineer ]
I like the simplicity, modularity & source understandability of Nucleus.
Our company does the system development and then transfers it to our
customers, so initial settings of tool have influences to customer's
further application development. So far, there were many satisfactions
from our customers specially about Nucleus: especially it being royalty
free and its source disclosure policy.
The major dissatisfactions of I have with VxWorks are its complex
parameter INCLUDE/EXCLUDE, problem from hidden source, and royalty burden.
Nucleus may be best for general purpose embedded system like real time
communication terminal. I do not know if it is good for network equipment
like router or network control server. We use the Nucleus kernel, libs,
debugger EDGE. Others: Wind River VxWorks, MontaVista.
- Dong Hyun Ahn of ETRI Korea
I do not think the Nucleus tool set if better than VxWorks. The Wind
River VxWorks toolset is lot better. Reason why we have selected Nucleus
is because of prior experience and good ARM processor support.
Pros
1. We have prior experience with Nucleus (used it for more than 10 years)
2. Nucleus has good ARM processor support
3. Integrated environment is a good feature
Cons
1. Their document especially with reference to integrating with third
party packages is not good. Examples are RVCT tools from ARM,
Multi-ICE from ARM, Multi-Trace from ARM, etc.
2. The Nucleus operating system quality has gone down a lot. There are
many fundamental bugs in the code which were not there few years ago.
We use Nucleus EDGE, RVCT tools, Multi-ICE, Multi-Trace, Profiler.
- Rajesh Arra of Bayer AG
I have used Wind River Tornado IDE. Although we had our share of
problems, after getting through the start-up pains, the Wind River
tools where very reliable and useful.
I have been using CodeLab/Partner-J for a couple of years. It has some
limitations that we can live and I find it to be a very useful tool when
it works. However, it does not work reliably. It can sometimes be
difficult or impossible to connect to, it may randomly disconnect, or a
sometimes come up with an "Oops" message and suddenly close. In
situations where there is connection difficulties, often times the only
solution is to re-boot my PC (host machine).
I have been involved with embedded software development for 15-20 years.
I have worked with a number of emulators, from 8 bits to 32 bits. I've
used tools from most of the major players in the embedded industry
(Motorola, Intel, TI, and a bunch more). I have used tool directly from
the chip vendors and third party tools. All of these tool have their
quirks and strange behavior. During course of development you eventually
come to understand them and learn to live this behavior. However, in all
my years I have not seen anything as unreliable as CodeLab/Partner-J. I
would not recommend this product to anyone.
Having said all that, I would still consider ATI/Nucleus development
products in the future. The support from ATI/Nucleus is much better
than most in the industry, including Wind River. At the time (4-5 years
ago) I found Wind River support was not very good.
- Steve Robertson of Zoll Medical Corp.
What do I think about the Mentor embedded tool suite Nucleus? Good.
How does it rank vs Wind River and Green Hills? Is Nucleus better
or worst? Better. What embedded tools do you use? Trace 32.
- [ An Anon Engineer ]
I have no background with Wind River or Green Hills. But I know from
the GBT project that the Wind River OS had a very detailed and well-
tested BSP package for the PPC and its various peripherals. For the
Nucleus we had to develop most of our BSP on our own; not necessarily
a knock on Nucleus, depending on what the costs were for the package.
The Mentor Edge tool suite has some challenges; mainly with performance
of the debugger. I would say the editor needs some additional work as
well. I am missing some of the features that are available in standard
eclipse (with the C/C++ IDE plugin). It has tabs vs. spaces in the
source file. The tagging support seems very intermittent. Sometimes
it tells me the function prototype by hovering, most of the time it
does not. A pre-build step would be handy in the compiler project
settings. The post-build step works great.
The Nucleus documentation was misleading (and flat out incorrect) for a
few functions. If this occurred in a number of the limited functions
we used, then I can only presume there are a fairly high number of
incorrect return values, etc. throughout.
The NET library, from my point of view, had quite a few little bugs in
it. Overall it does a nice job, but we did a lot of "testing" for them,
regarding the NET -- primarily the NET semaphore and port management.
- Rod Collins of Sensis Corp.
We selected Nucleus for our ColdFire based embedded systems several
years ago and after we put together an interrupt handling procedure
for our very low latency requirements, the RTOS has functioned very
well for us. A couple of years ago we added an ARM based device to
our product line and the ability to easily port to another processor
has been important.=20
How does it rank vs Wind River and Green Hills? We selected our RTOS
a long time ago, and at the time no royalty and completeness of the
Nucleus offering were the deciding points.
For embedded tools we use: ColdFire (5307,5407) Diab compiler, SDS
Single Step (now both from Wind River), ARM RealView, ColdFire (5484),
Gnu comiler, and the Gnu debugger with Abitron BDI2000.
- Kerry Shore of NextNet Wireless
ARM RealView for embedded SW development.
- [ An Anon Engineer ]
We use ARM RealView for our embedded SW development. No RTOS.
- [ An Anon Engineer ]
I've done a lot of embedded, most recently using an XScale/SOC, but have
never used these tools. I use stuff like gcc.
- Dave Chapman of Gold Mountain
I attended Mentor's Platform Express demo and saw a design assembly tool
that was full of pleasant surprises. The tool reads PX libraries, or
somewhat less capable SPIRIT structured libs, does self configuration
where it can, and interactively allows configuration of cores and
subsystems.
Some new features that were very helpful: the tool lets you build up
black-box forms out of known bus interfaces for modules not in the
library (the designer special sauce). The tool lets you configure and
same subsystems for reuse and export to other designs.
While the tool has been extended to cover SPIRIT described cores, it is
not bound by the unfortunate limitations of those cores; the extended
configuration choices of PX are also available. With the increasing
amount of IP available in PX and SPIRIT libraries, the assembly of
designs need not be error prone, and the extraction of information
(to create .h files, address maps, etc.) is nicely automated by the
extensible generator mechanism.
My company uses Platform Express daily for debug, verification, and
design assembly.
- [ An Anon Engineer ]
Index
Next->Item
|
|
