Written by Tom on Tuesday 05/06/07
Memory Foot print.
With the networking stack and basic utilities, a complete Linux system runs quite nicely in 500 K of memory on an Intel 386 microprocessor, with an 8-bit bus (SX). Because the memory required is often dictated by the applications needed, such as a Web server or SNMP agent, a Linux system can actually be adapted to work with as little as 256 KB ROM and 512 KB RAM.
Another advantage Embedded Linux has over a traditional real-time operating system (RTOS), is that the Linux development community tends to support new IP and other protocols faster than RTOS vendors do.
The micro-kernel is a simple architecture. Networking and file systems are layered on top of the micro-kernel in modular fashion. Drivers and other features can be either compiled in or added to the kernel at run-time as loadable modules. This provides a highly modular building-block approach to constructing a custom embeddable system, which typically uses a combination of custom drivers and application programs to provide the added functionality.
Linux can run on most microprocessors with a wide range of peripherals and has a ready inventory of off-the-shelf applications.
Linux is also well-suited for embedded Internet devices, because of its support of multiprocessor systems, which lends it scalability. This capability gives a designer the option of running a real-time application on a dual processor system, increasing total processing power. So you can run a Linux system on one processor while running a GUI, for example, simultaneously on another processor.
The one disadvantage to running Linux on an embedded system is that the Linux architecture provides real-time performance through the addition of real-time software modules that run in the kernel space, the portion of the operating system that implements the scheduling policy, hardware-interrupts exceptions and program execution. Since these real-time software modules run in the kernel space, a code error can impact the entire system's reliability by crashing the operating system, which can be a very serious vulnerability for real-time applications.
What do you need to make it work.
A minimal Embedded Linux system needs just three essential elements:
• A boot utility
• The Linux micro-kernel, composed of memory management, process management and timing services
• An initialization process
To doing anything useful while remaining minimal, you also need to add:
• Drivers for hardware
• One or more application processes to provide the needed functionality
As additional requirements become necessary, you might also want:
• A file system (perhaps in ROM or RAM)
• TCP/IP network stack
• A disk for storing semi-transient data and swap capability
• A 32-bit internal CPU (required by all complete Linux systems)
Off the shelf components.
Busybox: is a software application which provides many standard Unix tools, much like the larger (but more capable) GNU Core Utilities. BusyBox is designed to be a small executable for use with Linux, which makes it ideal for special purpose Linux distributions and embedded devices. It has been called "The Swiss Army Knife of Embedded Linux".
BusyBox can be customized to provide a subset of over two hundred utilities. It can provide most of the utilities specified in the Single Unix Specification plus many others that a user would expect to see on a Linux system.
A full list of the utilities implemented can be found on the BusyBox site.
Typical computer programs have a separate binary (executable) file for each application. BusyBox is a single binary, which is a conglomerate of many applications, each of which can be accessed by calling the single BusyBox binary with various names (supported by having a symbolic link for each different name) in a specific manner with appropriate arguments.
BusyBox benefits from the single binary approach as it reduces the overheads introduced by the executable file format (typically ELF), and it allows code to be shared between multiple applications without requiring a library.
Sharing of this common code, along with routines written with size-optimization in mind, enables a BusyBox system to be much smaller than a system built with the corresponding full versions of the utilities replaced by BusyBox.
Programs included in BusyBox can be run simply by adding their name as an argument to the BusyBox executable:
More commonly, the desired command names are linked (using hard or symbolic links) to the BusyBox executable; BusyBox notices the name it is called as, and runs the appropriate command, for example just
after /bin/ls is linked to /bin/busybox.
TinyLogin: is a suite of tiny Unix utilities for handling logging into, being authenticated by, changing one's password for, and otherwise maintaining users and groups on an embedded system. It also provides shadow password support to enhance system security. TinyLogin is, as the name implies, very small, and makes an excellent complement to BusyBox on an embedded system (though it can of course be used without).
Ash: Ash is a very small Bourne shell.
Sysvinit: Sysvinit is the most used init package for Linux.
Microwindows: An Alternative to X
In most embedded designs, the X Window System is overkill, especially when running a dedicated graphics application. For this reason, the Microwindows Project was developed (http://microwindows.org). Microwindows is an open source project aimed at producing desktop-quality graphics functionality for small devices. The architecture allows for ease in adding different display, mouse, touchscreen and keyboard devices, as explained below. Starting with Linux version 2.2, the kernel contains code to allow user applications to access graphical display memory as a framebuffer, which ends up being a memory-mapped region in a user process space that, when written to, controls the display appearance. This allows graphics applications to be written without having to have knowledge of the underlying graphics hardware, or use the X Window System. This is the way that Microwindows typically runs on embedded systems.
Real Time versus Hard Real Time.
The definition of real-time here varies quite a bit. To some people, real-time means responding to an event in the one-microsecond range, to others it is 50 milliseconds. The hardness of real-time also varies quite a bit. Some systems need hard real-time response, with short deterministic response latencies to events.
RT-Linux (Linux with real-time extensions) contains time critical functions to provide precise control over interrupt handling, through the use of an interrupt manager, and does a good job of making sure that critical interrupts get executed when needed. The hardness of this approach depends mostly on the CPU interrupt structure and context-switch hardware support. This approach is sufficient for a large range of real-time requirements. Even without the real-time extensions, Linux does pretty well at keeping up with multiple streams of events. For example, a Linux PC system on a low end Pentium is able to keep multiple 10BaseT interfaces executing effectively, while simultaneously running character-level serial ports at a full 56KBPS without losing any data.
Short deterministic response latencies defined.
Some real-time embedded systems need to respond quickly to external events in order to accomplish a specific task. A custom microcontroller embedded inside a missile, for example, needs to respond quickly to external events such as moving targets, weather, humans, etc., before instructing the missile to target a specific object in its surrounding environment. Short deterministic response latencies mean that the embedded system can determine the time it will take to respond to an external event.
I do not claim any originality in this article.