Embedded Systems

By
Ms. Priya Vyavahare
 Real-Time Operating System Based Embedded System Design

Operating System Basics:

 The Operating System acts as a bridge
between the user applications/tasks
and the underlying system resources
through a set of system functionalities
and services
 OS manages the system resources and
makes them available to the
applications/tasks on the need basis
 The primary functions of an Operating
system is
• Make the system convenient to use
• Organize and manage the system
resources efficiently and correctly
The Kernel:
 The kernel is the core of the operating system
 It is responsible for managing the system resources and the communication among the
hardware and other system services
 Kernel acts as the abstraction layer between system resources and user applications
 Kernel contains a set of system libraries and services.
 For a general purpose OS, the kernel contains different services like
➢ Process Management
➢ Primary Memory Management
➢ File System management
➢ I/O System (Device) Management
➢ Secondary Storage Management
➢ Protection
➢ Time management
➢ Interrupt Handling

Kernel Space and User Space:

 The program code corresponding to the kernel applications/services are kept in a
contiguous area (OS dependent) of primary (working) memory and is protected from the
un-authorized access by user programs/applications
 All user applications are loaded to a specific area of primary
memory and this memory area is referred as ‘User Space’
 The partitioning of memory into kernel and user space is purely
Operating System dependent
 An operating system with virtual memory support, loads the user
applications into its corresponding virtual memory space with
demand paging technique
 Most of the operating systems keep the kernel application code in
main memory and it is not swapped out into the secondary memory
Monolithic Kernel:
 All kernel services run in the kernel space
 All kernel modules run within the same memory space under a
single kernel thread
 The tight internal integration of kernel modules in monolithic kernel
architecture allows the effective utilization of the low-level features
of the underlying system
 The major drawback of monolithic kernel is that any error or failure
in any one of the kernel modules leads to the crashing of the entire
kernel application
 LINUX, SOLARIS, MS-DOS kernels are examples of monolithic kernel
Microkernel
 The microkernel design incorporates only the essential set
of Operating System services into the kernel
 Rest of the Operating System services are implemented in
programs known as ‘Servers’ which runs in user space
 The kernel design is highly modular provides OS-neutral
abstraction
 Memory management, process management, timer systems
and interrupt handlers are examples of essential services,
which forms the part of the microkernel
 QNX, Minix 3 kernels are examples for microkernel
Benefits of Microkernel:
1. Robustness: If a problem is encountered in any services in
server can reconfigured and re-started without the need for
re-starting the entire OS.
2. Configurability: Any services , which run as ‘server’
application can be changed without need to restart the
whole system
Types of Operating Systems:
 Depending on the type of kernel and kernel services, purpose and type of computing systems where
the OS is deployed and the responsiveness to applications, Operating Systems are classified into
General Purpose Operating System (GPOS):
 Operating Systems, which are deployed in general computing systems
 The kernel is more generalized and contains all the required services to execute generic applications
 Need not be deterministic in execution behavior
 May inject random delays into application software and thus cause slow responsiveness of an
application at unexpected times
 Usually deployed in computing systems where deterministic behavior is not an important criterion
 Personal Computer/Desktop system is a typical example for a system where GPOSs are deployed.
 Windows XP/MS-DOS etc are examples of General Purpose Operating System

Real Time Purpose Operating System (RTOS):

 Operating Systems, which are deployed in embedded systems demanding real-time response
 Deterministic in execution behavior. Consumes only known amount of time for kernel applications
 Implements scheduling policies for executing the highest priority task/application always
 Implements policies and rules concerning time-critical allocation of a system’s resources
 Windows CE, QNX, VxWorks , MicroC/OS-II etc are examples of Real Time Operating Systems (RTOS)
The Real Time Kernel:
 The kernel of a Real Time Operating System is referred as Real Time kernel.
 In complement to the conventional OS kernel, the Real Time kernel is highly specialized and it contains
only the minimal set of services required for running the user applications/tasks. The basic functions of
a Real Time kernel are
a) Task/Process management
b) Task/Process scheduling
c) Task/Process synchronization
d) Error/Exception handling
e) Memory Management
f) Interrupt handling
g) Time management
Real Time Kernel Task/Process Management:
 Deals with setting up the memory space for the tasks, loading the task’s code into the memory space,
allocating system resources, setting up a Task Control Block (TCB) for the task and task/process
termination/deletion.
 A Task Control Block (TCB) is used for holding the information corresponding to a task. TCB usually
contains the
following set of information
❖ Task ID: Task Identification Number
❖ Task State: The current state of the task. (E.g. State= ‘Ready’ for a task which is ready to execute)
❖ Task Type: Task type. Indicates what is the type for this task. The task can be a hard real time or soft
real time or background task.
❖ Task Priority: Task priority (E.g. Task priority =1 for task with priority = 1)
❖ Task Memory Pointers: Pointers to the code memory, data memory and stack memory for the task
❖ Task System Resource Pointers: Pointers to system resources (semaphores, mutex etc) used by the task
❖ Task Pointers: Pointers to other TCBs (TCBs for preceding, next and waiting tasks)
❖ Other Parameters Other relevant task parameters
 The parameters and implementation of the TCB is kernel dependent. The TCB parameters vary across
different kernels, based on the task management implementation
Task/Process Scheduling:
 Deals with sharing the CPU among various tasks/processes.
 A kernel application called ‘Scheduler’ handles the task scheduling.
 Scheduler is nothing but an algorithm implementation, which performs the efficient and optimal
scheduling of tasks to provide a deterministic behavior.
Task/Process Synchronization:
 Deals with synchronizing the concurrent access of a resource, which is shared across multiple tasks and
the
communication between various tasks.
Error/Exception handling:
 Deals with registering and handling the errors occurred/exceptions raised during the execution of tasks.
 Insufficient memory, timeouts, deadlocks, deadline missing, bus error, divide by zero, unknown
instruction execution etc, are examples of errors/exceptions. Errors/Exceptions can happen at the kernel
level services or at task level.
 Deadlock is an example for kernel level exception, whereas timeout is an example for a task level
Memory Management:
 The memory management function of an RTOS kernel is slightly different compared to the General
Purpose Operating Systems
 The memory allocation time increases depending on the size of the block of memory needs to be
allocated and the state of the allocated memory block (initialized memory block consumes more
allocation time than uninitialized memory block)
 Since predictable timing and deterministic behavior are the primary focus for an RTOS, RTOS achieves
this by compromising the effectiveness of memory allocation
 RTOS generally uses ‘block’ based memory allocation technique, instead of the usual dynamic memory
allocation techniques used by the GPOS.
 RTOS kernel uses blocks of fixed size of dynamic memory and the block is allocated for a task on a need
basis. The blocks are stored in a ‘Free buffer Queue’.
 Most of the RTOS kernels allow tasks to access any of the memory blocks without any memory
protection to achieve predictable timing and avoid the timing overheads
 RTOS kernels assume that the whole design is proven correct and protection is unnecessary.
 Some commercial RTOS kernels allow memory protection as optional and the kernel enters a fail-safe
mode when an illegal memory access occurs
 The memory management function of an RTOS kernel is slightly different compared to the General
Purpose Operating Systems
 A few RTOS kernels implement Virtual Memory concept for memory allocation if the system supports
secondary memory storage (like HDD and FLASH memory).
 In the ‘block’ based memory allocation, a block of fixed memory is always allocated for tasks on need basis
and it is taken as a unit. Hence, there will not be any memory fragmentation issues.
 The memory allocation can be implemented as constant functions and thereby it consumes fixed amount of
time for memory allocation. This leaves the deterministic behavior of the RTOS kernel untouched.
Interrupt Handling:
 Interrupts inform the processor that an external device or an associated task requires immediate attention
of the CPU.
 Interrupts can be either Synchronous or Asynchronous.
 Interrupts which occurs in sync with the currently executing task is known as Synchronous interrupts.
Usually the software interrupts fall under the Synchronous Interrupt category. Divide by zero, memory
segmentation error etc are examples of Synchronous interrupts.
 For synchronous interrupts, the interrupt handler runs in the same context of the interrupting task.
 Asynchronous interrupts are interrupts, which occurs at any point of execution of any task, and are not in
sync with the currently executing task.
 The interrupts generated by external devices (by asserting the Interrupt line of the processor/controller to
which the interrupt line of the device is connected) connected to the processor/controller, timer overflow
interrupts, serial data reception/ transmission interrupts etc are examples for asynchronous interrupts.
 For asynchronous interrupts, the interrupt handler is usually written as separate task (Depends on OS Kernel
implementation) and it runs in a different context. Hence, a context switch happens while handling the
asynchronous interrupts.
 Priority levels can be assigned to the interrupts and each interrupts can be enabled or disabled individually.
 Most of the RTOS kernel implements ‘Nested Interrupts’ architecture. Interrupt nesting allows the
Time Management:
 Interrupts inform the processor that an external device or an associated task requires
immediate attention of the CPU.
 Accurate time management is essential for providing precise time reference for all
applications
 The time reference to kernel is provided by a high-resolution Real Time Clock (RTC) hardware
chip (hardware timer)
 The hardware timer is programmed to interrupt the processor/controller at a fixed rate. This
timer interrupt is referred as ‘Timer tick’
 The ‘Timer tick’ is taken as the timing reference by the kernel. The ‘Timer tick’ interval may
vary depending on the hardware timer. Usually the ‘Timer tick’ varies in the microseconds
range
 The time parameters for tasks are expressed as the multiples of the ‘Timer tick’
 The System time is updated based on the ‘Timer tick’
 If the System time register is 32 bits wide and the ‘Timer tick’ interval is 1microsecond, the
System time register will reset in 232 * 10-6/ (24 * 60 * 60) = 49700 Days =~ 0.0497 Days =
1.19 Hours
 If the ‘Timer tick’ interval is 1 millisecond, the System time register will reset in 232 * 10-3 /
(24 * 60 * 60) = 497 Days = 49.7 Days =~ 50 Days The ‘Timer tick’ interrupt is handled by
the ‘Timer Interrupt’ handler of kernel.
The ‘Timer tick’ interrupt can be utilized for implementing the following actions.
 Save the current context (Context of the currently executing task)
 Increment the System time register by one. Generate timing error and reset the System time
register if the timer tick count is greater than the maximum range available for System time
register
 Update the timers implemented in kernel (Increment or decrement the timer registers for
each timer depending on the count direction setting for each register. Increment registers
with count direction setting = ‘count up’ and decrement registers with count direction setting
= ‘count down’)
 Activate the periodic tasks, which are in the idle state
 Invoke the scheduler and schedule the tasks again based on the scheduling algorithm
 Delete all the terminated tasks and their associated data structures (TCBs)
 Load the context for the first task in the ready queue. Due to the rescheduling, the ready
task might be changed to a new one from the task, which was pre-empted by the ‘Timer
Interrupt’ task
Hard Real-time System:
 A Real Time Operating Systems which strictly adheres to the timing constraints for a task
 A Hard Real Time system must meet the deadlines for a task without any slippage
 Missing any deadline may produce catastrophic results for Hard Real Time Systems, including
 Air bag control systems and Anti-lock Brake Systems (ABS) of vehicles are typical
examples of Hard Real Time Systems
 As a rule of thumb, Hard Real Time Systems does not implement the virtual memory
model for handling the memory. This eliminates the delay in swapping in and out the code
corresponding to the task to and from the primary memory
 The presence of Human in the loop (HITL) for tasks introduces unexpected delays in the
task execution. Most of the Hard Real Time Systems are automatic and does not contain a
‘human in the loop’
Soft Real-time System:
 Real Time Operating Systems that does not guarantee meeting deadlines, but, offer the
best effort to meet the deadline
 Missing deadlines for tasks are acceptable if the frequency of deadline missing is within
the compliance limit of the Quality of Service(QoS)
 A Soft Real Time system emphasizes on the principle ‘A late answer is an acceptable
answer, but it could have done bit faster’
 Soft Real Time systems most often have a ‘human in the loop (HITL)’
 Automatic Teller Machine (ATM) is a typical example of Soft Real Time System. If the ATM
takes a few seconds more than the ideal operation time, nothing fatal happens.
 An audio video play back system is another example of Soft Real Time system. No
potential damage arises if a sample comes late by fraction of a second, for play back.
How to chose RTOS:
 The decision of an RTOS for an embedded design is very critical. A lot of factors need to
be analyzed carefully before making a decision on the selection of an RTOS. These factors
can be either
1. Functional
2. Non-functional requirements.
1. Functional Requirements:
Processor support:
 It is not necessary that all RTOS’s support all kinds of processor architectures. It is
essential to ensure the processor support by the RTOS
Memory Requirements:
 The RTOS requires ROM memory for holding the OS files and it is normally stored in a non-
volatile memory like FLASH.
 OS also requires working memory RAM for loading the OS service. Since embedded
systems are memory constrained, it is essential to evaluate the minimal RAM and ROM
requirements for the OS under consideration.
Real-Time Capabilities:
 It is not mandatory that the OS for all embedded systems need to be Real Time and all
embedded OS’s are ‘Real-Time’ in behavior.
 The Task/process scheduling policies plays an important role in the Real Time behavior of
Kernel and Interrupt Latency:
 The kernel of the OS may disable interrupts while executing certain services and it may lead to
interrupt latency.
 For an embedded system whose response requirements are high, this latency should be minimal.
Inter process Communication (IPC) and Task Synchronization:
 The implementation of IPC and Synchronization is OS kernel dependent.
Modularization Support:
 Most of the OS’s provide a bunch of features.
 It is very useful if the OS supports modularization where in which the developer can choose the
essential modules and re-compile the OS image for functioning.
Support for Networking and Communication:
 The OS kernel may provide stack implementation and driver support for a bunch of communication
interfaces and networking.
 Ensure that the OS under consideration provides support for all the interfaces required by the
embedded product.
Development Language Support:
 Certain OS’s include the run time libraries required for running applications written in languages like
JAVA and C++.
 The OS may include these components as built-in component, if not , check the availability of the
same from a third party
2. Non-Functional Requirements:
Custom Developed or Off the Shelf:
 It is possible to go for the complete development of an OS suiting the embedded system needs or
use an off the shelf, readily availableOS.
 It may be possible to build the required features by customizing an open source OS.
 The decision on which to select is purely dependent on the development cost, licensing fees for the
OS, development time and availability of skilled resources.
Cost:
 The total cost for developing or buying the OS and maintaining it in terms of commercial product and
custom build needs to be evaluated before taking a decision on the selection of OS.
Development and Debugging tools Availability:
 The availability of development and debugging tools is a critical decision making factor in the
selection of an OS for embedded design.
 Certain OS’s may be superior in performance, but the availability of tools for supporting the
development may be limited.
Ease of Use:
 How easy it is to use a commercial RTOS is another important feature that needs to be considered in
the RTOS selection.
After Sales:
 For a commercial embedded RTOS, after sales in the form of e-mail, on-call services etc. for bug
fixes, critical patch updates and support for production issues etc. should be analyzed thoroughly.