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?
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
visi.com hours a day!
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
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
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..
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.