Embedded Operating Systems

It is difficult to imagine an embedded device, such as a control system in a factory, running an OS, especially when our picture of OSs is one of the MS Windows, Mac OS or Linux. But from a technical perception, there is a question that arises. Why cannot a device, which is doing something logical and systematic, have an OS? If there is no OS, how is the device able to accept inputs, manage tasks it may need to perform and how does it output?

Here is the fact. Most embedded devices have the OS and the programs burnt into their hardware circuitry. Most do not run anything as general purpose as one that can be called an OS. These devices may be doing such specific tasks that it may require only a very few operating instructions. In such cases, these few instructions are just burnt into the circuitry. A single program may be burnt which does both, the operating part as well as the application part. Hence, it becomes difficult to say that the device is actually running an OS on top of which other application(s) are running.

Having said that, the moment a device needs to do something more than very specific tasks, they run an apparent OS and this OS can even be Windows or Linux. Yes, you read it right. The only difference is, the embedded devices will run the scaled down versions of these OSs, which better fit their memory and processing capabilities. Besides these, there are more than a couple of OSs specifically developed for embedded devices. In the remaining article, we jot down some embedded OSs available. We start with the embedded flavors of the OSs we are familiar with.

Windows for embedded



It all began with Windows CE, which is currently at version 5. Earlier, the choice of Windows for non-computer devices was only Windows CE. But now we have Windows Mobile, Win XP Embedded and Windows Automotive. All these have bifurcated out of Windows CE for different target devices. The core still remains Windows CE.

Windows Mobile is the OS for smart phones such as Xphone II from O2 or for PDAs such as those of HP iPAQs. The latest version of Windows Mobile is 2005, which was out about a month back. Therefore, you will find most PDAs and phones using Windows Mobile 2003 Second Edition.

Now Windows Embedded is an OS for the niche market of POS (point-of-sale) terminals, thin clients and set-top boxes. To reduce the footprints, Windows Embedded gives a choice from amongst ten thousand components. That is, depending on the features that need to be deployed on the embedded device, a developer can choose the specific components of the OS, thereby not deploying a full-fledged version, which will require larger memory and more processing.



Last but not the least, there is Windows Automotive. An OS meant for a connected (to the Net) car, which can be controlled via speech. Some of the features of this system includes traffic alerts based on the current route, vehicle theft tracking, hands-free communication using speech recognition technologies, music downloads and access to e-mail and Web on the move.

The plus point of the Windows OSs for embedded devices is that they have the similar look and feel like the desktop counterpart-all begins from a start menu and things are controlled via the control panel. Also the latest OSs support the .NET technologies. This means easy development of application for the embedded devices and what's more, developers can still use the Visual Studio.NET to develop such application.

Linux for embedded



A lot of action is happening here with Linux-based handheld and cellphones making their debut. But the strong point of Linux and its kernel had been the modularization from day one. Which means, the Linux kernel is designed in such a way that all functionality can be incorporated by dynamically loading up modules. For example, if networking is required, TCP/IP support needn't required to be built in to the core kernel. Instead, a separate module for TCP/IP can be loaded up dynamically, and that too as and when required.

All this makes Linux very suitable for a wide range of embedded devices. The impression of Linux being able to run on legacy and less powerful hardware is also helping to push it in the embedded space which has similar requirements. There are many distributions and projects floating around for Linux for embedded.



uClinux (www.uclinux.org/) is a Linux distribution that can be deployed on microcontrollers. It supports a variety of microcontrollers or processors, which include those from Motorola, ARM and Intel. It is being used in devices such as IP telephones, routers and surveillance cameras (yes, you can log into a camera).

A commercial distribution of Linux tailored for embedded devices is BlueCat- www.lynuxworks.com/products/bluecat/bluecat.php3. It is based on the familiar and latest Linux kernel 2.6 and implements POSIX timers-which allows real-time signals or interrupts. It supports many processor architectures which includes Intel XScale, PowerPC, ARM and

MIPS.

Coming to computing devices, Linux is used in the home grown Simputer (www.simputer.org) handhelds and the latest Encore's Mobilis which is touted to be the sub Rs 15,000 notebook. And talking about mobile devices, Motorola cellphones such as A760 are powered by Linux.

Next we talk about a couple of OSs specifically meant for embedded devices.

Real Time OS for embedded



QNX (www.qnx.com) was originally developed as a RTOS (real time operating system) for embedded systems that are intended to respond in real time. These devices operate in real time, meaning that the time delay between the input and the output is predictable, unlike non real-time devices where this time can't be determined. So, the better the 'responsiveness' of the instruction set of an OS, the better is its real-time response. OSs like QNX that enable embedded devices to run in real-time came to be called real time OSs. Such OSs are very small in size, making it possible to fit them on small solid state memory modules.



QNX later branched off as a platform OS that runs on ordinary desktop computers.

The real time version of QNX is known as Neutrino, which is the base for the RTP and on which the features of a platform OS are added.

The Neutrino has a microkernel (that is, a small core of the OS) architecture. The kernel handles the main services such as threads, messaging, condition variables, signals, and scheduling, within the OS. Neutrino, in specific, provides multitasking, threads, priority-driven preemptive scheduling, and fast context switching. Other processes related to end-user applications will access these services from the kernel. Since the microkernel is very small, it's quicker in handling things. It doesn't have services like file systems, device I/O, and networking, that are normally found in conventional OS kernels. Instead, it has optional processes to provide these services. In fact, even the process manager is an optional component.

QNX is used in manufacturing plants, automotives, medical equipments and in defense systems. For more information refer to

www.qnx.com/markets/index.html.

Inferno



Inferno was developed by Computing Science Research Center of Bell Labs. Its core feature is a virtual machine called Dis which makes it portable across various platforms, including Intel x86, Sun Sparc, MIPS and PowerPC. So it can be used across all the major OSs like Windows, and many flavors of UNIX including Linux. Inferno runs as a service under these OSs. It also has its own microkernel, so it can be deployed on embedded devices without a native operating system underneath.

Inferno's memory requirements are as low as 1 MB-possible due to its modular architecture. All user applications as well as core services of Inferno are available as modules that can be dynamically loaded into the memory when required. Likewise, they can also be unloaded and the memory area reclaimed for subsequent use by a service called Garbage Collector that continuously runs in the background.

Inferno can be used in a distributed environment, a necessary feature so that all the intelligent gadgets can communicate with each other. It uses a communication protocol called Styx, which runs above the transport layer and is independent of transport layer protocols like TCP and UDP. Styx has built-in security using Public

Key Cryptography for communication.

Under Inferno, all services like network services are represented as files, which can be written (inputs) and read (outputs). The same scheme is adopted to represent I/O devices attached to the gadgets, which can use a variety of input and output devices ranging from simple keypads, touch screens to radio-wave based I/O. The interface to all these devices is also represented as files. This makes it easy for developers, as they can be read or written without worrying about the complexity (or simplicity) of the device.

As far as developing for this platform goes, a new programming language called Limbo is used to develop Inferno applications. Limbo borrows its syntax from C and Pascal, and is ideal for coding multitasking applications. The library functions that can be used while programming are also available as modules. Limbo programs when compiled result in byte codes which are instructions to the virtual machine Dis. At runtime, Dis translates the byte code instructions to those of the native OS of the embedded device. An on-the-fly compiler is also available which converts byte codes directly into native instructions thus boosting the execution speeds.

We have only touched the surfaces. There are a plethora of OSs available for embedded devices-open source, closed source, free as well as commercial. The decision to use which OS depends on the platform architecture of the embedded device, scalability, connectivity and cost.