Embedded Operating Systems for Real-Time Applications

Presented by Tufail Bashir Mir (1TJ08EC101) Under guidance of Mrs. Binu Singh

INTRODUCTION
 An embedded system is a combination of hardware and software and perhaps other mechanical parts designed to perform a specific function.  An embedded system is generally a system within a larger system. Modern cars & trucks contain many embedded systems. One embedded system controls anti-lock brakes, another monitors & controls vehicle s emission & a third displays information on the dashboard.  Even the general-purpose personal computer itself is made up of numerous embedded systems. Keyboard, mouse, video card, modem, hard drive, floppy drive & sound card are each an embedded system.  One major subclass of embedded systems is real-time embedded systems. A real time system is one that has timing constraints.  Real-time system s performance is specified in terms of ability to make calculations or decisions in a timely manner. These important calculations have deadlines for completion. A missed deadline is just as bad as a wrong answer. The damage caused by this miss will depend on the application. For example if the real-time system is a part of an airplane s flight control system, single missed deadline is sufficient to endanger the lives of the passengers and crew.

INSIDE AN EMBEDDED SYSTEM

All embedded systems contain a processor and software. The processor may be 8051 micro-controller or a Pentium-IV processor (having a clock speed of 2.4 GHz). Certainly, in order to have software there must be a place to store the executable code and temporary storage for run-time data manipulations. These take the form of ROM and RAM respectively. If memory requirement is small, it may be contained in the same chip as the processor. Otherwise one or both types of memory will reside in external memory chips. All embedded systems also contain some type of inputs and outputs .
MEMORY

INPUT

PROCESSOR

OUTPUT

Generic Embedded System

common critical features and design requirements of an embedded hardware

 Processing power: Selection of the processor is based on the amount of processing
power to get the job done and also on the basis of register width required.

 Throughput: The system may need to handle a lot of data in a short period of time.  Response: The system has to react to events quickly  Memory: Hardware designer must make his best estimate of the memory requirement
and must make provision for expansion.

 Power consumption: Systems generally work on battery and design of both software
and hardware must take care of power saving techniques.

 Number of units: The no. of units expected to be produced and sold will dictate the
trade-off between production cost and development cost

 Expected lifetime: Design decisions like selection of components to system

development cost will depend on how long the system is expected to run.

 Program Installation: Installation of the software on to the embedded system needs

special tools.

 Testability & Debugability: Setting up test conditions and equipment will be difficult
and finding out what is wrong with the software will become a difficult task without a keyboard and the usual display screen.

 Reliability: Is critical if it is a space shuttle or a car but in case of a toy it doesn t always
have to work right.

WHAT IS AN OPERATING SYSTEM

The operating system organizes and controls the hardware and it is that piece of software that turns the collection of hardware blocks into a powerful computing tool. Broadly the tasks of the Operating system are:

 Processor Management: The main tasks in processor management are ensuring that each
process and application receives enough of the processor's time to function properly, using maximum processor cycles for real work as is possible and switch between processes in a multi-tasking environment.

 Memory and Storage Management: The tasks include allotting enough memory required
for each process to execute and efficiently use the different types of memory in the system.

 Device Management: The operating system manages all hardware not on the computer's
motherboard through driver programs. Drivers provide a way for applications to make use of hardware subsystems without having to know every detail of the hardware's operation. The driver's function is to be the translator between the electrical signals of the hardware subsystems and the high-level programming languages of the operating system and application programs. One reason that drivers are separate from the operating system is for upgradability of devices.

 Providing Common Application Interface: Application program interfaces (APIs) let the
application programmers use functions of the computer and operating system without having to directly keep track of all the details in the CPU's operation.

 Providing Common User Interface: A user interface (UI) brings a formal structure to the
interaction between a user and the computer. Recently all developments in user interfaces have been in the area of the graphical user interface (GUI).

Types of Operating systems

Four types of Operating systems, based on the kind of applications they support are: i) Single-user, single task - This operating system is designed to manage the computer so that one user can effectively do one thing at a time. The Palm OS for Palm hand-held computers is a good example. ii) Single-user, multi-tasking - This is the type of operating system most of us use on our desktop and laptop computers today. Windows 98 and the MacOS are examples of OS that let a single user have several programs in operation at the same time. iii) Multi-user - A multi-user operating system allows many different users to take advantage of the computer's resources simultaneously. The operating system must make sure that the requirements of the various users are balanced, and that each of the programs they are using has sufficient and separate resources so that a problem with one user doesn't affect the other users. Unix is an example of multi-user operating system. iv) Real-time operating system (RTOS) The main task of a RTOS is to manage the resources of the computer such that a particular operation executes in precisely the same amount of time every time it occur.

REAL-TIME OPERATING SYSTEMS

o Real-time computing is where system correctness not only depends on the correctness of logical result but also on the result delivery time. o So the operating system should have features to support this critical requirement to render it to be termed a Real-time operating System (RTOS). o The RTOS should have predictable behaviour to unpredictable external events. A good RTOS is one that has a bounded (predictable) behaviour under all system load scenario i.e. even under simultaneous interrupts and thread execution . o A true RTOS will be deterministic under all conditions. o These operating systems occupy little space from 10 KB to 100 KB as compared to the General Operating systems which take hundreds of megabytes. o Real-time systems in which missing a deadline is catastrophic are called Hard Real time systems. If systems allow deadlines to be missed at times and still can be recovered they are called Soft Real-time systems.

WHY OPERATING SYSTEMS FOR REAL-TIME APPLICATIONS

Operating system is not a required component of any computer system. A simple microwave oven does not require an operating system. But as the complexity of applications expands beyond simple tasks the benefits of an operating system far outweighs the associated costs. Since embedded systems (PDAs, cell phones, VCRs, industrial robot control, or even the toaster) are becoming more complex hardware-wise with every generation, & more features are put into them in each iteration, applications they run require more and more to run on actual operating system code in order to meet the system response requirements . Real-time Operating System allows real-time applications to be designed and expanded easily. Functions can be added without major changes to the software. The use of an RTOS further simplifies the design process by splitting the application code into separate tasks. With a pre-emptive RTOS all time critical events are handled as quickly and efficiently as possible. An RTOS allows one to make better use of the system resources by providing valuable services such as semaphores, mailboxes, queues, time delays, time outs etc.

FEATURES NEEDED IN A GOOD EMBEDDED RTOS

 Operating System Architectures  Process -Thread -Task model  Task & Task States  Scheduler  Tasks and Data  Task Synchronisation & Inter task Communication  Interrupts  Memory management

Operating System Architectures

Monolithic Operating System:

APPLICATION PROGRAMS APPLICATION PROGRAMS

USER MODE KERNEL MODE

SYSTEM SERVICES

HARDWARE

Operating System Architectures(CONTD )

Layered Operating System:

APPLICATION PROGRAM RESIDENT SYSTEM PROGRAM MS-DOS DEVICE DRIVERS ROM BIOS DEVICE DRIVERS HARDWARE

Operating System Architectures(CONTD )

Client server operating system:

MEMORY SERVER PROCESS SERVER NETWORK SERVER

CLIENT APPLICATION

FILE SERVER

DISPLAY SERVER

USER MODE KERNEL MODE

MICROKERNEL HARDWARE

Process -Thread -Task model

A multi-tasking concept is essential if one wants to develop a good real time application. Indeed an application has to be capable of responding in a predictable way to multiple simultaneous external events arriving in uncontrolled way. If only one processor is used we have to introduce pseudo parallelism called multitasking . The application running on a system is subdivided into multiple tasks. In complex systems like UNIX, the system is considered to be consisting of different processes. Here the context in each process is very heavy resulting in large switching times. This approach was changed due to: i) Implementing multitasking approach, which is a requirement in complex distributed software, is too heavy in a process model. ii) Bringing Real-Time and non-Real-Time world together, which the POSIX standards were aiming at, is not easy using a process concept. Thus, the concept of thread was brought in, which is like a light-weight process. A thread inherits the context of the process but uses only a subset of it so that switching between threads can be done quickly . Today in a Real-time environment a process is an application subdivided into tasks or threads.

Task & Task States

Task is the basic building block of software written under an RTOS. Each task in RTOS is in one of the following three states (Fig. ) 1. Running: The microprocessor is executing the instruction that make up this task. In single processor systems only one task is running at a time. 2. Ready: means that some other task is running but this task has things that it could do if processor becomes available. 3. Blocked: this task has nothing to do right now even if microprocessor becomes available. Tasks get into this state because they are waiting for some external event. For example a task that handles data coming from a network will have nothing to do when there is no data.
BLOCKED READY

RUNNING

Task States

Scheduler
The heart and soul of any operating system is its scheduler .Some of the common scheduling algorithms used in mainstream operating systems are First-in-first-out [FIFO] scheduling is used in DOS, which is not a multitasking operating system. Here each task runs until it is finished and only after that next task is started. In shortest job first scheduler each time a running task completes or blocks itself, next task selected is one that will require the least amount of processor time to complete. Round robin is the only scheduling algorithm of the three in which the running task can be pre-empted, that is, interrupted while it is running. Unfortunately embedded operating systems cannot use any of these simple scheduling algorithms. Embedded systems, particularly real-time systems, almost always require a way to share the processor that allows the most important tasks to grab the control of processor as soon as they need it.. Therefore most embedded operating systems utilize a priority based scheduling algorithm that supports pre-emption . We also need that interrupt handling in case of different simultaneous interrupts should be handled in a pre-emptive way. There is also necessary to have a backup scheduling policy. This is the scheduling algorithm to be used in the event that several ready tasks have same priority. The most common backup algorithm used is the round robin. The actual process of changing from one task to another is called a context switch. Since the contexts are processor-specific, the code that implements this is also processor-specific. So it is always written in assembly language.

Tasks and Data

Each task has its own private data [includes register values, Program Counter and stack]. All other data like global, static, initialized, un-initialised etc is shared among the tasks. A situation like this can lead to many of shared data problems. If task1 calls a function ReadX for reading a shared data that is being modified by task2, there is a chance that data read by task1 is erroneous . RTOS DATA STRUCTURES RTOS ALL OTHER DATA REGISTERS READX TASK 1

TASK 2

TASK 3

STACK

STACK

Task Synchronisation & Inter task Communication

There are several tools available in RTOS to enable inter task communication and task synchronisation  Semaphores: Semaphores are inter task communication tools used to protect shared data resources. Tasks can call Take-Semaphore and Release-Semaphore functions. If one task has called TakeSemaphore and has not called the Release-Semaphore to release it, then any other task that calls Take-Semaphore will block until first task calls Release-Semaphore. Semaphore can also act as a signalling device for synchronisation. When using Semaphores, one should ensure that it does not lead to Priority inversion or Deadly embrace .  Message Mailboxes: Messages are sent to a task using kernel services called message mailbox.  Message Queues: is used to send one or more messages to a task. Basically Queue is an array of mailboxes.  Event Flags: basically these are Boolean flags which tasks can set or reset that other tasks can wait for.

Interrupts and Memory management

An interrupt is a hardware mechanism used to inform the CPU that an asynchronous event has occurred . When CPU recognizes an interrupt, it saves its context and jumps to a subroutine known as Interrupt Service routine (ISR).Upon completion of the ISR the program returns to a) The background in the case of foreground/background system b) Interrupted task in case of a non-pre-emptive kernel c) The highest priority task that is ready to run in case of a pre-emptive kernel. Each OS needs to disable interrupts from time to time to execute critical code that should not be interrupted. A good RTOS should have shortest Interrupt latencies, interrupt responses and interrupt recovery times. Each programs need to held in a memory generally in a ROM to be executed. The task data (stack and registers) and all variables must be stored in RAM. In a real-time system the main requirement is that the access time should be bound or predictable. The use of demand paging is not allowed since the systems providing virtual memory mechanisms use memory swapping which is not predictable. RTOS have fast and predictable functions to allocate and free fixed size buffers. RTOS allows to setup pools each of which consist of same number of memory buffers.

Why general purpose OS is not suitable for embedded RTOS

a) There are only 7 priority levels & there is no mechanism to avoid priority inversion b) The Queue of threads waiting on a semaphore is held in a FIFO order. Here there is no regard for priority, hampering the response times of highest priority tasks. c) Though ISR responses are fast, the Deferred Procedure Calls (DPC) handling is a problem since they are managed in a FIFO order. d) The thread switch latency is high (~ 1.2 ms), which is not acceptable in many realtime applications. Few important RTOS: VxWorks (Wind River Systems): used for targets processors. QNX RTOS v6.1: supports Intel x86family of processors, MIPS, PowerPC, and Strong ARM. VRTX: queues (TX speed more & RX speed less) CHIMERA: Robotics.