eLinux

eLinux

While UNIX is a wonderful operating system for workstations, desktops and servers, it suffers from several restrictions that prevented it from being used in the embedded system environment. It was large in terms of memory requirements both as main memory and virtual memory where hard disk storage is used to extend the amount of memory the system thinks it has. It makes a lot of assumptions about its environment that may not be true in an embedded system. How many embedded systems do you see with terminals and hard disks? These problems can be overcome but the real issue is the characteristics shown by the kernel. Yes the kernel is multi-tasking and yes it will support multiple users if needed but it does not support real-time operation. As a result, the embedded system community has largely excluded it from consideration. There were also problems with access to code, licensing, royalties that didn’t help its cause either.

Linux then appears and as it developed under the various licences that required easy access to the source code, it started to do several things. Firstly, it attracted a large applications base who ended up writing applications and drivers that were freely avail-able. At this point several people started to play with the kernel and its internals. Access was as simple as downloading the code from a web site and the idea of a version to support embedded designers started to come together.

The first thing that has to be remembered that while most real-time applications are embedded systems, not all embedded systems need real-time support. Taking this one step further, many designs actually need the ability to complete critical opera-tions within a certain time frame and need a “fast enough” system and not necessarily a real-time one. This is important as the processing power available to designers today is getting faster and faster and this means that the need to chase every last bit of processing power from the system is no longer needed and instead a faster processor and memory can be used. In this case, the margin between the time taken to complete the operation and when it needs to be completed is so great that there is no longer any need to have a real-time system. This has led to the introduction of non-real-time operating systems with fast processors as a viable alter-native for some embedded system designs. So the mantra of “it is embedded and therefore must need a real-time operating system” has been shattered. It is no longer such a universal truth and many designs can use non-real-time operating systems for an embedded design providing the software is designed to cope with the char-acteristics that the system provides. Indeed the last chapter goes through a design that does exactly that and uses MS-DOS with no multitasking or real-time capabilities as a real-time data logger.

This change coupled with the growth and confidence in Linux-based applications and systems has encouraged the use of Linux in embedded design. This has meant that embedded Linux has taken two development directions: the first concerns adapting the operating system to fit in a constrained hardware system with reduced amounts of memory and peripherals. This is based on stripping out as much of the software that can be done while maintaining the required functionality and this has dramatically reduced the amount of memory that is needed to run the operating system. Add to that support for RAM disks and other solid state memory technology such as flash and an ability to boot up system tasks without the need for a terminal connection and these basic problems are addressed. However, the next issue is not so easy and is concerned with modifying the Linux kernel to provide real-time support.

The standard kernel is multi-tasking and uses a sophisti-cated fairness scheme that will try and give a fair distribution and sharing of the processing time to the different tasks and threads that are running at the time. It is not pre-emptive in that a currently running task or thread cannot be shut down and replaced as soon as a higher priority task needs to run. So how can Linux be made to run real-time? There are three main methods.

1.                                                                   Run the standard kernel on a fast enough hardware. This can achieve some impressive figures for task switching (60 microseconds is not uncommon) but it should be remem-bered that a fast task switch does not mean that there is not some thread or task in the system that might block the kernel and prevent the system from working. This ap-proach requires making some risk assessments over the potential for this to happen. It is fair to say that Linux drivers and code tends to be consistently written following the recommended practices and that this gives a high level of confidence. However, in the same way that MS-DOS can be used for real-time embedded systems by carefully de-signing how the software is written and runs, the same can be done for Linux without changing the kernel.

Care needs to be taken however to ensure that there are no hidden problems and in particular tasks and drivers that can hog the execution time and block operations. As drivers are normally supplied in source code, they can be inspected (and modified if necessary) to prevent this. This does re-quire some level of expertise and understanding of how the driver was written, which can be a daunting prospect at first.

2.                                                                   Replace the standard kernel with a real-time version. This is a little strange in that one of the reasons why Linux is popular is because of the stability of its kernel and the fact that it is freely available. Yet this route advocates replacing the kernel with a real-time version. Several proposals have been made and have included the idea of using a standard RTOS and wrapping it so that it looks like a normal Linux kernel from a software perspective.

3.                                                                   Enhance the standard kernel with pre-emptive scheduling. In this case, the standard kernel is modified to allow block-ing tasks to be pre-empted and removed from execution.

Now the joy of working with Linux is that there are many keen developers ready to meet the challenge but this can lead to many different implementations. It is fair to say that there are several types of embedded Linux implementations available now that use different techniques to provide embedded support.

One method that is used with the TLinux/ TAI releases is to use a second kernel that has real-time characteristics and thus the operating system becomes a hybrid with normal Linux software running under the Linux kernel and real-time tasks running under the second real-time kernel. Communication between the Linux and RTOS worlds is performed using shared memory. This does work but is not as elegant as some purists would like in that why have the Linux kernel there in the first place and also it forces the software developer to classify software into the two camps. It is a suitable solution for very time critical applications where the Linux components are not critical and are restricted to housekeep-ing and other activities.

The alternative to a second kernel is to make the kernel real-time itself. It turns out that there is real-time support deep down in the kernel e.g. the SCHED_FIFO and SCHED_ calls that support up to 100 priority levels. The idea is that these priority levels are serviced first and then if there are no such tasks that need execu-tion then control can be passed to normal Linux tasks and threads via the standard scheduler. This provides a priority scheme but there are some restrictions. While the calls are present in the interfaces, this does not mean that the implementations actually support or enforce them. In addition, there is no pre-emption which means that a lower priority task or thread can still prevent a higher priority one from pre-empting and gaining control. However, providing the implementation does support these schemes, this can provide an improved real-time Linux environ-ment. Couple it with fast hardware and good interrupt latencies can be obtained.

So ideally, a pre-emptive version of the kernel is needed. It turns out that the standard SMP (Symmetric Multi Processing) version of Linux does just that and by modifying it slightly to support a single processor, it can become a transparent priority-based pre-emptive eLinux kernel. This is the approach that Monta Vista has taken with its eLinux support.

In summary, the restrictions that prevented eLinux from becoming a mainstream embedded RTOS have by and large been removed and eLinux is poised to become a dominant player in the RTOS market.