Professional Documents
Culture Documents
Unit-Iv: Real Time Operating System
Unit-Iv: Real Time Operating System
1
OUTLINE
Architecture of Kernel
Task Scheduler
ISR
Semaphores
Mailbox
Message Queue
Pipes
Events
Timers
Memory Management
Introduction to µCOSII RTOS
Kernel Structure of µCOSII
Synchronization in µCOSII
Inter-task Communication in µCOSII 2
6
ARCHITECTURE OF KERNEL
The embedded software consists of operating system
and the application software.
The services provided by the operating system are
accessed through the API.
The API is a set of function calls – access the kernel
objects and services provided by the kernel.
7
ARCHITECTURE OF KERNEL (CONTD…)
Message
Queue
Signals Event
Registers
Mailboxes
ISRs
Scheduler
Pipes Timers
Tasks Mutexes
8
Semaphores
TASKS AND TASK SCHEDULER
The embedded software consists of no. of task.
The task object consists of its name, a unique ID, a
priority, a stack and a Task Control Block.
The kernel has its own system tasks with priorities.
These task are:
Startup task
Exception handling task
Logging task
Idle task
Each task has to be assigned priority; and a
mechanism for deciding which task will get CPU time
next has to be worked out. This is known as task
scheduling. 9
TASKS AND TASK SCHEDULER (CONTD…)
Another important requirement is that one task
should not corrupt the data of another task.
While scheduling the tasks, a number of issues as
described below:
Many tasks make calls to a function.
Reentrant function.
Non-reentrant function.
10
TASK STATES
In an embedded system, each task has to do a specific job.
Consider, an embedded system that obtain data from a
serial port and converts the data into Ethernet packets.
11
TASK STATES (CONTD…)
A task can be in one of the following state:
Running state – if it is being executed by the CPU
Waiting state – if it is waiting for another event to occurs.
Ready-to-Run state – if it is waiting in a queue for CPU
time.
Task stack
Every task will have a stack.
12
CONTEXT SWITCHING AND SCHEDULING
ALGORITHMS
Context Switching.
The state of the CPU registers when a task has to be
preempted is called the context.
Saving the contents of the CPU registers and loading the new
task parameter is called context switching.
Scheduling Algorithms.
Depending on the requirement of the embedded system, the
scheduling algorithm needs to be chosen.
Following scheduling algorithm:
First In First Out
Round Robin algorithm
Round Robin with priority
Shortest Job First
Non-preemptive multitasking
Preemptive multitasking 13
SCHEDULING ALGORITHMS
First In First Out
The task which are ready to run are kept in a queue and the
CPU serves the task on first come first served basis.
This is a good algorithm for an embedded system has to
perform few small tasks all with small execution times.
Round Robin Algorithm
The kernel allocates a certain amount of time for each task
waiting in the queue.
The time slice allocated to each task is called quantum.
The kernel gives control to the next task if
The current task has completed its work within the time slice.
The current task has no work to do.
16
SCHEDULING ALGORITHMS (CONTD…)
Preemptive multi-tasking.
In preemptive multi-tasking, the highest priority task is always
given the CPU time.
The main attraction of this scheme is that the execution time of the
highest priority task can be calculated.
Most of the commercial embedded OS use preemptive multitasking
to meet real time requirements.
17
RATE MONOTONIC ANALYSIS
Priority assignment to a task can be static or dynamic.
Static – assigned a priority at the time of creating the task and it
remains the same.
Dynamic – the priority of the task can be changed during execution
time.
It is not very easy to assigning priorities to tasks. A good
starting point is the Rate Monotonic Analysis is used for
assigning priorities.
RMA makes the following assumptions:
High priority task will run first.
All the tasks run at regular intervals.
Task do not synchronize with each other.
19
INTERRUPT SERVICE ROUTINES (CONTD…)
Interrupt Latency
The maximum time for which interrupts are disabled + time to start
the execution of the first instruction in the ISR is called interrupt
latency.
Interrupt Response Time
Time between receipt of interrupt signal and starting the code that
handles the interrupt is called interrupt response time.
In a preemptive kernel, response time = interrupt latency + time to
save CPU registers context.
Interrupt Recovery Time
Time required for CPU to return to the interrupted code/highest
priority task is called interrupt recovery time.
In non-preemptive kernel, interrupt recovery time = time to restore
the CPU context + time to execute the return instruction from the
interrupted instruction.
In preemptive kernel, interrupt recovery time = time to check
whether a high priority task is ready+ time to restore the CPU
context + time to execute the return instruction from the interrupted
20
instruction.
SEMAPHORES
When multiple tasks are running, two or more tasks may
need to share the same resources.
interrupt, set the variable, access the shared resources, set the
variable and lastly enable the interrupts.
MUTEX (CONTD…)
The mutex is a special binary semaphore.
A mutex can be either in locked state or unlocked state.
It is much more powerful than semaphore because of its
special features:
It will have an owner
Owner can acquire a mutex multiple times in the locked state. If
the owner locks it ‘n’ times, the owner has to release it ‘n’ times.
A task owning a mutex, cannot be deleted.
The mutex supports priority inheritance protocol to avoid priority
inversion problem.
25
SEMAPHORES AND MUTEX
Semaphores Management Function Calls.
The operating system API provides the following function calls
for semaphore management:
Create a semaphore
Delete a semaphore
Acquire a semaphore
Release a semaphore
Query a semaphore
Mutex Management Function Calls.
The operating system API provides the following function calls
for mutex management:
Create a mutex
Delete a mutex
Acquire a mutex
Release a mutex
Query a mutex
Wait on a mutex 26
MAILBOXES
A mailbox object is just like your mailbox.
A task can have a mailbox into which others can post a
mail.
27
MAILBOXES (CONTD…)
To manage the mailbox object, the following function
calls are provided in the operating system API:
Create a mailbox
Delete a mailbox
Query a mailbox
Post a message in a mailbox
Read a message from a mailbox
28
MESSAGE QUEUES
Message queue can be considered as an array of mailboxes.
Some of the applications of message queue are: taking the i/p
from a keyboard, to display output, reading voltages from sensors,
data packet transmission in a network.
In each applications, a task or an ISR deposits the message in the
message queue. Other task can take the messages.
At the time of creating a queue, the queue is given a name or ID,
queue length, sending task waiting list and receiving task waiting
list.
29
MESSAGE QUEUES (CONTD…)
The following function are provided to manage the
message queues:
Create a queue
Delete a queue
Flush a queue
Post a message in queue
Read a message from queue
Broadcast a message
Show queue information
Show queue waiting list
30
MESSAGE QUEUES (CONTD…)
31
PIPES
A task can write into a pipe and the other task reads
the data that comes out of the pipe.
Task-to-task or ISR-to-task data transfer can take
place using pipes.
Pipes can be used for inter-task communication.
32
PIPES (CONTD…)
33
EVENT REGISTERS
34
SIGNALS
Signals can be passed to indicate an event
Many RTOS do not support it then and their use is
discouraged.
In shell commands, the signals are sent to kill a
process. Consider the command-
$kill -9 879
35
TIMERS
Timers are used to measure the elapsed time of events.
The kernel has to keep track of different times:
A particular task may need to be executed periodically. A timer is
used to keep track of the periodicity.
A task may be waiting in a queue for an event to occur. If the event
does not occur for a specified time, it has to take the appropriate
action.
A task may be waiting in a queue for a shared resource. If the
resource is not available for a specified time, an appropriate action
has to be taken.
Timer management function calls:
Get time
Set time
Time 36
Reset timer
PRIORITY INVERSION PROBLEM
Portable:
Most of μCOS-II is written in highly portable ANSI C, with
target microprocessor specific code written in assembly language.
Assembly language is kept to a minimum to make μCOS-II easy
to port to other processors.
μCOS-II can run on most 8-bit, 16-bit, 32-bit or even 64-bit
microprocessors or micro-controllers and, DSPs.
41
FEATURES OF ΜCOS-II (CONTD…)
ROMable:
μCOS-II was designed for embedded applications. This means
that if you have the proper tool chain (i.e. C compiler, assembler
and linker/locator), you can embed μCOS-II as part of a product.
Scalable:
Designed of μCOS-II such that you can use only the services that
you need in your application.
This means that a product can have just a few of μCOS-II’s
services while another product can have the full set of features.
Scalability is accomplished with the use of conditional
compilation.
Preemptive:
μCOS-II is a fully-preemptive real-time kernel.
Most commercial kernels are preemptive and μCOS-II is
comparable in performance with many of them. 42
FEATURES OF ΜCOS-II (CONTD…)
Multi-tasking:
μC/OS-II can manage up to 64 tasks, however, the current version
of the software reserves 8 of these tasks for system use. This
leaves your application with up to 56 tasks.
Each task has a unique priority assigned to it which means that
μCOS-II cannot do round robin scheduling. There are thus 64
priority levels.
Deterministic:
Execution time of all μCOS-II functions and services are
deterministic.
Furthermore, except for one service, execution time of all μCOS-II
services do not depend on the number of tasks running in your
application.
43
FEATURES OF ΜCOS-II (CONTD…)
Task stacks:
Each task requires its own stack, however, μCOS-II allows each
task to have a different stack size.
This allows you to reduce the amount of RAM needed in your
application.
With μCOS-II’s stack checking feature, you can determine exactly
how much stack space each task actually requires.
Services:
μC/OS-II provides a number of system services such as mailboxes,
queues, semaphores, fixed-sized memory partitions, time related
functions, etc.
44
FEATURES OF ΜCOS-II (CONTD…)
Interrupt Management:
Interrupts can suspend the execution of a task and, if a higher
priority task is awakened as a result of the interrupt, the highest
priority task will run as soon as all nested interrupts complete.
Interrupts can be nested up to 255 levels deep.
45
KERNEL STRUCTURE OF ΜCOS-II
Application Code
47
INTER-TASK COMMUNICATION AND SYNCHRONIZATION
(CONTD…)
Synchronization information is like a command, where some
commands could be positive and some negative.
Negative command to a task would be like “Please don’t print
right now because my task is using the printer”.
Positive command to a task would be like “I have detected a
cardiac emergency, and I want you to help me handle it.
Most RTOSs offer a semaphore or mutex mechanism for handling
negative synchronization
For positive synchronization, different RTOSs offer different
mechanisms. Some RTOSs offer event-flags, while others offer
signals.
48
INTER-TASK COMMUNICATION AND SYNCHRONIZATION
(CONTD…)
Inter-task or inter process communication in µcos-ii takes place
using:
Message mailbox
Message queues
Messages can be sent to a task through kernel services. A
Message Mailbox, also called a message exchange, is typically a
pointer size variable.
A waiting list is associated with each mailbox in case more than
one task desires to receive messages through the mailbox.
A task desiring to receive a message from an empty mailbox will
be suspended and placed on the waiting list until a message is
received.
49
INTER-TASK COMMUNICATION AND SYNCHRONIZATION
(CONTD…)
A message queue is basically an array of mailboxes.
Through a service provided by the kernel, a task or an ISR can
deposit a message (the pointer) into a message queue.
50
INTERRUPTS IN ΜCOS-II
An Interrupt Service Routine (ISR) be written in assembly
language.
If your C compiler supports in-line assembly language, however,
you can put the ISR code directly in a C source file. The pseudo
code for an ISR is shown below:
YourISR:
Save all CPU registers; (1)
Call OSIntEnter( ) or, increment OSIntNesting directly; (2)
Execute user code to service ISR; (3)
Call OSIntExit( ); (4)
Restore all CPU registers; (5)
Execute a return from interrupt instruction; (6)
A different stack is used when servicing an interrupt.
As the registers are saved on the interrupted task’s stack when a
51
context switch occurs.
INTERRUPTS IN ΜCOS-II (CONTD…)
OSIntNesting can be incremented directly if your processor
performs an increment operation to memory using a single
instruction.
OSIntEnter() wraps these three instructions with code to
disable and then enable interrupts thus ensuring access to
OSIntNesting .
Some implementation of OSIntEnter() will cause interrupts to
be enabled when OSIntEnter() returns. .
μC/OS-II allows you to nest interrupts because it keeps track of
nesting in OSIntNesting.
ISR is marked by calling OSIntExit() which decrements the
interrupt nesting counter.
The saved registers are restored and a return from interrupt
instruction is executed .
52
INTERRUPTS IN ΜCOS-II (CONTD…)
53
RTOS PORTING
This deals with simulation and porting of RTOS onto target
system, this is achieved by the creation of boot disk which hold
the image of the RTOS.
Hardware Requirement
Any PC with windows 98 or higher (for host)
Any Pentium PC (for target)
Floppy diskette
Software Requirement
Any RTOS image
Simple client/server application.
Explain how various operations take place.(RTU)
After simulation, we develop the application specific for RTOS on the main system and
then port it on the target system using the boot disk created.
54
RTOS PORTING (CONTD…)
General steps for RTOS Porting
Make sure that it isn’t already ported.
Determine how portable the various parts of RTOS code
Use as much as possible a high level language like C
Use a popular compiler/assembler/linker toolchain
Get a popular reference board, a popular JTAG debugger and a
popular IDE that supports your toolchain and debugger.
Look at standalone sample IDE projects for ARM and for
architectures that you are familiar with.
Look at RTOS sample IDE projects for ARM and for architectures
that you are familiar with.
Look at other ports of the RTOS.
Look at other RTOSes ported to ARM.
55