You are on page 1of 55

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

 Memory Management in µCOSII


SERVICES PROVIDED BY AN OPERATING
SYSTEM
 Every computing device, whether it is a mainframe,
desktop computer or an embedded system needs a piece of
software using which the user interacts with the hardware.
 Each job is done by invoking an application software
package.
 Each job is called “process” in desktop system and each job
is called “task” in embedded system.
 Each task needs memory and needs to access I/O devices.
 An OS has to do the following functions:
 Process/Task Management.
 Memory Management.
 I/O Management including managing the file system.
 Providing the services to the applications.
 Providing a user interface. 3
SERVICES PROVIDED BY AN OPERATING SYSTEM (CONTD…)

 OS are divided into different categories:


 Single-tasking OS versus Multi-tasking OS.
 Single-user OS versus Multi-user OS.
 Command-driven OS versus GUI-based OS.
 As compared to desktops, embedded system have
special requirements.
 Reliability
 Multi-tasking with time constraints
 Small footprint
 Support diskless systems
 Portability
 Scalability
4
 Support for standard API
HARD AND SOFT REAL TIME SYSTEM
 Hard real time means strict about adherence to each
task deadline. When an event occurs, it should be
serviced within the predictable time at all times in a
given hard real time system.
 Automobile engine control system and anti-lock brake
are the examples of hard real time systems.
 Soft real time means that only the precedence and
sequence for the task operations are defined and
observed time constraints and a few deadline misses
are accepted.
 Set top boxes and digital cameras are examples of soft
5
real time systems.
CATEGORIES OF EMBEDDED OPERATING SYSTEMS
 Non-real-time Operating Systems.
 Small footprint but they are not suitable for hard real time
applications.
 Examples: Embedded Linux, Windows XP Embedded.

 Real-time Operating Systems.


 Suitable for hard real time embedded applications.
 Mobile/Handheld Operating Systems.
 Used in mobile devices such as palmtops, PDAs,
Smartphone.

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.

 Every task requires resources.


 Tasks may need to communicate data amongst themselves.

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.

 The current task has completed its allocated time slice.


14

 Digital multimeters and microwave ovens use this algorithm.


SCHEDULING ALGORITHMS (CONTD…)
 Round Robin Algorithm with Priority.
 The round robin algorithm can be slightly modified by
assigning priority levels to some or all the task.
 Examples: Bar Code Scanner
 Soft real-time systems can use this algorithm.

 Shortest Job First.


 In Shortest-job first task scheduling algorithm, the task
that will take minimum time to be executed will be given
priority.
 This approaches satisfies the maximum number of tasks,
but some task may have to wait forever.
15
SCHEDULING ALGORITHMS (CONTD…)
 The kernel used in embedded systems can implement priority-based
multi-tasking scheduling algorithms of two types:
 Non-preemptive multi-tasking.
 Preemptive multi-tasking.
 Non-preemptive multi-tasking.
 In this the tasks cooperate with each other to get their share of the CPU
time.
 Hence, each task has to release the CPU and give control to another task
on its own.
 The main disadvantage of non-preemptive multitasking is that a high
priority task may have to wait for a long time.
 This type of multi-tasking is not suitable for embedded real time
systems.

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.

 RMA is used to calculate the percentage of CPU time utilized


18
by the tasks.
INTERRUPT SERVICE ROUTINES (ISR)
 Interrupt is a hardware signal that informs the CPU that an
important event occurred.
 When an interrupt occurs, CPU saves its context and jumps to the
ISR.
 In real time operating systems, the interrupt latency, interrupt
response time and the interrupt recovery time are very important.

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.

 To access a shared resource, there should be as mechanism


so that there is discipline. This is known as resource
21
synchronization.
SEMAPHORES (CONTD…)
 A mechanism that shows for task1 to inform task2 that it
has done its job.
 This has to be done through well defined procedure. This is
known as task synchronization.

 Semaphore is a kernel object that is used for resource


synchronization and task synchronization. 22
SEMAPHORES (CONTD…)
 Suppose two tasks want to access a display. Display is shared
resources. To control the access, a semaphore is created.

 If a number of tasks have to access the same resources then


23
the tasks are kept in a queue and each task can acquire the
semaphore one by one.
MUTEX
 Mutex is the general mechanism used for both resource
synchronization as well as task synchronization.
 Mutual exclusion can be achieved through the following
mechanisms:
 Disabling the scheduler
 Disabling the interrupts
 By test – and – set operations
 Using the semaphore

 Test-and set operations


 When two tasks have to share resource, the functions in each of the
tasks can check the value of a global variable to obtain the status of
the shared resources.
 Note that while the test-and set operation is in progress, the
interrupts have to be disabled. So, the procedure is – disable the 24

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…)

 In UNIX/LINUX, we use the pipes as shell commands.


 Consider the shell command $ cat hello.c | more

33
EVENT REGISTERS

 A task have an event register in which the bits


correspond to different events.
 Each bit in an event register can be used to obtain the
status of an event.
 Each of the bits in the event register is an event flag.

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

 When tasks share a resource, there is a possibility of getting into


a problem, known as priority inversion problem 37

 To overcome this problem, priority inheritance protocol is used.


PRIORITY INHERITANCE

 The priority of the task which acquired the mutex will be


increased to a value than the priority of the task competing
38
for that resource.
PATHFINDER PROBLEM REVISITED
 Priority-based preemptive multitasking OS was used.
 Information management bus task – High Priority

 Communication management task – Medium Priority

 Meteorological data collection task – Low Priority

 While initializing the mutex, the parameter to set the


priority inheritance was to be changed from FALSE to
TRUE.
 This is just a change in the file that declares global
variables.
 So, this change was made in the file and the file
uploaded to the pathfinder embedded system. 39
MICROC/OS-II
 It is developed by Jean J. Labrosse.
 It is certified for use in commercial aircraft by Federal
Aviation Administration.
 Features of µCOSII:
 Source code availability
 ROMable
 Scalable
 Preemptive
 Portable
 Multitasking
 Deteministic
 Reliable
 Support for different platforms
 Supports 64 task out of which 8 are system task. Each task
assigned unique priority.
40
 Round – robin scheduling algorithm is not supported.
FEATURES OF ΜCOS-II
 Source Code:
 The book published by Jean J Labrosse.
 He went through a lot of efforts to provide you with a high
quality ‘product’.
 The code is both clean and very consistent.

 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.

 Robust and reliable:


 μC/OS-II is based on μC/OS
 μC/OS-II uses the same core and most of the same functions as
μC/OS yet offers more features.

45
KERNEL STRUCTURE OF ΜCOS-II

Application Code

Processor Independent Application Specific


Code Configurations
•Scheduling policy
•Event flag
•Semaphores
•Mailboxes OS_CFG.H
•Event queues
•Task management
•Time management
•Memory management

µcos-ii port for specific codes


Software
Hardware
CPU Timer
46
INTER-TASK COMMUNICATION AND
SYNCHRONIZATION
 Most OS (RTOS) offer a variety of mechanisms for communication
and synchronization between tasks.
 These mechanism are necessary in a preemptive environment of
many task.
 Most RTOSs provide several communication, with each
mechanism optimized for reliably passing a different kind of
information from task to task.
 If message can be sent more quickly than they can be handled,
the RTOS will provide message queue for holding the messages
until they can be processed.

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

You might also like