On Thu, Jan 14, 1999 at 11:26:37AM -0800, Marko Rauhamaa wrote:
> > i'm trying to decide between VxWorks and rtlinux for an RTOS project. i'd
> > like hear your comments concerning vxworks if you have experience with it
> > and why you're considering rtlinux.
>
> We are trying to decide between those two, too. We haven't used either
> in our products yet, but here are some of the points we have been
> considering:
We also are looking at OS choices, but are also looking at others (Lynx,
Chorus, any other suggestions?)
> - We may decide to use a MIPS clone for hardware reasons. VxWorks runs
> on MIPS. Linux does support MIPS, but MIPS is probably the least used
> Linux platform. Moreover, RT Linux would have to be ported to MIPS
> and I have no idea yet how big a task that would be (we might be
> willing to pay a fee if somebody did it, though).
>
> - AFAIK, VxWorks source code is not for sale. RTOS debugging is hard
> enough with source code, so not having it may make debugging much
> slower even if the bug is in our code. In addition, we may need some
> special tweaks of our own that may not be possible without the source
> code. The source code risk is increased by the fact that VxWorks is a
> single-source product.
We purchased VxWorks source for that reason. Single source is not really
a big issue once you have the source. VxWorks' code is remarkably
organized given the long time it's been in the market. Typically there's
a lot of cruft and fossilized code in this type stuff, but the
coding-standards that WRS has provided helped out a lot. Note that I
would _not_ _ever_ get VxWorks without source code; their support leaves
much to be desired. I've fixed a few bugs in the OS (none considered
'critical') with nary a thank-you from WRS. Needless to say, I don't send
them my bugfixes any more...
> - With RT Linux we can place soft-RT modules in the Linux sandbox. That
> means that we can add unexpected new features later without risking
> the functionality of the hard-real-time core. With VxWorks, as with
> most other RTOSes, new features may affect the whole system (although
> I hear VxWorks offers per-task memory management as an option).
For a small to medium sized system, I'd recommend VxWorks (but not
necessarily as an alternative to others, just a general recommendation
based on it's stability, and the development environment.) VxWorks,
however, is not reasonable for larger systems (> ~40 tasks).
At this level of complexity, there are too many tasks all sharing the
single address space, and per-task protection is almost a requirement.
(And contrary to Marko's statement above, though VxWorks _does_ have an
MMU option, they currently have no per-task protection, which is why we're
in the market for an OS...)
> - The function and feature list of VxWorks is impressive. Personally I
> find a bit risky, though, to have a single company develop and
> maintain such an amount of code. Most of those functions are used by
> hundred of thousands of people on the Linux side, so I tend to rely
> more on the quality of Linux. For example, we may even want to run an
> HTTP server on the processor -- VxWorks has it, but I'd rather run
> Apache under Linux.
Many of the features pulled into VxWorks came from 'freeware' type places,
or companies that had already have a VxWorks port of their feature. For
example, the IP stack came from the BSD code. Most of the stuff is
rather 'partitioned', so seems pretty stable. I still believe that once
VxWorks (or any OS, for that matter) gets beyond a certain number of tasks
sharing the same memory, problems ensue (one stray pointer causes the
whole system to fail.) It just doesn't scale well past medium sized
systems.
> - RT Linux allows soft-RT-interrupts (eg, communication with the host)
> to have a lower priority than critical RT tasks. I don't know if
> VxWorks allows this. I'm afraid it may be difficult to estimate the
> worst-case timing of VxWorks built-in device drivers.
Any tasks in VxWorks are prioritizable, so if there are lower-priority
jobs, just change their priority. You can either have run-to-completion
tasks, or round-robin.
Typically (communications-style) device drivers will have an interrupt
portion that drops work on the queue of a task. It's up the task to wake
up and handle the data at the appropriate rate. Another method we've used
is to just drop the data into memory, then kick a semaphore on a task to
pick up the data.
Not being up-to-date on Linux (and assuming traditional Unix), I don't
know how to get fine-grained control over process priorities in the
'linux' part of RT-Linux. Typically, 'nice' is all that there is, and
it's not good enough. Often one wants the 'functionality' available in
the Linux OS, but at a bit higher priority than, say, sendmail :-)
> - VxWorks is expensive.
Yep.
Regards,
Eric
--
Eric Peterson WB6PYK (818)878-4537 WORK: [EMAIL PROTECTED] HOME: [EMAIL PROTECTED]
PGP: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x4DA8EEF1
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
