1. REAL TIME OPERATING SYSTEM
UNIT-IV
REAL TIME OPERATING SYSTEM

2. 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
Memory Management in µCOSII

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

4. 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
Support for standard API

5. 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 real time systems.

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

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

8. Architecture of Kernel (Contd…)
Message Queue
Signals
Event Registers
Mailboxes
ISRs
Scheduler
Pipes
Timers
Tasks
Mutexes
Semaphores

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

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

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

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

13. Context Switching and Scheduling Algorithms
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

14. 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.
Digital multimeters and microwave ovens use this algorithm.

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

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

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

18. 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 by the tasks.

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

20. 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 instruction.

21. 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 synchronization.

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

23. 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 the tasks are kept in a queue and each task can acquire the semaphore one by one.

24. 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 interrupt, set the variable, access the shared resources, set the variable and lastly enable the interrupts.

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

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

27. Mailboxes A mailbox object is just like your mailbox.
A task can have a mailbox into which others can post a mail.

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

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

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

31. Message Queues (Contd…)

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

33. Pipes (Contd…) In UNIX/LINUX, we use the pipes as shell commands.
Consider the shell command $ cat hello.c | more

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

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

36. 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
Reset timer

37. Priority Inversion Problem
When tasks share a resource, there is a possibility of getting into a problem, known as priority inversion problem
To overcome this problem, priority inheritance protocol is used.

38. Priority Inheritance
The priority of the task which acquired the mutex will be increased to a value than the priority of the task competing for that resource.

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

40. 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.
Round – robin scheduling algorithm is not supported.

41. Features of µcos-ii Source Code: Portable:
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.

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

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

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

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

46. Kernel Structure of µcos-ii
Application Code
Processor Independent Code
Scheduling policy
Event flag
Semaphores
Mailboxes
Event queues
Task management
Time management
Memory management
Application Specific Configurations
OS_CFG.H
µcos-ii port for specific codes
Software
Hardware
CPU
Timer

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

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

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

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

51. 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 context switch occurs. 

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

53. Interrupts in µcos-ii (Contd…)

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

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