Embedded Linux = RTOS ??

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Can someone give an answer on this?

Many vendors claim that their boards run embedded linux, but is this a real
RTOS or a stripped down version of the full version ?


Re: Embedded Linux = RTOS ??
Quoted text here. Click to load it

IMHO, most of them are stripped down version of the full version.

Some usese some "low latency" patches to get nearly RTOS features, some
uses RTLinux or RTAI to get real RTOS features.


Bernhard Roessmann
Don't Fear The Penguins!

Re: Embedded Linux = RTOS ??
Quoted text here. Click to load it

Embedded Linux is just as much of a real-time operating system as Linux.
(i.e. not at all).

RTLinux offers some reasonable guaranteed real-time behaviour by putting
an RTOS kernel "under" Linux.

snipped-for-privacy@fenelon.com "how many clever men have called the sun a fool?"

Re: Embedded Linux = RTOS ??
Quoted text here. Click to load it

You can usually infer things about the "RTOSness" of the software
bundle from the intended application and the price. Saying "we bundle
embedded Linux" is a bit like saying "we will provide you with a
compact car" - it covers a lot of possible models and optional
features. You have to evaluate these things on a case-by-case basis.
But in general Linux != RTOS, though it is realtime enough (especially
on over-speced hardware) for many tasks that nominally demand an RTOS.

Re: Embedded Linux = RTOS ??

"Sagaert Johan" <sagaert.j AT belgacom.net> wrote in message
Quoted text here. Click to load it

Linux is not an RTOS (unless it is using one of the real-time extensions for
linux), but you must decide whether you actually need an RTOS or just an OS
with reasonably predicatable timings.  The point of an RTOS is that you can
guarentee that time-critical events occur within specified time limits.  If
you really need that, you have to consider closely whether you want to do
that kind of guarentee analysis on a complete system, or whether you should
be splitting off a small, carefully controlled sub-system that must be
real-time, and have the rest running a low-latency general OS like linux
(definitely go for 2.6 kernel with low-latency patches).  You don't get
real-time guarentees, but you get close enough for many embedded systems.

As to whether the embedded linux version is stripped down or not, that
depends entirely on what you expect from a "full version".  Many linux
distributions come on several CD's - in comparison, of course it will be
stripped down.  But you are likely to have some basic utilities (most often
busybox for common command-line utilities), maybe a webserver (such as boa)
and other bits and pieces.  As for the kernel, it is unlikely to be compiled
with support for all the functionality available in linux, but you should be
able to compile your own kernel if you need something (say, samba support,
or advanced network functionality) that is not in the provided kernel.  The
most likely "stripped down" aspect is that if it is compiled to run on a cpu
without an mmu (such as on a Coldfire, or ARM7), then the kernel will be a
"ucLinux" kernel.  If you don't have an mmu, then there is no hardware
protection between processes - there's no way round that limitation.

Re: Embedded Linux = RTOS ??

Quoted text here. Click to load it

True, Linux != RTOS. However, you can make the point moot. If you enable nested
interrupts in your hardware and perform your needed work at interrupt time,
you essentially solve the real time problem without throwing the baby out
with the bathwater. Linux does not control the interrupt level, thats up to
you as a device implementor. Using a *properly* sculped nested interrupt
system, you can have device interrupts perform critical services, then enable
interrupts and take care of real time needs while still allowing other, critical
interrupts to take place. The result is that the devices that need real time
servicing get it, and Linux runs above this real time layer with no ill effect.

Certainly an RTOS is neat to get real time threading going. However, depending
on criticality of device service and latency, even in an RTOS, it may be wise
to service at the interrupt level without cascading into a formal context,
which is costly on any system, RTOS or otherwise. A good RTOS implementation
is going to combine nested interrupts, careful sculpting of interrupt exclusive/
non-exclusive sections, and real time contexts. Depending on the device type,
interrupts can be serviced by immediate, exclusive interrupts, by nested
interrupts, or by changing the interrupt to a context/thread.

Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline