Real-Time Programming

Real-Time Programming Week 7: Real-Time Operating Systems Instructors Tony Montiel & Ken Arnold rtp@hte.com 4/1/2003 Co Montiel 1 Objectives o Introduction to RTOS o Event Driven Systems o Synchronization and Communication o Task Scheduling o Common RTOS Problems 4/1/2003 Co Montiel 2

Intro to RTOS o Operating System o Share/Allocate Resources: CPU Time Memory I/O o Real Time OS o Event Driven Tasks 4/1/2003 Co Montiel 3 Event Driven Systems o Processing Required When Events Occur o Asynchronous With Respect to Program o System Must Respond to Events o Multiple Events Can Occur Simultaneously o RTOS Attempts to Allocate CPU Time 4/1/2003 Co Montiel 4

Event Driven Systems o The hardware and software together take action as a direct result of the occurrence of an event. o When an event occurs: Other processing is suspended The event is processed Other processing is resumed o Usually these are also Real Time systems 4/1/2003 Co Montiel 5 Polling Events o The simplest, but least efficient method of determining if an event has occurred o Processor waits in a loop for the event o Often used in simple I/O handlers: Wait: Input buffer full? No: jump to Wait Yes: read input data buffer and continue Processor does nothing else... 4/1/2003 Co Montiel 6

Embedded RTOS Concepts o Resource Allocation: CPU Time Round Robin vs. Priority, Preemptive vs. Non-preemptive Memory I/O o Inter-Task Communication o Tasks Scheduling, States o Hiding Hardware Details 4/1/2003 Co Montiel 7 Tasks States, Scheduling o Context Preservation & Restoration Issues: Co-processors, Limited Stack Size... o Task Control Data Structures o Limited Embedded Resources: R/W Volatile Memory Non-volatile Memory Register Banks Timers, Counters, Peripherals 4/1/2003 Co Montiel 8

Differences: Embedded OS o Harvard Architecture is Common o Code in ROM, Data in RAM o Limited Memory Resource Allocation o File System is Limited or Non-Existent o Different Storage Media: Magnetic Media is Rare Solid State Media Common Flash Memory is NOT Like Disk 4/1/2003 Co Montiel 9 RTOS Alternatives o >70% of Embedded Developers Don t Use an RTOS Why? o Disadvantages of Commercial RTOS: Cost, Complexity, Efficiency Issues Customization Req d, Latency, Overhead o Embedded Environment Differences Memory Sizes, Types Cost, Volume, Risks 4/1/2003 Co Montiel 10

RTOS Task State Diagram 4/1/2003 Co Montiel 11 uc/os State Diagram 4/1/2003 Co Montiel 12

Synchronization & Communication o Synchronizing Tasks Semaphores Waiting for Event or Time o Inter-Task Communication Mailbox (Pointer) Circular Queue or Buffer 4/1/2003 Co Montiel 13 What is IPC? o IPC: Inter-Process Communications o Also works for Inter-Task Communications. o A safe method for passing data, messages, and/or events between tasks. o Multiple Processor IPC is a special case. 4/1/2003 Co Montiel 14

Why IPC? o Embedded systems are event driven. o IPC supports this model by allowing tasks to block on the IPC method. o Tasks can be independently developed. Higher reliability by reducing dependencies. 4/1/2003 Co Montiel 15 Why not IPC? o 1 task. o Very simple architecture. o Performance requirements. 4/1/2003 Co Montiel 16

Methods of IPC o Queues o Mailboxes o Signals/Events/Semaphores o Shared Memory 4/1/2003 Co Montiel 17 Queues o Typically implemented as a ring buffer. o Message is copied into and out of the queue buffer. o Disadvantages: Moving the data twice. May consume more memory than other methods. o Advantages: Data is protected. 4/1/2003 Co Montiel 18

Queues o Implementation Dependant Features: Writer may block if queue is full. Reader may block if queue is empty. There can be multiple readers/writers. Messages may be fixed or variable length. FIFO, maybe with priority. 4/1/2003 Co Montiel 19 Queues o Sample APIs: CreateQueue( QControlBlock, Name, StartAddress, Size, <Fixed/Var>, <MsgLen> ); WriteQueue( QControlBlock, Msg, Size, Suspend ); ReadQueue( QControlBlock, Msg, Size, ActualSize, Suspend ); 4/1/2003 Co Montiel 20

Mailboxes o Essentially a fixed size queue with element size equal to size of pointer. o Disadvantages: Data is not protected. Data must remain in scope. Not clear when data has been consumed. o Advantages: Faster than queues. More efficient than queues. If data fits in place of pointer, then this is a queue. 4/1/2003 Co Montiel 21 Mailboxes o Implementation Dependant Features: Subset of queues features. o Sample APIs: CreateMBox( MBoxControl, Name ); WriteMBox( MBoxControl, Msg, Suspend ); ReadMBox( MBoxControl, Msg, Suspend ); 4/1/2003 Co Montiel 22

Signals/Events/Semaphores o Used as an IPC mechanism, semaphores: Allow for synchronization between tasks. Allow ISR and task to communicate. HEY! Data is ready! o Disadvantages: Minimal amount of data (1 bit). Overhead slower than shared variable. o Advantages: Task can block on semaphore. Controlled IPC mechanism (vs. shared variable). 4/1/2003 Co Montiel 23 Signals/Events/Semaphores o Implementation Dependant Features: Event groups: collection of semaphores which can be logically combined to form truth table : Resume task when Ev1 && Ev3 &&!Ev4. 4/1/2003 Co Montiel 24

Semaphores o MUST have Indivisible Test and Set One atomic operation Test & Set o May Also Be Multi-Valued Useful for Multiple Shared Resources -63 to +32767 for uc/os o Mutually Exclusive Access to a Shared Resource: a.k.a. Mutex 4/1/2003 Co Montiel 25 Semaphore vs. Mutex o Mutex: Binary Semaphore Two states: available or busy o Semaphore: Binary (Mutex) or > 2 states (counting): counting semaphore -- increment or decrement example: sharing "n" resources or devices sempaphore = number of available resources 4/1/2003 Co Montiel 26

Example: getsemaphore() bit getsemaphore( uint8 *semaphore ) { bit result = 0; // Assume failure. bit oldea = EA; // Save current state. EA = 0; // Disable interrupts. if ( *semaphore > 0 ) // Any resources avail? { *semaphore = *semaphore - 1; // Grab one. result = 1; // Good to go. } EA = oldea; // Restore interrupts. // NOTE: Could give up processor if we didn t // get the semaphore. return result; } 4/1/2003 Co Montiel 27 Example in Assembly Acquire_Semaphore: ; Acquire semaphore ; Returns with A=1 if success, ; A=0 if failure to acquire semaphore. mov a,#1 ; Assume we got it. jbc sema4_bit, got_sema ; Atomic Test & Clr. clr a ; Failed to acquire. got_sema: ret Release_Sempahore: ; Release semaphore. setb sema4_bit ; Restore flag. ret 4/1/2003 Co Montiel 28

Shared Memory o Can always use shared memory for all the previously mentioned IPC mechanisms. o Disadvantages: Not thread-safe, unless hardware lock available. No controls to prevent misunderstandings. o Advantages: Fast. No RTOS overhead. Ring Buffer can be thread safe with one producer and one consumer. 4/1/2003 Co Montiel 29 Task Scheduling o Scheduler Allocates CPU Time o Determines Which Task to Run Next Context Switch uc/os uses: Priority Based, number 0-63 High Priority (0) Supercedes Low Priority (63) High Priority Tasks can Interrupt Low Ones o Overhead: Time Wasted, Not Spent on Task 4/1/2003 Co Montiel 30

Schedulers o There are basically two types of scheduling schemes in use today: Priority Round-robin o This is not to be confused with preemption (a.k.a time-slicing) and non-preemption (or cooperative) multi-tasking. o Schedulers can implement multiple combinations of the above methods. 4/1/2003 Co Montiel 31 uc/os Priorities o 64 Priorities o One Unique priority for each task o Lower number = higher priority o Example priorities used by sample firmware for a TCP/IP stack and server applications: MAIN_PRIO 50 HTTP 45 PPP 44 TCP 40 IP 39 Ethernet Send 38 4/1/2003 Co Montiel 32

Task Priorities and Blocking o Task priorities must be chosen carefully o If you create a high priority task that never blocks, lower priority tasks will never run o For example, task A has a priority of 50 and constantly polls an peripheral status register. Task B is assigned a priority of 51 and is used for a serial command interface. In this case, Task B will never run. 4/1/2003 Co Montiel 33 Kernels o The Kernel is responsible for task management and communication between tasks. o Kernels can be Preemptive or Nonpreemptive o The Scheduler is a part of the Kernel. 4/1/2003 Co Montiel 34

Round-Robin Scheduling o Basically, tasks run in a pre-defined order. o For example: Say you have 3 tasks (T1, T2, T3). Their execution order is T1, T2, then T3. Whenever T1 releases the CPU (a different story), if T2 is ready to run it will be allowed to run. After T2 is done, T3 will run (assuming it is ready). After T3 is done, T1 will get to run again. 4/1/2003 Co Montiel 35 Priority Scheduling o Each task is given a priority. o Higher priority tasks run before lower priority tasks. o For example: Say T1 has highest priority and T3 lowest. T2 is running. T1 and T3 are ready at the same time. T1 will be allowed to run. 4/1/2003 Co Montiel 36

Non-Preemptive Kernel o Each task must specifically do something to give up control of the CPU o Also called cooperative-multitasking o ISR s interrupt tasks, but do not immediately determine which task will run upon completion o Simpler to implement than pre-emptive. o Critical section easier to design away. 4/1/2003 Co Montiel 37 Non-Preemptive Example From uc/os-ii page 43 4/1/2003 Co Montiel 38

Preemptive Kernel o Used for Real-Time applications o Highest priority task always runs o A task switch will occur when: A task makes a higher priority task ready to run. An ISR completes o More complicated to implement o Critical section issue more pronounced. 4/1/2003 Co Montiel 39 Preemptive Example From uc/os-ii page 44 4/1/2003 Co Montiel 40

Re-entrant Code o Code that can be interrupted, and called again one or more times, before completing execution. Must use only local resources (i.e.variables) Cannot modify global resources Compiler libraries are often non re-entrant Most OS functions are non re-entrant Code that uses dedicated hardware is not 4/1/2003 Co Montiel 41 Common RTOS Problems o Task Stack Size o Stack Overflow o Scheduling Issues o Preemptive Task Priority o Getting Stuck... 4/1/2003 Co Montiel 42

Deadlock o Circular dependency between tasks and resources o Task1 takes MutexA, waits on MutexB o Task2 takes MutexB, waits on MutexA o DEADLOCK: Waiting for an event which will never occur. o Only way to end is reboot. 4/1/2003 Co Montiel 43 Deadlock Example Task A Resource1 Task B Resource2 = Has Acquired = Is Requesting 4/1/2003 Co Montiel 44

Determinism o A system is guaranteed to behave in a predictable way. o Priority inversion can make the system unpredictable: A low priority tasks behaves like a high priority task. 4/1/2003 Co Montiel 45 Priority Inversion o Higher priority task blocks, waiting for a lower priority task. o OK thus the reason for mutexes. o 3 rd task comes along and can run. o This affects determinism. o Very bad for hard real-time systems. 4/1/2003 Co Montiel 46

Priority Inversion Example High Priority Med Priority Low Priority t0 t1 t2 t3 t4 t5 t6 t7 = task blocked = priority inversion 4/1/2003 Co Montiel 47 Priority Inheritance task + PI High Priority Med Priority Low Priority t0 t1 t2 t3 t4 t5 t6 = task blocked = Priority inheritance active 4/1/2003 Co Montiel 48

Additional Reading o http://www.ganssle.com/tem/tem14.pdf This is the discussion of the Mars Pathfinder mission. Very interesting reading. 4/1/2003 Co Montiel 49 A Critical View o Commercial RTOS: any co-operative? o May not be due to technical reasons: Co-operative schedulers easier to make. Co-operative schedulers are portable. Pre-emptive RTOS much larger and more complex (uc/os: ~3000 vs. Pont: ~300) This may make them unsuitable for inhouse development. 4/1/2003 Co Montiel 50

RTOS Strategic Issues o License Fees, Development Costs o Learning Curve is Non-Trivial o Long Term RTOS Vendor Stability o Lack of Visibility and Control o Availability of Source Code o Upgrades, Support, Obsolescence o Development of Internal RTOS 4/1/2003 Co Montiel 51 Summary o OS Concepts o Resource Sharing / Allocation o Use only the elements needed. o For simplest situations, shared memory may be best approach. o Variety of IPC mechanisms exist: Queues, Mailboxes, Signals/Events/Semaphores 4/1/2003 Co Montiel 52