Embedded Systems - Real Time

Operating Systems (RTOS)

Unit 6
 User Interface

Analog i/p Analog D/A, Analog o/p

Front End User Interface Isolation..
Digital i/p Digital Modules
Digital Digital o/p
i/p Ports
o/p Ports
interrupts Support:
Timers
Watchdog
INPUTS OUTPUTS
CPU Comms:
ASC, SSC,
USB, IIC,
Data Bus IrDA, etc.

Address Bus

Data Program
Memory Memory

2 of
Links to Other Systems
Introduction
• The software in an embedded system consists of
an operating system
— Optional, if not present, need to write software routines to access hardware
— Embedded systems are constrained by memory, hence can not use OS such as Windows
or Linux
the application software
• Services Provided by an operating System
• Every computing device needs a piece of software using which the user
interacts with the hardware. This software is known as the Operating System
(OS).
• A computer or embedded system is designed to perform different things
simultaneously. Each such job is called a process in case of a computer and in
case of embedded system, it is called as a task.
• Each task needs memory and access to I/O devices. Managing these multiple
tasks is done by the OS.
3
Introduction
• An OS has to do the following functions:
 Process / Task Management
 Memory Management
 Input / Output Management including file services
 Providing services to applications
 Providing user interface so that user need not be concerned about
underlying hardware details.
• An OS is said to be
• Of type Hard, when the tasks to be completed are to be completed absolutely
on time without missing any deadline e.g., pacemaker, defense systems etc.
• Of type Soft, when the tasks to be completed are to be completed can miss
few deadlines without compromising overall application performance. E.g.,
music system, automated toys etc.
4
Process
• An application program consists of number of processes
• Each process runs under the control of OS
• Each process consists of sequentially executable program codes and state
controlled by OS.
• The state of a process is represented by information of process state(created,
running, blocked, finished), process structure(data, objects, resources) and
Process Control Block(PCB)
• A process runs on scheduling by OS, which gives control of CPU to the process.
• Process Control Block:
• Is a data structure having the information using which the OS controls the
process state. The PCB consists of
• Process Id, Process priority, parent process, child process(if any) and address to the next
process PCB.
• It also holds allocated memory information of ROM, stack and CPU registers and other
context related information.
5
Multiple Threads
• A thread consists of sequentially executable code under state control
by OS.
• The state information of a thread is represented by
• a thread state (started, running, blocked, finished)
• thread structure (data, object and resources)
• A thread is a process or a sub process within a process that has
• its own PC, SP and stack
• Priority parameter for scheduling
• Variables that load into processor register on context switching
• Signal mask when unmasked allows the tread to activate and run.
• When masked, the thread is put into a queue of pending threads.
• A thread stack is at a memory block allocated by OS.
6
Multithreaded Process
• A multiprocessing OS runs more than one process.
• A process consisting of multiple threads is called multithreaded
process.
• A thread defines a minimum unit of a multithreaded process that an
OS schedules onto the CPU and allocates other system resources.
• Difference between task and thread:
• A thread can be a sub process within a process or a process within an
application program
• A task is a process and the OS does the multitasking.
• Task is kernel controlled entity, where as thread is process controlled entity.
• A task and a thread are analogous in the aspect that
• A task or a thread do not call another task or thread
• Both need schedulers – Task scheduler / thread scheduler.
7
 Tasks
• A task is similar to a process. Some OSes use the term task and some use process.
• A task consists of a sequentially executable program(codes) under a state control
by an OS.
• The tasks include the OS tasks as well as application specific tasks.
• The task object contains all information related to the task:
• The state information of a task is represented by the task state, task structure and task control
block.
• Task Scheduling:
• Since only one CPU can handle multiple tasks, the tasks have to share the CPU time in
disciplined manner to ensure one task does not get too much time while other task is waiting
for ever.
• Each task has to be assigned a priority and a mechanism for deciding which task will get CPU
time next. This is known as task scheduling.
• In addition to CPU time, the tasks have to share system resources such as CPU registers,
external memory and input / output devices.
• Also, one task should not corrupt data of another task.
8
Process, thread and task
Process 1 Process 2 Process n - 1 Process n

PCB Process 1 PCB Process 2 PCB Process n-1 PCB Process n

Process 1 Process i

Thread 1 Thread j Thread 1 Thread k

Stack Stack Stack Stack

PCB Process 1 PCB Process i

Task 1 Task 2 Task n-1 Task n

TCB Process 1 TCB Process 2 TCB Process n-1 TCB Process n

9
 Task States
• A task has a state which includes its status at a given instance in the system.
• A task can be considered to be in one of the below states:
1. Idle (Created) state: Task has been created and memory is allotted to its structure. However, it is not ready
and is not schedulable by the kernel.
2. Ready (Active) state: Created task is ready and is schedulable by the kernel but not running at present as
another high priority task is scheduled to run and has the system resources at this instance.
3. Running state: Executing the service code and has acquired system resources at this instance. It will run till
it needs some input or starts to wait for an event or is pre-empted by another high priority task.
4. Blocked state: Execution of the code is suspended after saving the required parameters into a context.
5. Deleted (finished) state: The created task has memory de-allocated to its structure and frees the memory.

Attached with kernel Signal or message

Idle Ready Running

Signal or message

Wait for Signal or message

Blocked

10
 Task Data
A task has following data which is specific to its status stored in TCB(Task
Control Block)
1. Each task has a Task ID – Typically of 1 byte, assigned by the OS.
2. Each task has a priority parameter – Represented by a byte, generally, higher the
value, greater the priority.
3. Each task has
1. Program Counter – Memory address from where it runs the program if granted access of CPU
2. Stack Pointer – Memory address from where it gets saved CPU registers, parameters and pointer
to stack top if scheduler grants access to the CPU.
Task Id
Task Context
— PC (Program Counter)
— SP (Stack Pointer)
TCB — CPU Register
— Processor Status Register
Task Priority

Task context_init
11
 Context Switching
• Context:
• Each task has a context (CPU registers, parameters and pointer to the stack top of called function).
• The context is continuously updated during running of the task and is saved before switching to another
task.
• Hence the context reflects the state just before the OS blocks one task and initiates another task into
running state.
• Context Switching
• Only after saving the registers and pointers, the CPU control switches to other process or
task. The context will retrieve the PC and register information once the CPU is back to the
task again, on the OS unblocking its state and allowing it to enter running state again.
• Context switching happens each time the schedule blocks one task and runs another task.
• Each task also has initial context - context-init . This has initial parameters of the task: 1)
Pointer to a start up function – a task starts from this address 2) Pointer to task data
structure
• Task Control Block
• The TCB is a data structure having the information using which the OS controls the task state.
• TCB is a memory block stored in protected memory area of the kernel.
12
 Scheduling Algorithms
Various scheduling algorithms have been developed for scheduling. Depending on the requirement of
embedded system, scheduling algorithm needs to be chosen.
Scheduling Model Description
First In First Out Tasks which are ready to run in queue are executed on first come first serve basis.
• Simple to implement
• Difficult to estimate the time the task has to wait
• Suited for simple embedded system with small tasks and small execution times.
Round Robin Kernel allocates certain amount of time (called quantum) for each task waiting in the queue. The
kernel gives control to next task if 1) the current task has completed its work within the time slice or
has no work to do 2) current task has completed its allocate time slice
• Works well for non time critical operations
Round Robin with Priority This is a variation to round robin schedule where apriority task can interrupt the scheduler.
• Soft real time systems can use this algorithm.
Shortest Job First If time of each task can be estimated, the CPU can execute the task that takes least amount of time.
Here, priority is based on execution time.
• High number of tasks can be executed
• Task with highest amount of time has to wait for long.
13
 Scheduling Algorithms
If the embedded system is a hard real time system, none of the above algorithms can be used.
Priority based multi tasking embedded systems are of two types:
1. Non-preemptive multitasking / Co-operative scheduling: The tasks co-operate with each others to
get their share of CPU time. Each task is given priority, but the priority has to be respected by the
other tasks. Each task has to release the CPU and give control to another task on its own.
• A high priority task can interrupt the running task and make the high priority task ready to run.
• After the ISR is executed, the CPU will continue to execute low priority task only
• When the low priority task releases the CPU, the high priority task is executed.
2. Preemptive multitasking: Highest priority task is always given the CPU time. If a lower priority task is
presently running and a higher priority task is in ready to run state, the running task is pre-empted
and the higher priority task is executed.
Non Preemptive Preemptive
Low Priority ISR Low Priority High Priority Low Priority ISR High Priority Low Priority
task running task running task running task running task running task running

ISR makes high priority Low priority task ISR makes high priority High priority task
task ready to run releases the CPU task ready to run releases the CPU 14
 Semaphores(Sharing Resources and Synchronization)
• DEF: A hardware or software flag. In multitasking systems, a semaphore is a variable with a value that indicates
the status of a common resource. It's used to lock the resource that is being used. A process needing the resource
checks the semaphore to determine the resource's status and then decides how to proceed.

• A semaphore is like a key. The task which needs access to a resource needs to first acquire the semaphore,
use the resource and then release the resource
• Two or more tasks may need to share the same resource when multiple tasks are running. E.g.,
two tasks writing to a same display.
• A mechanism to access a shared resource is called resource synchronization.
• Also, there could be cases where there are task dependencies – e.g., read from an input and write
to an output. The data should be written to output only after read from input or after certain tasks
are performed. Here, there should be a mechanism for task1 that task2 is completed. A procedure
through which this is done is known as task synchronization.
• Semaphore is a kernel object that is used for both resource and task synchronization..
• The allocation of semaphore can be on first come first serve basis or it can be on priority basis.
• The tasks in queue requiring the same resource can acquire the resource one by one through the
semaphore. 15
 Semaphores(Binary & Mutex-mutually exclusive)
• E.g., Task1 and Task2 want to make use of a display, which is shared.
• A binary semaphore can be used for handing this – the semaphore can be set to 0 when it has been
taken and set to 1 when it has been released.
• Task1 notifies the OS when getting access to the resource
• The OS returns the semaphore as taken by decrementing the semaphore from 1 to 0.
• Task1 accesses the resource.
• After completing the access, task 1 notifies the OS to have posted the semaphore.
• Acquires the resource and the semaphore is set to 1.
• The OS returns the semaphore as released by incrementing the semaphore from 0 to 1.
• Meantime if task 2 wants the same resource, will be in blocked state.
• It will have access to the resource once the semaphore is released.

16
Binary Semaphore - Illustration

Critical Section Task 1 Until critical section of task 1

is completed, semaphore is
Release semaphore
Notification Take semaphore
flag call event to OS
with task 1. Task 2 requiring
request to take
semaphore same resource is in blocked
state.

OS

Provide access of semaphore

to task 2 and Run Task 2

Blocked Task 2

17
Multiple Semaphores & Multitasking
Share common semaphore X

Share common semaphore Y

Task i Task J Task k Task l Task m

X taken Notify for taking Y Y taken

Notify for taking X OS

Use of multiple semaphores for multitasking operations in synchronizing tasks: different semaphores used for need of
different resource needs.
18
 Device Drivers
• A system has number of physical devices. A device has multiple functions.
• E.g., a timer may be used for counting, as well as delay calculations.
• Each device function requires a driver. A common driver or separate driver for each device
function is required. A driver has following features:

1. The driver provides a software layer between the application and actual device:
• The drivers are used when running an application.
• Driver provides a routine that facilitates use of a device function in an application.
2. The driver facilitates the use of a device by executing an ISR:
• The driver function is generally written in such a way that it can be used by the developer without actually knowing
the detailed contents of it. The developer need not know the details of memory / registers / addresses / flags used
by the device, once the functions are made available to the code. E.g., for delay generation, a function call can be
made to the timer, with parameters of time delay requirements. Specifics of which component of registers, timers,
frequency is being used need not be known by the developer.
• Simple commands from a task or function can be used to drive the device.
3. To use a device, the device is opened or registered before using the driver. i.e., device is first
initialized and configured through control register and corresponding ISR is enabled. A device
function can also be de-registered through the configuration. In such case, the device driver is not
accessible till the device is re-opened.
19
 Choosing an RTOperating System
• Select the simplest architecture that will meet the system response
requirements.
• If the system requirements necessitate use of real time operating system,
then the design should be to chose RTOS.
• A hybrid of architecture can also be created. Even if decision is to use an
RTOS, we can have a low priority task that polls those parts of the hardware
that do not need faster response.

20
 Choosing an RTOperating System
• OS Choice Considerations:
• RTOS is generally necessary for any application which requires control over process priorities.
• For an operating system to be considered as an RTOS, the system must be predictable with respect to timing
and be deterministic.
• For example, if you need a task to execute every 10 seconds without fail, then you will need a RTOS.
• Following are a few RTOSs for further review:
• Nucleus
• QNX
• VxWorks
• Windows CE
• OSE
• An embedded system is a specialized computer system that typically utilizes a RTOS. Generally,
such systems perform a limited number of functions, often with tight constraints. For example,
many household appliances utilize rudimentary embedded systems. For example, a washing
machine only requires a select few operations which do not require a full computer system.
• The first step in determining which RTOS is right is to understand the various types of RTOSs and
their application. Each of the following sections can be used to help determine what specific RTOS
requirements are. Once these requirements are determined, the information needed to select the
appropriate RTOS can be firmed up. 21
 Choosing an RTOperating System
• Size:
Most embedded systems have tight memory constraints. We must determine how much memory the
embedded system allows (i.e. how much and what type of RAM is supported). Then, there are two factors
to consider 1) what memory is required by the RTOS itself and 2) how much memory the application
requires. For the second factor, we may need to utilize an RTOS simulator (most RTOSs come with one) to
gain an accurate estimation, which is especially important if we are working with a severely limited system.
• Flexibility:
There are some constraints and requirements that are very important towards the success in relation to the
RTOS architecture. Following are few key areas to explore with each RTOS vendor:
• Scheduling Policies: Evaluate the scheduling policy needed for the application. Multiple scheduling policies may be needed
based on requirements.
• Runtime behavior: Verify support for dynamic objects at runtime. This will allow for greater flexibility. If dynamic objects
are not supported, the functionality may have to be handled before runtime, reducing the flexibility.
• Application Programming Interface (API): Verify the APIs supported by the RTOS and if it in particular supports the one
needed by the application.
• Interrupts: Determine how the RTOS handles interrupts and whether the functions are supported. If functions are not
supported, own code may have to be written, extending the development time.
• Event Synchronization: Chose the OS based on how multiple events need to be synchronized.
• Memory Management: Check the ability of memory allocations so that additional overhead associated with garbage clean
up and fragmentation can be avoided.
• Messaging: Check the messaging options available for passing data between various objects.

22
 Choosing an RTOperating System
• Speed:
• There are two basic types of RTOSs, hard and soft. A hard system is required when there is a
situation where a task not meeting a deadline would result in a failure. With a soft system
there is no guarantee that deadline would be met, but there is some window of reliability. For
example, the system may not guarantee the execution of task every 10 seconds, but the
system will likely not take more than 11 seconds and generally will make the 10 second
requirement.
• The response time is the measure of the hardness of a RTOS. The lower the response time, the
better (harder) the RTOS. The key question to explore is: What is the worst case response time
the application can live with? The value that answers that question is determined by the
amount of Jitter in the system.
• Cost:
Budget needs to be considered by keeping following aspects in mind:
• Initial software license fees
• Recurring license fees
• Support costs
• Training costs
• Development labor costs
23