1230 Rtf Final

Objectives When you finish this class you will know: The terminology used in the RTOS world What functions an RTOS provides and how it affects your programming style What factors to consider when choosing an RTOS for your next project

Agenda When is an RTOS appropriate? RTOS Introduction Concepts Terminology Operation Techniques Demonstrations Current Support How to choose Factors influencing your decision

Why an RTOS? Efficient Resource Management 4 UARTs, 3 SPI, 3 I 2 C™, CTMU, USB (Device/Host/OTG), Ethernet, CAN…. Deterministic behaviour Provable real-time response Rapid application development Commercial RTOSs provide well-tested platform Popular RTOSs provide large pool of knowledge Structured Design and System Management Software re-use CASE Tools System Profiling

Why an RTOS? Software Management Stacks USB ~40k ZigBee ~40k Ethernet ~85k QVGA ~50k Timing Liberating time for multiple tasks Interoperability Third party software lwIP Compliance Testing OSEK, AutoSAR

Concepts and Terminology Pre-emption Deterministic Multitasking Hard Real-Time Mailbox Co-operative Multitasking Livelock Priority Inversion Priority Inheritance Thread Task Mutex Soft Real-Time Round-Robin Semaphore Context Switch Queue Deadlock Re-entrancy

Task A group of instructions that execute to solve a portion of a problem A “problem” could be: Design of a dishwasher system A “task” for such system can be: Manage water level Manage motor speed A single task ‘thinks’ that it has the CPU available all the time

Dishwasher System Water Level Manager Door Manager Button Manager Cycle Selection Manager Manage Motor Speed

Multitasking What is it? Ability to do many things at once Drink coffee, talk on cell-phone, drive, switch lane ‘ Manage water level’ and ‘Manage motor speed’ Tasks can be created and deleted at run-time Typically fixed number of tasks at compile time Sometimes extra tasks automatically created User Issues: Resource sharing CPU, Memory, I/O, etc. Synchronization Inter-task communication

RTOS Related Task Calls Create – to create a new task Start – some RTOSs require starting a task after creation Delete – to delete a task RTOSs may not release some system memory Less common in embedded systems Suspend – to wait execution Resume – to resume execution Change Priority – to dynamically change task priority

Scheduling What is it? Multi-tasking requires all tasks get scheduled to run on CPU according to some pre-determined scheme Types of Scheduling: Co-operative, Pre-emptive Typical Real Time System Uses Pre-emptive Round-robin, Deadline Monotonic, Least Slack-Time etc. Issues: Task Deadlines Missed deadlines may have severe consequences Context Switch Time

Scheduling Tasks Real-time Does not always mean ‘fast’ Tasks must be written to obtain best predictable response Soft Real-time Tasks will generally run on-time Little effect if tasks are delayed Hard Real-time Tasks must be allowed to run on-time Serious problems if task execution is delayed

Co-Operative Multitasking Tasks execute until they pause or yield Must be written to explicitly yield System performance can be optimised Tasks can be given priorities Scheduler while (1) { x = x + 1; for(i=0;i<10;i++) { x = x * 2; } taskYIELD(); } while (1) { for(i=0;i<1000;i++) { y = y * 2; if ((x % 100) == 0)‏ taskYIELD(); } taskDelay(100); }

Pre-emptive Multitasking Tasks are swapped either voluntarily or automatically by the RTOS Tasks normally selected based upon priority Scheduler while (1) { for(i=0;i<10;i++) { x = x * 2; x = x * 3; } taskYIELD(); } while (1) { for(i=0;i<1000;i++) { y = y * 6; y = y / 2; } taskDelay(100); }

Priority Real-time systems are hierarchical Each task gets to execute according to pre-determined-priority Priority determines right to run on CPU Priorities can be dynamically changed Truly deterministic real-time systems assign different priority to each task Round-robin for equal priorities

Round-Robin Scheduling Each task is given a fixed time to execute Must be written accordingly The scheduler runs each task in turn Scheduler Task 1 Task 2 Task 3 while(1) { switch(x) { case 0: … break; case 1: … break; } } while(1) { switch(x) { case 0: … break; case 1: … break; } } while(1) { switch(x) { case 0: … break; case 1: … break; } }

Priority-based Pre-emptive Multi-tasking Priority Time t0 Multi-tasking Starts HP Runs MP Runs t1 HP Waits for Event LP Runs t2 MP Finishes LP Runs HP Runs t3 Event HP was waiting for occurs LP Runs t4 HP waits for Resource LP Runs HP = Highest Priority Task, MP = Medium Priority Task, LP = Lowest Priority Task HP, MP and LP are READY at time t0 LP Pre-empted & Ready MP Ready LP Ready LP Ready HP Wait MP Dormant MP Dormant MP Dormant HP Wait HP Wait

Context Switches During a yield or pre-emption the task pushes the processor state The RTOS determines the next task to run The processor state is popped The next task runs int x; double y; char buff[2]; Task 1 int count; char ledState; Task 2 PC PSVPAG w0-w15 SR PC PSVPAG w0-w15 SR ?

Example PIC24F #define portRESTORE_CONTEXT() \ asm volatile("MOV _pxCurrentTCB, W0 \n“ \ "MOV [W0], W15 \n“ \ "POP W0 \n“ \ "MOV W0, _uxCriticalNesting \n“ \ "POP PSVPAG \n“ \ "POP CORCON \n“ \ "POP TBLPAG \n“ \ "POP RCOUNT \n“ \ "POP W14 \n“ \ "POP.D W12 \n“ \ "POP.D W10 \n“ \ "POP.D W8 \n“ \ "POP.D W6 \n“ \ "POP.D W4 \n“ \ "POP.D W2 \n“ \ "POP.D W0 \n“ \ "POP SR " ); #define portSAVE_CONTEXT() \ asm volatile( "PUSH SR \n“ \ "PUSH W0 \n“ \ "MOV #32, W0 \n“ \ /*disable INTs*/ "MOV W0, SR \n“ \ "PUSH W1 \n“ \ "PUSH.D W2 \n“ \ "PUSH.D W4 \n“ \ "PUSH.D W6 \n“ \ "PUSH.D W8 \n“ \ "PUSH.D W10 \n“ \ "PUSH.D W12 \n“ \ "PUSH W14 \n“ \ "PUSH RCOUNT \n“ \ "PUSH TBLPAG \n“ \ "PUSH CORCON \n“ \ "PUSH PSVPAG \n“ \ "MOV _uxCriticalNesting, W0 \n“ \ "PUSH W0 \n“ \ "MOV _pxCurrentTCB, W0 \n“ \ "MOV W15, [W0] ");

Demo 1 Demo concepts: Task Creation Multi-tasking

Resources What is it? Anything that a task depends on Communication channel System data-structures Memory Multiple tasks may use the same resource Issues: Resource may be limited Multiple tasks may need the same resource at the same time resulting in resource contention Inefficient resource management may increase system overhead

Memory Management Typical RTOSs provide memory allocation facilities Frequently fixed block scheme Deterministic service calls Avoid memory fragmentation RTOS System Calls for Memory Allocation Allocate – allocate a block from memory Free – release a block of memory Query – query fixed block size, number of available blocks, etc. in a memory area

Events Events are signals to a task That affect the execution of a task Typically come from outside the task Can be combinatorial External hardware events Water level full in dishwasher Hardware pushbutton pressed Software events Another task has completed its operation Signal from an ISR

RTOS System Calls for Events Create – to create an event (group)‏ Delete – to delete an event Wait – to wait for an event to occur Also known as ‘pending’ Timeout available Signal – to signal occurrence of an event Query – to check status of an event (whether it is signaled or not)‏

Message Queue Standard method for inter-task communication Queue is allocated storage Definable size and number of entries May contain data or pointers Tasks can add messages Many tasks can write Tasks can pend on the queue

Mailbox What is it? Method to send ‘pointer’ sized asynchronous data between tasks Often implemented as a simple queue Tasks must agree on what ‘pointer’ points to Multiple tasks can wait on a message to be posted Highest priority task wins in retrieving message Multiple tasks can post a message Only one message can be present in the mailbox at any time

System Calls For Mailbox and Message Queues Create – allocate the Mailbox or Queue For queues, space for the queue must be allocated and its size must be specified to ‘Create’ call Delete – remove the Mailbox or Queue Pend – wait on message to become available A timeout period may be specified If no message is available, calling task may wait Post – put a message in Mailbox or Queue Query – inquire if tasks are waiting to receive message on a Mailbox or Queue Flush – remove all messages from Queue

Semaphore Semaphores are used for synchronization A flag that can only be modified atomically Protect Critical Section, Resource Management, Synchronization Two types of Semaphores: Binary – A value of 0 or 1 Counting – non-negative integer value Zero Another task is in specific critical section Resource is busy Non-zero You can enter critical section of code Resource is available I ssues: Priority Inversion

Mutex Prevents conflicting access to common resource Hardware Registers Peripherals Data structures The same as binary semaphore Mutexes can lead to deadlocks occurring RTOS provides priority inheritance to overcome problem of priority inversion Mutex may have inheritance

Deadlocks Each task waits for the other to release the mutex Neither completes Thread A Owns Mutex X Waits on Mutex Y Thread B Waits on Mutex X Owns Mutex Y Mutex X Mutex Y

RTOS System-calls for Semaphore and Mutex Create – allocate semaphore or mutex Initial value of the semaphore or mutex should be provided Delete – remove semaphore or mutex Get – try to acquire semaphore or mutex A timeout period may be specified If not available, the task waits Put – release semaphore or mutex Query – inquire the state of semaphore or mutex

Priority Inversion What is it? When a lower priority task holds a resource that a higher priority task needs, the higher priority task must wait (as if it were a lower priority task) until the lower priority task releases the resource In such scenario, the lower priority task executes as if it has higher priority Problem typically encountered in dealing with RTOS service like Semaphore Can be solved by Priority Inheritance Not always the best solution, design it out!

Priority Inversion Priority Time HP = Highest Priority Task, MP = Medium Priority Task, LP = Lowest Priority Task LP Running at t0 LP Runs t0 LP gets Sem1 HP Runs t1 HP created, LP ready LP Ready t2 HP waits for Sem1, LP runs LP Runs MP Runs t3 MP created, LP ready HP Wait LP Ready HP Wait MP Dormant LP Runs HP Wait t4 MP finishes, LP runs t5 LP puts Sem1, HP runs LP Ready MP Dormant HP Runs

RTOS Configuration Compile Time: Configuration header file Enable or disable OS services Maximums: semaphores, mutex, message queues Enable OS debug and statistic gathering facilities Run Time: Hardware specific initialization (BSP) Data structure initialization Initialization of resource managers Task creation, Memory allocations, Link-List creations Initialization of inter-task messaging Enter Multi-tasking

Example Configuration #define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 0 #define configTICK_RATE_HZ ( 1000 )‏ #define configCPU_CLOCK_HZ ( 80000000UL ) #define configPERIPHERAL_CLOCK_HZ ( 40000000UL )‏ #define configMAX_PRIORITIES ( 5 )‏ #define configMINIMAL_STACK_SIZE ( 200 )‏ #define configTOTAL_HEAP_SIZE ( 28000 )‏ #define configMAX_TASK_NAME_LEN ( 8 )‏ #define configUSE_TRACE_FACILITY 0 #define configUSE_16_BIT_TICKS 0 #define configIDLE_SHOULD_YIELD 1 #define configUSE_MUTEXES 1 /* Set the following definitions to 1 to include the API function, or zero to exclude the API function. */ #define INCLUDE_vTaskPrioritySet 1 #define INCLUDE_uxTaskPriorityGet 1 #define INCLUDE_vTaskDelete 0 #define INCLUDE_vTaskCleanUpResources 0 #define INCLUDE_vTaskSuspend 1 #define INCLUDE_vTaskDelayUntil 1 #define INCLUDE_vTaskDelay 1 #define INCLUDE_uxTaskGetStackHighWaterMark 1 /* The priority at which the tick interrupt runs. This should probably be kept at 1. */ #define configKERNEL_INTERRUPT_PRIORITY 0x01

Inter-task Communication Information passed between tasks; and between tasks and ISRs Two ways to perform inter-task communication: Global memory and semaphore or mutex Mail-box and Message Queues

Demo 2 Demo Concepts Inter-task Communication Message Queues

Critical Sections What is it? A sequence of code that must execute atomically E.g. update system data-structures Semaphores and Mutexes used to guard Critical Sections Locking interrupts (or scheduler) may be desirable If manipulating only one variable or so Less OS overhead This may degenerate Interrupt Response

Demo 3 Demo Concepts Critical Sections Semaphore Note Critical Section in parallel port code PIC32 version does not use Critical Section

RTOS Vendors 16/32 16 32 8/16/32 8/16/32 16/32 16/32 8/16/32 Microchip 16/32 Ports GUI, TCP/IP DSP, TCP/IP, POSIX TCP/IP TCP/IP Modules/ Support N Salvo 4 Pro and Salvo 4 LE Pumpkin N DSPNano Unison RoweBots Yes embOS V3.52 Segger Yes µC/OS-II v2.86 Micrium Yes FreeRTOS v5.0 FreeRTOS Yes ThreadX G5.1.5.0 Express Logic Yes CMX 5.30 CMX Systems MPLAB ® Plug-in Product Vendor

RTOS Vendor Websites CMX: http://www.cmx.com/ Express Logic: http://www.rtos.com/ FreeRTOS: http://www.freertos.org/ Micrium: http://www.micrium.com/ Pumpkin: http://www.pumpkininc.com/ RoweBots: http://www.rowebots.com/ Segger: http://www.segger.com/

Factors influencing Many factors: Context Switch Time RTOS Service Call Performance Interrupt Response Time Highest Priority Interrupt Response Time Scheduling Algorithms Tools and Middleware Integration Additional libraries for TCP/IP, DSP, Graphics Business Model Freeware, Open Source, Support, License, Royalties Reliability and user base

The Numbers Game Some RTOS vendors have done testing on Context switch time, Size, Interrupt response time, etc. However, few numbers are officially released Like-for-like comparisons can be difficult It is very difficult to recommend one product Much depends on the application Users should expect to perform some tests

Summary We discussed: Where an RTOS is useful The basic concepts behind an RTOS The terminology used Several demonstrations What to think about when selecting an RTOS Please attend classes 1231, 1232 and 1233 for a more detailed and hands-on look

Trademarks The Microchip name and logo, the Microchip logo, Accuron, dsPIC, KeeLoq, KeeLoq logo, MPLAB, PIC, PICmicro, PICSTART, PRO MATE, rfPIC and SmartShunt are registered trademarks of Microchip Technology Incorporated in the U.S.A. and other countries. FilterLab, Linear Active Thermistor, MXDEV, MXLAB, SEEVAL, SmartSensor and The Embedded Control Solutions Company are registered trademarks of Microchip Technology Incorporated in the U.S.A. Analog-for-the-Digital Age, Application Maestro, CodeGuard, dsPICDEM, dsPICDEM.net, dsPICworks, dsSPEAK, ECAN, ECONOMONITOR, FanSense, In‑Circuit Serial Programming, ICSP, ICEPIC, Mindi, MiWi, MPASM, MPLAB Certified logo, MPLIB, MPLINK, mTouch, PICkit, PICDEM, PICDEM.net, PICtail, PIC32 logo, PowerCal, PowerInfo, PowerMate, PowerTool, REAL ICE, rfLAB, Select Mode, Total Endurance, UNI/O, WiperLock and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and other countries. SQTP is a service mark of Microchip Technology Incorporated in the U.S.A. All other trademarks mentioned herein are property of their respective companies. © 2008, Microchip Technology Incorporated. All Rights Reserved.

1230 Rtf Final

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 1230 Rtf Final (20)

Recently uploaded (20)

1230 Rtf Final