P. 1
RTOS

RTOS

|Views: 147|Likes:
Published by Sushil Yadav

More info:

Published by: Sushil Yadav on May 16, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

09/15/2012

pdf

text

original

Real Time Operating Systems -RTOS

-

Kaiserslautern University of Technology June 2006
serna_oliver@eit.uni-kl.de

Ramon Serna Oliver

Outline

Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references

28.06.06

RTOS - R.Serna Oliver - TU Kaiserslautern

2

Outline

Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references

28.06.06

RTOS - R.Serna Oliver - TU Kaiserslautern

3

06.Basic concepts ● What is the OS? Basic structure of the OS OS classification ● ● 28.06 RTOS .TU Kaiserslautern 4 .R.Serna Oliver .

network.What is the OS? ● Collection of system calls (functions) – Provide a set of basic services to interact with the hardware Typically a library or set of libraries Tends to be small and highly optimized Might be (or not) other high level services on top ● ● The core of the OS is the Kernel – – – graphic interface.TU Kaiserslautern 5 28. i/o.06..Serna Oliver .06 . desktop environment.R. RTOS .. etc. user interfaces.

TU Kaiserslautern .06 RTOS .Basic structure of the OS ● An operating system provides: – – Resource allocation Task management.R.Serna Oliver .06. scheduling and interaction Hardware abstraction I/O interface Time control Error handling 6 – – – – 28.

portable.Serna Oliver .OS classification ● Depending on.06. 28.R.TU Kaiserslautern 7 . ● Real OS are a mixture of the above.06 RTOS . POSIX).. standard compliant (i.e. – – – – response time: batch / interactive / real-time users: multi / single user execution mode: multi / single task others: embedded..

Outline

Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references

28.06.06

RTOS - R.Serna Oliver - TU Kaiserslautern

8

Real Time Operating Systems RTOS

Main features Other features

28.06.06

RTOS - R.Serna Oliver - TU Kaiserslautern

9

RTOS: Main features

Same basic structure than a regular OS, but... In addition it provides mechanisms to allow real time scheduling of tasks:

Deterministic behavior of all system calls (!)

All operations (system calls) must be time bounded
– –

No memory swap (virtual memory) is typically allowed “Special” hw interaction. Ad-hoc drivers (!)

Interrupt service routines (ISR) time bounded

28.06.06

RTOS - R.Serna Oliver - TU Kaiserslautern

10

but less “comfortable” to the user Modular structure – – 28. mailboxes.TU Kaiserslautern 11 . monitors..Serna Oliver . .. Hardware access is done at a lower level – ● faster.06 Unused modules can be discarded to save space/resources RTOS . message queues.RTOS: Other features ● Task priority policy Can be dynamic or static Inter-task communication and synchronization – ● ● semaphores.R.06. buffers.

Serna Oliver .06 RTOS .Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references ● ● ● ● ● ● ● 28.R.06.TU Kaiserslautern 12 .

06.R.06 RTOS .RTOS Design considerations ● Memory management I/O Management Time handling Limited resources considerations ● ● ● 28.Serna Oliver .TU Kaiserslautern 13 .

Serna Oliver .06.06 RTOS .Memory Management ● Common memory handling is unpredictable – Memory allocation time increases depending on ● ● block size status of the memory (“clean or dirty”) – fragmentation ● swap / virtual memory (depends on HD) 1) No memory handling at all 2) Limited memory management – Solution ● ● 28.TU Kaiserslautern 14 .R.

Memory Management (II) ● Example of RTOS memory manager: – Only certain blocs of fixed size of dynamic memory can be required by tasks.06.R.TU Kaiserslautern 15 .Serna Oliver .06 RTOS . Blocks are stored in a “free buffer queue” – 28.

Memory Management (III) ● Advantages: – No fragmentation ● A block is always taken and used as an unit – – No need of garbage collection (!) Easily implemented as constant functions (deterministic behavior!) ● get_mem() and set_mem() vs malloc() and free() ● Disadvantages: – – Limited choice of chunks size Suboptimal usage of memory resources RTOS .06.06 .R.TU Kaiserslautern 16 28.Serna Oliver .

random delays (CSMA/CD).R. ie: void safe_printf(char *txt) { get_semaphore(s). } – I/O functions are typically non reentrant ● ● 28.. release_semaphore(s).06.Serna Oliver .TU Kaiserslautern 17 . . hw failure.I/O Management ● Unpredictable hw behavior: – No control over the device behavior ● ie: disc segmentation..06 RTOS . printf(txt). network collision. ie: printf() is not appropriated for RT applications New reentrant functions provided.

. spinning speed.I/O Management (II) ● CPU & RAM are controllable Other devices are commonly unpredictable – ● i.R.e. HD access is non deterministic ● Depends on header position. latency.06 RTOS .. Development of ad-hoc drivers (!) Assembler and low level code = platform dependent – Manufacturers drivers are not Real Time compliant ● ● 28.TU Kaiserslautern 18 ..06.Serna Oliver .

06.R.06 .Serna Oliver .TU Kaiserslautern 19 28.Time handling ● Time control is a main thing – Task scheduling ● ● deadlines (!) delay() & delay_until() functions – ● Time outs depends on hw might be adjustable by the user ● Time resolution – – >resolution → >overhead (!) RTOS .

RTOS .06.. Size restrictions Limited power consumption .Limited resources ● RTOS commonly oriented to Embedded systems – Little resources available ● ● ● micro controllers low power CPUs ..06 ...R.TU Kaiserslautern 20 – Little space to add cool stuff ● ● ● 28.Serna Oliver .

Serna Oliver .R.06 RTOS .06.Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references ● ● ● ● ● ● ● 28.TU Kaiserslautern 21 .

06.R.Serna Oliver .Tasks and scheduler in RTOS ● What is a task for us (users/programmers)? What is a task for the OS? Task states Scheduler ● ● ● 28.TU Kaiserslautern 22 .06 RTOS .

R...TU Kaiserslautern 23 28.06.What is a task for us? ● A task is a piece of executable code – – – – a function (procedure) a program a kernel module .Serna Oliver .06 . Tasks run concurrently ● ● ● A program consists of one or more tasks – Real concurrence in multi-processor system Pseudo concurrence in single-processor systems RTOS .

... – – ● Task status Other relevant information Create task = create TCB Destroy task = delete TCB RTOS .R..What is a task for the OS? ● Task Control Block (TCB) – – TCB Task ID Task Priority Program Counter (PC) @ Task Memory @ Registers Task Status Waiting resource Next TCB (.Serna Oliver .) Task ID and Task Priority Copy of last execution context ● CPU registers. stack.06.TU Kaiserslautern ● 28..06 24 .

06.06 RTOS .R.Task States ● Executing Ready Blocked Waiting : actually running : Ready to be dispatched : blocked by another task or resource : blocked by time EXECUTING ● Dispatch ● ● BLOCKED/ WAITING READY List of TCBs 28.Serna Oliver .TU Kaiserslautern 25 .

Serna Oliver .06.06 .R.TU Kaiserslautern 26 – Time triggered ● – Event triggered ● 28.Scheduler ● Scheduler – Implement a scheduling policy ● ● ● select next task to be executed maintain queues (order by?) maintain priorities (static? dynamic?) Kernel executes periodically Kernel executes only when “something” happens RTOS .

TU Kaiserslautern 27 .06.Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references ● ● ● ● ● ● ● 28.06 RTOS .Serna Oliver .R.

Communication & Synchronization ● Needs of communication and synchronization Communication mechanisms Synchronization mechanisms ● ● 28.R.06.06 RTOS .TU Kaiserslautern 28 .Serna Oliver .

wait for an intermediate result i. producer / consumer mutual exclusion (mutex) ● Tasks need to synchronize – “meeting points” ● ● i.e. wait for the end of another task RTOS .e.e.06 .TU Kaiserslautern 29 28.Tasks communication and Synchronization ● Tasks need to communicate – sharing data ● ● ● i.Serna Oliver .06.R.

06.TU Kaiserslautern 30 . message). – – Task blocked until a message is available Message deleted after reading 28.Communication ● Mailboxes: – A task sends a message to a mailbox ● message_send(id_mailbox.R.Serna Oliver . – Task blocked if mailbox full – A task reads a message from a mailbox ● m= message_read(id_mailbox).06 RTOS .

R.06.TU Kaiserslautern 31 .Serna Oliver .Communication (II) ● Message queues: – Same concept as Mailboxes but more than one message can be stored (fixed capacity) ● ● Sender can send up to N messages before being blocked Reader gets messages in FIFO order 28.06 RTOS .

R. optional protocols to avoid priority inversion RTOS .TU Kaiserslautern 32 – 28.Serna Oliver .06.Communication ● Mutex – Two basic atomic operations: ● mutex_lock() – – blocks execution until mutex is unlocked then locks mutex unlock mutex ● mutex_unlock() – – Only one task can enter a section protected by mutex.06 .

mutex_unlock(m). mutex_unlock(m).. global_id ++.06. } } 28..TU Kaiserslautern 33 .Communication ● Example: Task A mutex m. .06 void taskB() { while (1) { mutex_lock(m) id_b = global_id. int global_id = 0.. Task B void taskA() { while (1) { mutex_lock(m) id_a = global_id. } } RTOS . global_id ++.Serna Oliver ..R. .

Serna Oliver .TU Kaiserslautern 34 28.Synchronization ● Semaphores – Two basic operations (similar to MUTEX) ● wait_semaphore() – – decrement resource counter block execution if counter = 0 increment resource counter if value<=0 one of the blocked tasks continues execution ● signal_semaphore() – – – Plus initial value ● number of available resources (>=0) – resource counter RTOS .06.06 .R.

. wait_semaphore(s) get_result()... signal_semaphore(s). .Serna Oliver .Synchronization ● Example: Task A semaphore s = init_semaphore(0).06. } } 28.. } } RTOS . ..R.... Task B void taskB() { while (1) { .TU Kaiserslautern 35 void taskA() { while (1) { .06 . produce_result().

06.TU Kaiserslautern 36 .R.Serna Oliver .06 RTOS .Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example POSIX Standard Conclusions and references ● ● ● ● ● ● ● 28.

06.R.Example ● Simple example with two tasks Notes ● 28.06 RTOS .Serna Oliver .TU Kaiserslautern 37 .

Serna Oliver ..R. } } Priority = 2 Period = 50 Execution time = 10 38 RTOS . } } Priority = 1 Period = 10 Execution time = 5 28.... sleep_until(time+50). sleep_until(time+10).Example (I) Task 1 (T1) void task1(void *param) { while (1) { .06.TU Kaiserslautern .06 Task 2 (T2) void task2(void *param) { while (1) { . echo(“task 1”). echo(“task 2”).

t2 = create_task(*task2. NULL.Example (II) void main() { Task Creation (main) char *mem1[100]. mem1. @mem. int t1. 1). priority */ t1 = create_task(*task1. @param. /* OS starts executing */ os_start(). } /* end */ 28. t2.Serna Oliver .06.06 RTOS .TU Kaiserslautern 39 . NULL.R. *mem2[100]. 2). mem2. /* create_task(@code.

R.TU Kaiserslautern 40 T2 T1 0 5 10 15 20 25 30 35 40 45 50 .06 RTOS .Example (III) Blocked Initially both tasks (T1 and T2) are ready to execute Waiting Ready T1 T2 Running PC = Stack = Mem = 28.06.Serna Oliver .

TU Kaiserslautern 41 28.Example (IV) Blocked T2 remains Ready T1 becomes the Running task Waiting T2 Ready T2 Running T1 PC = ~task1() Stack = stack1 Mem = mem1 T1 0 5 10 15 20 25 30 35 40 45 50 PC.06 .R.Serna Oliver .06. memory and CPU registers are updated from the TCB of T1 RTOS . stack.

R.TU Kaiserslautern 42 28.Example (V) Blocked T1 reaches the end of the loop.06.Serna Oliver . memory and CPU registers. Sleeps until “time+10” T2 becomes the Running task Waiting T1 T2 Ready T1 0 5 10 15 20 25 30 35 40 45 50 Running T2 PC = ~task2() Stack = stack2 Mem = mem2 TCB of T1 is updated with PC. memory and CPU registers are updated from the TCB of T2 RTOS . stack. PC. stack.06 .

06.Example (VI) Blocked T1 becomes ready again At this point T2 still has 5 units to execute T2 Waiting Ready T1 Running T2 PC = ~task2() Stack = stack2 Mem = mem2 T1 0 5 10 15 20 25 30 35 40 45 50 28.TU Kaiserslautern 43 .06 RTOS .Serna Oliver .R.

stack. memory and CPU registers.Serna Oliver .Example (VII) Blocked T1 preempts T2 since it has higher priority Execution of T2 is preempted by a higher priority task T2 Waiting Ready T2 Running T1 PC = ~task1() Stack = stack1 Mem = mem1 T1 0 5 10 15 20 25 30 35 40 45 50 TCB of T2 is updated with PC. PC.06 .06. stack. memory and CPU registers are updated from the TCB of T1 RTOS .R.TU Kaiserslautern 44 28.

stack.Example (VIII) Blocked T1 reaches again the end of the loop and finishes its execution T2 can now continue its execution T2 Waiting T1 Ready T1 0 5 10 15 20 25 30 35 40 45 50 Running T2 PC = ~task2() Stack = stack2 Mem = mem2 TCB of T2 is updated with PC.06. memory and CPU registers. memory and CPU registers are updated from the TCB of T1 RTOS .06 . stack.Serna Oliver .TU Kaiserslautern 45 28.R. PC.

stack. PC. memory and CPU registers are updated from the TCB of T1 RTOS .Serna Oliver .R. memory and CPU registers.TU Kaiserslautern 46 28.06 . stack.06.Example (IX) Blocked T2 reaches the end of its loop and finishes its execution T1 executes again (after moving from Waiting to Ready) Waiting T2 T2 Ready T1 0 5 10 15 20 25 30 35 40 45 50 Running T1 PC = ~task1() Stack = stack1 Mem = mem1 TCB of T2 is updated with PC.

TU Kaiserslautern 47 .Serna Oliver .06.R.06 And now what ? RTOS .Example (X) Blocked T1 reaches the end of its loop and finishes its execution No task is ready to be executed!! Waiting T2 T1 T2 Ready T1 0 5 10 15 20 25 30 35 40 45 50 Running PC = ?? Stack = ?? Mem = ?? 28.

Example (XI) Blocked A special task IDLE is scheduled with the lowest priority in order to get the CPU when no other task is ready to execute Waiting T2 T1 T2 Ready Idle Task IDLE 0 5 10 15 20 25 30 35 40 45 50 Running PC = ?? Stack = ?? Mem = ?? 28.R.Serna Oliver .06.06 void idle(void *param) { while (1) { NULL } } T1 Priority = Lowest Always Ready to execute RTOS .TU Kaiserslautern 48 .

R.Serna Oliver . stack and memory are replaced like with any other task RTOS .Example (XII) Blocked The Idle task executes until any other task is available in the Ready queue Waiting Idle T2 T1 T2 Ready T1 0 5 10 15 20 25 30 35 40 45 50 Running Idle PC = ~idle() Stack = stack_idle Mem = mem_idle Again PC.06 .06.TU Kaiserslautern 49 28.

TU Kaiserslautern 50 . Running . Waiting Idle ... Stack = .Example (end) Blocked Execution continues..06... RTOS ..Serna Oliver .. PC = ... 0 5 10 15 20 25 30 35 40 45 50 T1 28......06 .. T2 Ready . Mem = .R..

Scheduling is based on selecting the appropriated task from (ordered) queues.R.Serna Oliver .Notes from the example ● Idle task is an infinite loop that gains CPU access whenever there is “nothing to do”.06. Task context is saved on its own TCB and restored in every new execution.06 . RTOS are preemptive since they “kick out” the current running task if there is a higher priority task ready to execute.TU Kaiserslautern 51 ● ● ● 28. RTOS .

R.06 .Notes from the example (II) ● Context switch might have effect: – Switching is not for free!: Context switch involves RTOS kernel execution and consequently overhead! RTOS T2 T1 This is where the TCB and CPU registers are updated and.TU Kaiserslautern 52 28.Serna Oliver .06. queues reordered (!) RTOS .

R.Notes from the example (III) ● What happens if tasks are blocked? ● Blocked X Task goes to blocked queue A pointer is set to/from blocking ● ● resource MUTEX.TU Kaiserslautern 53 . etc. ● BLOCKING RESOURCE Task is moved to “Ready” when the resource is free 28.06.. mailbox.Serna Oliver ..06 RTOS .

R.Serna Oliver .06.Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example “Real” RTOS POSIX Standard Conclusions and references RTOS .06 .TU Kaiserslautern 54 ● ● ● ● ● ● ● ● 28.

Serna Oliver .POSIX Standard ● Overview RT Extensions ● 28.06 RTOS .R.06.TU Kaiserslautern 55 .

Serna Oliver .R.POSIX: Overview ● Portable Operating System Interface Motivation – – ● Portability Interoperability Real time extensions ● ● Set of standards – POSIX 4 28.06.TU Kaiserslautern 56 .06 RTOS .

Serna Oliver .TU Kaiserslautern 57 .06 RTOS .06.POSIX: RT Extensions ● Real Time Scheduling – 3 policies ● ● ● FIFO Round Robin Other (implementable) ● Virtual Memory – Special functions to bound v.R. mechanisms 28.m.

TU Kaiserslautern 58 28.06 .POSIX: RT Extensions ● Process Synchronization – Semaphores ● Priority inversion possible (!) ● Shared Memory – can be protected by semaphores Event notification ● ● ● ● Signals – signal priority queued data field RTOS .R.06.Serna Oliver .

Serna Oliver .POSIX: RT Extensions ● Message queues – – message priorities sending and receiving can be blocking or not Clock ● ● Time – resolution = nanoseconds programmed to a certain interval expiration sends a signal to the owner process RTOS .06.TU Kaiserslautern 59 – Timers ● ● 28.R.06 .

TU Kaiserslautern 60 .Serna Oliver .06.R.POSIX: RT Extensions ● Asynchronous I/O – – No wait for I/O operation A signal is sent when done Threads Timeouts ● ● Other extensions: – – limit blocking periods 28.06 RTOS .

R.Outline ● Basic concepts Real Time Operating Systems RTOS Design considerations Tasks and scheduler in RTOS Tasks communication and synchronization Example “Real” RTOS POSIX Standard Conclusions and references RTOS .TU Kaiserslautern 61 ● ● ● ● ● ● ● ● 28.06.06 .Serna Oliver .

06 .R.Conclusions ● RTOS : deterministic OS Design of RT Systems – ● Limited by: ● Time & Resources TCB queues – Tasks ● – Scheduler ● ● POSIX : Portable RT systems RTOS .TU Kaiserslautern 62 28.Serna Oliver .06.

Obenland – ● ● ● http://www.com/story/OEG20010312S0073 ● “Real-Time POSIX: An Overview”.html 28.06. ed.Com – ● http://www.com/rtos/rtos. Kevin M.06 RTOS .Serna Oliver . John A. Guillem Bernat.R.References ● Operating Systems. Univ. Prentince Hall “Diseno de Sistemas en Tiempo Real”. UIB “Missconceptions about Real-Time Computing”. Ramon Puijaner. Stankovic “POSIX in Real-Time”. Michael Gonzalez Harbour.onesmartclick. Cantabria OneSmartClick.TU Kaiserslautern 63 . William Stallings. Albert Llamosi.embedded.

R.06 RTOS .Serna Oliver .TU Kaiserslautern 64 .06.The End Thank you! 28.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->