Embedded Operating Systems

Introduction

• A simple embedded system is

  
  	while true
  	    read a value from an I/O port
  	    do something
  	

• A more complex one might have to poll several devices

  
  	while true
  	    select a ready I/O device
  	    read a value from the I/O port
  	    do something
  	

• Doing something might involve memory access

  
  	while true
  	    read a value from an I/O port
  	    get an unused chunk of memory
  	    do something with this memory
  	    release memory
  	

• It may involve multitasking

  
  	while true
  	    select a thread
  	    in this thread
  	        read a value from an I/O port
  	        do something
  	

• It may involve handling interrupts from devices

  
  	set up interrupt handlers
  	while true
  	    do something
  
  	handler1:
  	    disable interrupts
  	    process interrupt from device1
  	    enable interrupts
  	

Functions of an O/S

An O/S is required when the complexity of functions to be done gets too high for one-off programming

• An O/S can use a device driver, which gives a higher-lever software interface to a device than is given by the manufacturer
• An O/S can supply interrupt handling mechanisms and polling mechanisms to deal with asynchronous and synchronous device handling
• An O/S supplies memory management routines to gain and free memory
• An O/S running on protected mode hardware can use virtual memory to protect memory in one process from another one
• An O/S can look after task/process/thread scheduling
• An O/S supplies a software abstraction layer (the O/S API - Application Programmers Interface) that can be used to
  • manage memory
  • manage proceses
  • manage devices

Typical O/S

MSDOS

MSDOS was the precursor of Windows. Is is designed for the 8086, an unprotected mode processor with 1M address space. MSDOS will run in only 64k. It is a primitive O/S, but is used very heavily for embedded applications which don't have complicated or heavy requirements. It is used in about 15% of embedded systems in 2001

Windows 3.1

This was an application layer on top of MSDOS that added task switching to MSDOS. It has no use for embedded systems

Windows NT, Windows 2000, Windows XP

These are all protected mode O/S built on good O/S principles. In their standard form they are not suitable for embedded systems because

• They require a graphical user interface, which will not be present on e.g. a sprinkler
• They have a lot of "baggage" which is usually not needed for an embedded O/S e.g. most of the device drivers will not be needed
• They are not realtime, with unpredictable amounts of time before a task is scheduled
Windows CE (Compact Edition) was used in about 10% of embedded systems in 2001

Linux

This is a protected mode O/S built on good O/S principles. It uses a standard API, defined by POSIX. In its standard form it is not suitable for embedded systems because

• It has a lot of "baggage" which is usually not needed for an embedded O/S e.g. most of the device drivers will not be needed
• It is not realtime, with unpredictable amounts of time before a task is scheduled

Linux was used in about 12% of embedded systems in 2001

Dedicated Realtime/Embedded O/S

• An O/S designed for embedded systems is usually designed for several different criteria
  • It must run on a number of processors
  • It may need to run in very small memory configurations
  • It may need to support realtime applications
• There are a number of commercial O/S's that meet these criteria including
  • VxWorks (about 18% in 2001)
  • QNX (about 5% in 2001)
  • LynxOS (about 5% in 2001)
  • Symbian - used in nearly all mobile phones using an O/S (in 2003)

Typical O/S sizes

• Some minimal configurations:
  • LynxOS: 150kb
  • BlueCat Linux: 260kb
  • Windows XP Embedded: 5Mb
• Some typical configurations:
  • LynxOS: 250kb
  • Linux: 500kb
  • Windows XP Embedded: 15Mb

Scheduling algorithms

• A non-realtime system can use a scheduling algorithm such as

  
        schedule:
            update status of all processes
            choose runnable process with highest priority
            restart this process
  
        interrupt:
            set interrupt flag on process
  
        update process:
            if interrupt set, set status to runnable
            increase priority of process
        

• The non-realtime scheduler will place processes in a priority list, and run a process when it has the highest priority
• A realtime system cannot afford these delays in processing interrupts. A realtime system might adopt a scheduler such as

  
        interrupt:
            process for this interrupt pre-empts current process
        

• Realtime scheduling algorithms are discussed in Stallings

Making non-realtime into realtime

• A trick can be used to make non-realtime systems such as Linux into realtime systems: run two schedulers
• The first scheduler handles all non-realtime processes, and is the usual Linux scheduler
• A second scheduler is a realtime scheduler, and handles all hard realtime processes
• The realtime scheduler runs the Linux scheduler as the default task, which can be interrupted by an realtime process
• When no realtime processes are running, the "ordinary" Linux processes are run

O/S boot sequence

When a system starts up, the hardware goes through an initialisation phase and then jumps to a fixed address to start the O/S. On a PC-like system for Linux, this is

References

• R. Lehrbaum Bully in the (embedded) playground, pp52-57, March 2002, Linux Journal
• W. Stallings Operating Systems - internals and design principles, Prentice-Hall
• IEEE standard POSIX
• P.M. Adams Writing Unix Device Drivers in C, Prentice-Hall
• M. Beck et al Linux Kernel Internals, Addison_Wesley