Real Time Operating Systems Johan Dams

Slides:



Advertisements
Similar presentations
Resource management and Synchronization Akos Ledeczi EECE 354, Fall 2010 Vanderbilt University.
Advertisements

Real-Time Library: RTX
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Embedded System Presentation Nguyễn Trần Quang Nguyễn Công Vũ 1µC/OS-II.
Lecture 2. Real-time Systems Concept Prof. Taeweon Suh Computer Science Education Korea University COM609 Topics in Embedded Systems.
HW/SW Interface Operating Systems Design and Implementation.
Introduction to Operating Systems – Windows process and thread management In this lecture we will cover Threads and processes in Windows Thread priority.
Home: Phones OFF Please Unix Kernel Parminder Singh Kang Home:
Real-Time Kernels and Operating Systems. Operating System: Software that coordinates multiple tasks in processor, including peripheral interfacing Types.
MicroC/OS-II Embedded Systems Design and Implementation.
Intro to OS CUCS Mossé Processes and Threads What is a process? What is a thread? What types? A program has one or more locus of execution. Each execution.
Real-Time Operating Systems Suzanne Rivoire November 20, 2002
ΜC/OS-III Tasks Akos Ledeczi EECE 354, Fall 2010 Vanderbilt University.
CE Operating Systems Lecture 5 Processes. Overview of lecture In this lecture we will be looking at What is a process? Structure of a process Process.
SOC Consortium Course Material SoC Design Laboratory Lab 8 Real-time OS - 2 Speaker: Yung-Chih Chen Advisor: Prof. Chun-Yao Wang November 17, 2003 Department.
Real-Time Kernel (Part 1)
Kernel structure & Task management © P.J.Fondse April 2010.
1 Computer System Overview Chapter 1. 2 n An Operating System makes the computing power available to users by controlling the hardware n Let us review.
The  C/OS-II Real-Time Operating System.  C/OS-II Real-time kernel –Portable, scalable, preemptive RTOS –Ported to over 90 processors Pronounced “microC.
Object Oriented Analysis & Design SDL Threads. Contents 2  Processes  Thread Concepts  Creating threads  Critical sections  Synchronizing threads.
Operating Systems Real-Time Operating Systems
S.Ducasse Stéphane Ducasse 1 Processes and Concurrency in VW.
SOC Consortium Course Material Real-time OS Speaker: 沈文中 April. 9, 2003 National Taiwan University Adopted from National Chiao- Tung University SOC Course.
Getting Started with the µC/OS-III Real Time Kernel Akos Ledeczi EECE 6354, Fall 2015 Vanderbilt University.
2-1 The critical section –A piece of code which cannot be interrupted during execution Cases of critical sections –Modifying a block of memory shared by.
Multiprocessor and Real-Time Scheduling Chapter 10.
Chapter 101 Multiprocessor and Real- Time Scheduling Chapter 10.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
CE Operating Systems Lecture 11 Windows – Object manager and process management.
Real Time Operating Systems
Real-time OS Hao-yuan Chin Feb. 18, Institute of Electronics, National Chiao Tung University Real-time OS 1 Outline Introduction to RTOS Introduction.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Real Time Operating Systems Mutual Exclusion, Synchronization & Intertask Communication Course originally developed by Maj Ron Smith.
Overview Task State Diagram Task Priority Idle Hook AND Co-Routines
RTX - 51 Objectives  Resources needed  Architecture  Components of RTX-51 - Task - Memory pools - Mail box - Signals.
ECGR-6185 µC/OS II Nayana Rao University of North Carolina at Charlotte.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
Operating Systems CSE 411 CPU Management Sept Lecture 10 Instructor: Bhuvan Urgaonkar.
MicroC/OS-II S O T R.  MicroC/OS-II (commonly termed as µC/OS- II or uC/OS-II), is the acronym for Micro-Controller Operating Systems Version 2.  It.
1 VxWorks 5.4 Group A3: Wafa’ Jaffal Kathryn Bean.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
Processes. Process Concept Process Scheduling Operations on Processes Interprocess Communication Communication in Client-Server Systems.
6.0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS (RTOS) 6.0 Introduction A more complex software architecture is needed to handle multiple tasks, coordination,
Embedded Computer - Definition When a microcomputer is part of a larger product, it is said to be an embedded computer. The embedded computer retrieves.
Slides created by: Professor Ian G. Harris Operating Systems  Allow the processor to perform several tasks at virtually the same time Ex. Web Controlled.
Copyright © Curt Hill More on Operating Systems Continuation of Introduction.
SOC Consortium Course Material SoC Design Laboratory Lab 8 Real-time OS - 1 Speaker: Yung-Chih Chen Advisor: Prof. Chun-Yao Wang November 17, 2003 Department.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
Chapter 7: Semaphore Management Seulki Lee 1. Semaphore?  A protocol mechanism offered by most multitasking kernels  Control access to a shared resource.
2-1 Chapter 2 Real-Time Systems Concepts. 2-2 Foreground/Background Systems BackgroundForeground ISR Time Code execution application consists of an infinite.
Chapter 13: Porting μC/OS-II 1. Outline Requirements Hardware Software Tasks of Porting µC/OS-II OS_CPU_C.H OS_CPU_C.C OS_CPU_A.ASM Testing a port 2.
Chapter 1: Getting Started with μC/OS-II 1. kernel Introduction 2 LinuxμC/OS-II Task (process) kernel Device driver User mode (0-3G) (Kernel mode) 3G-4G.
Outlines  Introduction  Kernel Structure  Porting.
1 Module 3: Processes Reading: Chapter Next Module: –Inter-process Communication –Process Scheduling –Reading: Chapter 4.5, 6.1 – 6.3.
Real-Time Operating Systems RTOS For Embedded systems.
Chapter 2: Operating System Concepts 1. Objectives To know essential topics on the design of (embedded) operating systems 2 1.Task & resources 2.Kernel.
Chapter 1: Getting Started with μC/OS-II
REAL-TIME OPERATING SYSTEMS
Processes and threads.
Chapter 4: Task Management
EEE Embedded Systems Design Process in Operating Systems 서강대학교 전자공학과
Chapter 2: Operating System Concepts
Topics Covered What is Real Time Operating System (RTOS)
Getting Started with the µC/OS-III Real Time Kernel
Intro to Processes CSSE 332 Operating Systems
Akos Ledeczi EECE 6354, Fall 2017 Vanderbilt University
Akos Ledeczi EECE 6354, Fall 2015 Vanderbilt University
Akos Ledeczi EECE 6354, Fall 2017 Vanderbilt University
Chapter 13: I/O Systems “The two main jobs of a computer are I/O and [CPU] processing. In many cases, the main job is I/O, and the [CPU] processing is.
Presentation transcript:

Real Time Operating Systems Johan Dams

INTRODUCTION RTOS ??? –Real Time Operating System Where used? –Satellite systems –Measuring equipment –GSM (antennas and devices) –Cars (e.g. ABS) –Cameras –Medical instruments –Motor control –Network adapters –Robots –Fax machines, copiers –Printers, terminals, scanners, modems –Switches and routers –Flight systems, weapon systems –Micro-wave systems, dishwashers, thermostats –...

MicroC/OS-II (Jean J Labrosse) Free for educational use Easy as entry level Can handle 64 tasks (-8 for system) 64 priority levels Price: $60 book+disk Implementations exist for: –Win95/98 –68HC11 –80x86 –M16C (!) –…

Foreground/Background systems Foreground –= "Interrupt level" –based on Interrupt Service Routines (ISR) Background –= "Task level" –Most used

Real-Time Systems Concept Definitions "Critical Section of Code": has to be treated uninterrupted Resource (printer, keyboard, …but also variable, structure...) Shared Resource: can be used by more then one task. Mutual Exclusion !!! Multitasking: process in which CPU-time is divided under multiple tasks Task or thread : –Thinks it has got the CPU for itself. –Has a priority Five conditions in which a task can be: –DORMANT exists in memory not yet offered to the multitasking kernel –READY can be executed has lower priority then running tasks –RUNNING if the task has control of the CPU

Definitions –WAITING waits for an event (e.g. I/O) waits for resource to be available wait till certain time elapses –ISR (Interrupt Service Routine) if there is an interrupt Context switch Context ? See fig. Task Control Block gets exchanged by OS with Registers More CPU registers => more overhead

Definitions Kernel –Piece of a multitasking system that controls tasks –Primary task = context switching –Extra ROM and RAM needed -> problem for single-chip processors –RAM gets eaten –Extra CPU-time needed (2 tot 5%) Scheduler (or: dispatcher) –controls which task will run –Mostly priority based –Priority-based kernel = gives highest priority task that is ready to run control of the CPU

Preemptive and non-preemptive kernels non-preemptive kernel –also: "cooperative multitasking" –A task has to give up the CPU itself –releasing the CPU has to be done fast –small interrupt latency –every task can run completely before the CPU is released –less danger for corruption (non-reentrant functions) –bad response on high-priority tasks –crash of a task, or endless loop --> ??

Preemptive and non-preemptive kernels Preemptive kernel –Used when response time important –eg. microC/OS-II –Highest priority task ALWAYS gets control –Highest priority tasks gets immediate control –response time very short –Non-reentrant functions cannot be used! –After execution of task continue with highest priority task (not interrupted task)

Reentrant functions Can be used by multiple tasks at the same time Examples: int Temp; void swap(int *x, int *y) { Temp = *x; *x = *y; *y = Temp; } void strcpy(char *dest, char *src) { while(*dest++ = *src++) { *dest = NULL; }

Round-Robin scheduling When: if 2 or more tasks have the same priority Every task gets fixed amount of time: a quantum = time slicing Alternative: Task priority. Highest priority gets CPU

Static and Dynamic priorities Static: priority does not change Dynamic : priority changes during execution Dynamic is needed to prevent priority inversions

Priority inversions One of the problems when using real time kernels Situation: 3 tasks with different priority (H-M-L) Task 1 (High priority) needs a semaphore (resource), occupied by task 3 problem: task 1 (H) has to wait too long to start running

Priority inversions Solution: give task 3 a very high priority For as long as it occupies the resource Needed: a kernel that can change the priority itself

Assigning priorities to tasks SOFT real-time system: tasks don’t have to be completed within a certain time HARD real-time system: tasks have to be completed correctly within time Method: RMS (Rate Monotonic Scheduling) –Most executed tasks -> highest priority –Demands: tasks occur regularly tasks don’t exchange anything preemptive scheduling needed –real-time deadlines are met when –Ei maximum time needed for task i –Ti time between i and i+1 –n = number of tasks

Assigning task priorities –Conclusion NUMBER OF TASKS –Thus: never use more then 60% to 70% CPU time

Mutual Exclusion Demand: exclusive use of a resource How? –Disable interrupts Used on critical sections of code For very short time only –Test-and-set operations For important sections Needs more time Principle: disable interrupt test test-and-set variable Set test-and-set variable to 1 enable interrupt Access resource disable interrupt Set test-and-set variable to 0 enable interrupt

Mutual Exclusion –Disable scheduling Normal: after interrupt, processing goes to highest priority task Now: after interrupt, processing goes back to interrupted task –Use of semaphores Better method than disabling scheduling Invented mid 1960 Principle –Access control on shared resource –Event gets clearly flagged –Two tasks can synchronise = key you need in order to continue processing If semaphore in use, keep WAITING until it gets available ”Give me the key. If it is in use, I’ll keep waiting."

Mutual Exclusion Binary semaphore: two conditions, used or not Counting semaphore:from 0 tot 2^8, 2^16 of 2^32 –=> semaphore counts downwards (!)

Three semaphore operations INITIALIZE (or CREATE) –initial waiting list is empty WAIT (or PEND) –a task requests a resource –If semaphore = 0, next task goes in WAIT next task is put on waitinglist –If semaphore > 0, tasks begins execution semaphore gets decremented SIGNAL (or POST) –a task releases the semaphore –no task waiting: semaphore incremented –task waiting: key is given to new task –new task is first task that asked for semaphore (FIFO) highest priority task

Three semaphore operations Example

Encapsulated semaphores Principle: –task does not have to control semaphore –Resource controls the semaphore Typical: driver of the resource solves semaphores Release of a semaphore is done through a timeout eg. Network card, serial port,... Advantages: –tasks just use the driver –programmer does not have to deal with the semaphores

Deadlocks (Deadly embrace) What ? –Two tasks waiting for each others semaphore Solutions –acquire all resources before proceeding –always acquire resources in the same order and –always release in reverse order –use of time-outs on semaphores

Synchronisation What ? –Synchronisation between tasks –Synchronisation between tasks and ISR How ? – Use of semaphores –"unilateral rendezvous" –semaphore signals an event (flag, NOT a key)

Synchronisation –counting semaphores for accumulation of events not processed yet –More than one task can be waiting for event: highest task first first task first (FIFO) –"bilateral rendezvous" synchronising two tasks (not task + ISR) with two semaphores

Event Flags When ? –A task has to synchronise with multiple events Disjunctive synchronisation –logical OR –synchronisation if one of the events occurred Conjunctive synchronisation –logical AND –synchronisation if all events occurred

Inter task communication What ? –ISR or task sends information to other task How ? –Global variables –sending messages Global variables –Make sure you have exclusive access by disabling and enabling interrupts by use of semaphores –Alterations are passed on by use of semaphores polling of the results –Better methods: "message mailbox" and "message queues"

Message mailboxes Principle: –interchanging messages through the kernel –typical pointer size variable –Kernel provides a mailbox service –Task or ISR drops a message (pointer) in the mailbox –pointer can point to any data –transmitter and receiver know what data the pointer holds Waiting list –every mailbox can have a waiting list –used if more tasks are waiting the arrival of a message in one mailbox Task asking message from empty mailbox –goes in SUSPEND (WAIT) –goes active as soon a message is present highest priority first first task first serve (FIFO) –in general: timeout is specified –after timeout: error code

Message mailboxes –I-beam = message box –hourglass "10" = number of clock ticks before time-out Typical operations on a mailbox –init of mailbox, can have a message initially –deposit message in mailbox (POST) –get message from mailbox, wait if no available (PEND) –get message from mailbox, don't wait if no available (ACCEPT)

Message Queues Principle –used to send one or more messages to a task –typical an array of mailboxes –a task or ISR can deliver a message (pointer) in hte message queue –one or more tasks can receive messages from the queue through the kernel –sender and receiver know what kind of data is behind the pointer typical FIFO, also LIFO and highest priority possible Also here: –task can go in WAIT if queue is empty –task can specify time out –square = queue - "10" = max number of messages in queue - "0" = time-out

Interrupts What? –hardware mechanism for asynchronous event If interrupt is recognised –CPU saves (part of) local variables (CPU-Registers) –CPU jumps to special part of memory (ISR) At the end of the interrupt, the program continues with: –the background (foreground/background system) –the interrupted task (non-preemptive kernel) –the highest priority task ready to run (preemptive kernel) Allow to run process events when they happen no POLLING needed Disabling interrupts –possible, but highly not recommended –in real-time systems, as short as possible –interrupts are NOT Queued interrupts can be missed

Interrupt Latency Important RTOS specification: –Amount of time interrupts are disabled –Disabling is needed for critical sections –During disabling: interrupt latency Interrupt latency? –Interrupt latency = maximum amount of time interrupts are disabled + Time to start executing the first instruction of the ISR Interrupt response time –= time between the reception of an interrupt and the start of user code that handles the interrupt. –For foreground/background systems AND non-preemptive kernels = interrupt latency + time needed to save CPU context –For preemptive kernels = interrupt latency + time needed to save CPU context + execution time of the kernel ISR entry function

Interrupt Latency Interrupt Recovery –For foreground/background systems AND non-preemptive kernels = time to put CPU context back + time for RTI instruction –For preemptive kernels = Time to determine if a higher priority task is ready + time to put CPU context back + time for RTI instruction Non-maskable interrupts –Cannot be disabled –Mostly in hardware –Only for important tasks –Eg. To save data during power-down.

Clock tick = special interrupt –Periodical = RTOS heartbeat Typical 1 tot 200 ms Higher clock tick leads to more overhead Delaying a task: “n” clock ticks

Memory usage of a RTOS Foreground-background systems –Only dependant on application size RTOS –Extra room needed for kernel –for  Controllers: 1 tot 100 KBytes for the RTOS –MicroC-OS/II : 3KB –Extra RAM needed for ISR and context switching of tasks

ad- and disadvantages of RTOS Advantages: –Real time applicaties are easier to expand –Timecritical applications are dealt with more efficiently –Important services semaforen mailboxes queues fixed time delays time-out handling Disadvantages: –More CPU-time (2 to 5%), RAM and ROM needed –Extra cost for the RTOS

MicroC/OS II

Kernel structure: critical sections Critical sections –During critical moments : disable interrupts –Usercode can also indicate critical sections OS_ENTER_CRITICAL() OS_EXIT_CRITICAL() –These macros are in OS_CPU.H Tasks –Result = void –Structure void JustAnotherTask(void *pdata) { User Code; System Call; User Code; } Kernel structuur: Tasks

Kernel structure: Tasks Example of an infinite task void JustAnotherTask(void *pdata) { for (;;) { User Code; OSMboxPend(); of OSQPend(); of OSSemPend(); of OSTaskDel(OS_PRIO_SELF); of OSTaskSuspend(OS_PRIO_SELF); of OSTimeDly(); of OSTimeDlyHMSM(); User Code; }

Kernel structure: Tasks Example of a temporary task void MyTask(void *pdata) { User Code; OsTaskDel(OS_PRIO_SELF); } Function of void *pdata –“void” can be any kind of data –pdata is given to the task during startup –eg. Number of a serial port  1 task can handle all serial ports

Kernel structure: priorities Priorities –Max 64 priority levels –8 levels reserved for OS –56 for user from 0 tot OS_LOWEST_PRIO-2 –Low number = high priority –Highest priority is dealt with first Creation of tasks –Task must be offered to Kernel Memory address and parameters are given OSTaskCreate() or OSTaskCreateExt()

Kernel structure: states of a task States of a task –DORMANT Not yet offered to kernel –READY Task offered with OSTaskCreate() or OSTaskCreateExt() Back to dormant by OSTaskDel() –RUNNING After multitasking has been started (see also further) Highest priority first –WAITING A task can delay itself with OSTimeDly() or OSTimeDlyHMSM() A task can also be waiting for an event, like –OSSemPend(); OSMboxPend(), OSQPend() –ISR state When interrupt has occurred

Kernel structure: states of the kernel States of the kernel –Multitasking is started with OSStart() –A WAITING task gets back activated with OSTimeTick() –If all tasks are waiting for an event: idle task OSTaskIdle()

Kernel structure: Task Control Blocks Task Control Blocks (OS_TCBs) –A task that has been created, gets an OS_TCB typedef struct os_tcb { OS_STK*OSTCBStkPtr; void *OSTCBExtPtr; OS_STK*osTCBStkBottom; INT32UOSTCBStkSize; INT16UOSTCBOpt; INT16UOSTCBId; struct os_tcb*OSTCBNext; struct os_tcb*OSTCBPrev; OS_EVENT*oSTCBEventPtr; void*OSTCBMsg; INT16UOSTCBDly; INT8UOSTCBStat; INT8UOSTCBPrio; INT8UOSTCBX; INT8UOSTCBY; INT8UOSTCBBitX; INT8UOSTCBBitY; BOOLEANOSTCBDelReq; } OS_TCB;

Kernel structure: Task Control Blocks Explanations –OSTCBStkPtr Every task has its own stack –OSTCBExtPtr Pointer to own part of TCB –OSTCBStkBottom Points to the end of the TCB –OSTCBDly Number of clock ticks the task needs to be delayed –OSTCBStat Contains current task status 0 = READY, see uCOS_II.H file –OSTCBPrio Contains task priority, low number = high priority –OSTCBDelReq Request to be deleted

Kernel structure: Task Control Blocks Some constants –OS_MAX_TASKS Max number of tasks available Can be reduced  less memory needed Reduce to the actual number used –List of OS_TCBs is made in advance Notice list structure –OS_LOWEST_PRIO Lowest applicable priority Note! Number of priorities can be higher than number of tasks

Kernel structure: Locking Scheduler –Will let highest priority task run –Lower priority task gets interrupted Locking the scheduler –Using OSSchedLock() allows scheduler to be stopped –Low priority tasks keeps in control –Stays like that until OSSchedUnlock() gets called When? –Normally: never –Exceptions, eg. If a task has to post a lot of messages multiple mailboxes, queues, semaphores messages have to be dealt with simultaneous  synchronisation

Kernel structure: Statistics What? –Keeps the amount (% ) of CPU in use –Resolution = 1% How? –Call in the beginning OSStatInit() Set a variablein configuration file: OS_TASK_STAT_EN –Every second, the task OSTaskStat() will be started. Result is kept in variable OSCPUUsage –with:OSIdleCtr : gets +1 if OSTaskIdle() gets called OSIdleCtrMax : calculated once during Init

Kernel structure: starting program How? –A program in C starts with void main(void) { /* own code */ } –In this routine the following has to happen: Initialisation of the RTOS : OSInit() Creation of a task by OSTaskCreate() or OSTaskCreateExt() Starting of the RTOS : OSStart() –Example: void main(void) { OSInit() OSTaskCreate(TaskStart,(void *) 0,(void *) &TaskStartStk[TASK_STK_SIZE-1],0); OSStart(); }

Kernel structure: starting program Structure of TaskStart() –Is the actual program –General structure: void TaskStart(void *pdata) {  Install and Init OS Ticker OSStatInit(); // initialises statistics Task  Install tasks that comprise your program for (;;) { your own code OSTimeDlyHMSM(0,0,1,0); }

Kernel structure: OS Ticker Remember –OS Ticker is the ms heartbeat BAD way of starting void main (void) { OSInit() InitTick(); OSStart() } Reason: –Tick interrupt can start before your first task Enabling of TICKER is done before OSStart() –Program can crash

Kernel structure: OS Ticker GOOD way of starting void TaskStart (void *pdata) { OS_ENTER_CRITICAL() InitTick(); OS_EXIT_CRITICAL() Start other tasks FOR (;;) { other stuff }

Task Management General form of your program –TASK = 1) Infinite loop, or 2) Task that deletes itself –C program –Return value = void void My_Task(void *pdata)void My_Task(void *pdata) { for (;;) { /* own code here */ /* own code here */ OSTaskDel(OS_PRIO_SELF); one of following calls: } OSMBoxPend(); OSQPend(); OSSemPend(); OSTaskDel(OS_PRIO_SELF); OSTaskSuspend(OS_PRIO_SELF); OSTimeDly(); OSTimDlyHMSM(); }

Creation of a Task Task is offeres to the kernel –OSTaskCreate() –OSTaskCreateExt() : has extra options Stack checking: if stack should get too big User-defined data area User-defined checks on data At least one task needed before OSStart() can run Every task has its own STACK space –Can be expanded dynamically with malloc() /* other code */ pstk = (OS_STK *) malloc(stack_size); if (pstk != (OS_STK *)0) ; see if enough memory { /* create task */ } /* Other code */ –Problem: fragmentation of memory

Deleting a Task Done by OSTaskDel() –Code still exists –Goes back to DORMANT state –= “hard” delete Request to delete: OSTaskDelReq() –= “soft” delete –Task gets chance to clear semaphores and memory –Task has to check for OSTaskDelReq ! /* other code */ if (OSTaskDelReq(OS_PRIO_SELF) == OS_TASK_DEL_REQ) } /* Release all resources */ /* De-allocate memory */ OSTaskDel(OS_PRIO_SELF); } else { /* Other code */ }

Other operations on tasks Changing the priority –OSTaskChangePrio() Suspend –Starts after OSTaskSuspend() –Can only be undone by OSTaskResume()

Time Management Delaying a task using OSTimeDly() –OSTimeDly(ticks) –creates context switch –Delay of 1 to system Ticks Delaying a task using OSTimeDlyHMSM() –OSTimeDlyHMSM(hours,minutes,seconds,milli) –HMSM = Hours – Minutes – Seconds – Milliseconds –Can go till 256 hours (around 11 days) Resuming a delayed task with OSTimeDlyResume() Requesting time with OSTimeGet() –Result in Ticks –Size = INT32U

Communication and synchronisation Use of ECB’s (Event Control Blocks) 2 forms of communication –a) Task or ISR gives flag to a Task –b) A Task Waits for an event only Tasks can wait !! An ISR cannot wait Time-out possible A ECB can be –a semaphore Task keeps wachten, or Task can be flagged –a message mailbox –a message queue

Use of semaphores Link between a Task, ISR en semaphore: –Creation of the semaphore with OSSemCreate() –A flag passed to a semaphore: OSSemPost() –Waiting for a semaphore: OSSemPend() –Accepting a semaphore without waiting: OSSemAccept() –Requesting status of a semaphore: OSSemQuery()

Use of Message Mailboxes Link between een Task, ISR en Message Mailbox: –Creation of a mailbox with OSMboxCreate() –Posting a message in a mailbox: OSMboxPost() –Waiting for a message in a mailbox: OSMboxPend() –Getting a mailbox without waiting: OSMboxAccept() –Request status of a mailbox: OSMboxQuery()

Use of Message Queues Queue is comprised of Queue Control Blocks

Use of Message Queues A Message Queue is a circular buffer

Use of Message Queues Link between Task, ISR en Message Queue: –Creation of the Message Queue using OSQCreate() –Posting a message in the queue (FIFO): OSQPost() –Posting a message in the queue (LIFO): OSQPostFront() –Waiting for a message in the queue: OSQPend() –Requesting a queue without waiting: OSQAccept() –Requesting status of a queue: OSQQuery()

Memory Management How does C work ? –malloc() Function for requesting memory –free() Function for releasing memory Problems –In RTOS danger for fragmentation –Quick shortage of continues memory blocks RTOS solution –Use of memory blocks with fixed size –All blocks same size –Size of blocks is configurable

Memory Management Creation of memorypartition by use of OSMemCreate() –Has to be done in advance –eg. creation of 100 blocks of 32 bytes each OS_MEM *CommTxBuf; // create pointer to buffer INT8UCommTxPart[100][32]; // allocate memory void main(void) { /* Other code */ CommTxBuf = OSMemCreate(CommTxPart,100,32,&err); /* Check for errors using err */ /* Other code */ OSStart(); }

Memory Management Requesting a memory block OSMemGet() releasing a memory block OSMemPut() Bigger blocks get linked