Stupid question,

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

Translate This Thread From English to

Threaded View
Having written some simplistic embedded applications (purely hobbyist type
stuff) I am curious, what are the advantages of running an OS on an
embedded device? Typically my embedded apps take the form of an endless
loop and I will check pins, execute some code... When is this model no
longer adequate for embedded projects?  

Re: Stupid question,

Quoted text here. Click to load it

When you need two or more endless loops, each of which needs to
wait for an event (input data from an A/D or serial port, a
timer, etc.) to happen at some point in the loop.

--
Grant Edwards                   grante             Yow!  In Newark the
                                  at               laundromats are open 24
We've slightly trimmed the long signature. Click to see the full one.
Re: Stupid question,
Quoted text here. Click to load it


You don't exactly need it, but it might make your work much easier.

If you want to do TCP/IP, USB or something like that with your embedded
device, it might save you 99 % work.

Moreover preemptive multitasking might help you to do a much easier
software design.

OTOH, you need to take care of protecting shared resources when allowing
preemptive multitasking.

Moreover Linux is not a real-time OS: it _might_ delay your program for
some 100 mSek. Only once every year, but you can't guarantee a minimum
latency.

If you need to guarantee a latency constrain, you might add RTAI (free,
too), that reintroduces hard realtime, while preventing the advantages
of Linux, but makes things more complicated, of course.

-Michael

Re: Stupid question,

Quoted text here. Click to load it

In your endless loop, if you have a device that needs some light
servicing say, every 1 ms and the others need some heavy servicing
about every 10-15 ms, you would have to run your loop once every
millisecond.

This would be far too often for the slow devices, so you would need
some logic to execute one slow device once e.g. every 7th cycle and
the other every 11th cycle, so most of the time these slow operations
would not be executed on the same cycle. But every 77th cycle they
would hit the same cycle and their total execution time might be
longer than 1 ms, which would harm the device needing service every
ms.  

Even if you create a sequence of 10 cycles and execute one slow
operation at cycle #5 and the other on cycle #10 in the sequence,
there is going to be problems, if the service time exceeds 1 ms.

You can of course create more and more complex algorithms to manage
these thinks, but sooner or later, the system becomes too complex to
be maintainable (e.g. add some new functionality or fix problems).

With a simple pre-emptable kernel (usually a few kilobytes), you can
assign a task for each device, such as a serial device or the real
time clock. When the device needs some servicing, it starts an
interrupt service routine, which kicks up the task servicing the
device, if the servicing takes longer than the time interrupts can be
blocked.

By giving the highest priority to the device that needs servicing
every 1 ms, this task will preempt the task servicing the device that
needs servicing every 10 ms.

Of course you can also use polled devices by including an endless loop
into each task, with a suitable sleep time to set the execution rate.
Thus, the poll rate can be tailored separately for the requirement for
each device. The priority and preemption mechanism will automatically
force the low priority tasks to yield, if a high priority task needs
servicing.

The system must become quite large and complex until it makes sense to
consider such highly complex operating systems as Linux. There is a
large gap between applications that can be done with a single endless
loop and running some form of embedded Linux. In my opinion, those
applications are best served with some simple pre-emptable kernels.

If your hardware resources allow it and you require a full support for
USB, full feature TCP/IP stack or other highly complex systems that
are already available in Linux, then of course, it is the easiest way
to use Linux.
 
Paul
 

Re: Stupid question,

Quoted text here. Click to load it


Hey, thanks for the replies, I doubt I will need ever to use embedded
Linux - I may run a system with it one day simply to tinker with.
Again, thanks for the info..

Re: Stupid question,
Quoted text here. Click to load it

To add - it can make it easier/almost trivial to reuse code.

If you'r running on a platform that basically has linux running on it
already, and you only have to write drivers for trivial stuff like
how to work your LEDs, or how the A/D converter for battery voltage works.

Complex stuff like writing PCMCIA drivers for wireless network cards, or
USB scanner drivers, can be 'free', once you've got the basics setup.

If instead of starting with a clean sheet of paper, you look at what
software packages already exist that may suit your needs, and then
fit the hardware around those, then you can in some cases nearly eliminate
writing software.

Linux to replace a 555 would probably be overkill.

At least for the next 10 or 15 years, when it's probably going to be
as cheap.

Site Timeline