Rtos Ppts

μC/OS-II Features  Portable : portable ANSI C, minimum micro processor specific assembler code  ROMable  Scalable  Preemptive : μC/OS-II is a fully preemptive real-time kernel  Multitasking : μC/OS-II can manage up to 64 tasks  Deterministic : Execution time of all μC/OS-II functions and service are deterministic  Deterministic : Each task requires its own different stack size

1

μC/OS-II Features  Services : Mailboxes, Queues, Semaphores, fixed-sized memory partitions, time-related functions  Interrupt Management: Interrupt can be nested up to 255 levels deep  Robust and Reliable  Shortcomings:  μC/OS-II does not support priority inheritance.  With μC/OS-II, all tasks must have a unique priority.  A task, also called a thread, is a simple program that thinks it has the CPU all to itself.

2

Tasks  μC/OS-II can manage up to 64 tasks  Two task are used for system use.  The four highest priority tasks and the four lowest priority tasks are reserved for its own use (0, 1, 2, 3, OS_LOWEST_PRIO-3, 2, 1, 0)  56 application tasks  The lower the value of the priority, the higher the priority of the task.

3

Task Control Blocks (OS_TCB)  When a task is created, it is assigned a  Task Control Block, OS_TCB  OS_TCB is a data structure that is used by  μC/OS-II to maintain the state of a task when it is preempted  All OS_TCB reside in RAM  An OS_TCB is initialized when a task is created.

4

Task States  Task (Thread) States DORMANT  READY  RUNNING  DELAYED  PENDING  INTERRUPTED 

5

Task Context Switch

6

Functions

UCOS2.LIB

void OSInit(void); Description Initializes µC/OS-II data; must be called before any other µC/OS-II functions are called. void OSStart(void) Description Starts the multitasking process INT8U OSTaskCreate(void (*task)(), void *pdata, INT16U stk_size, INT8U prio); Description Creates a task to be managed by µC/OS-II.

7

OS Init exit functions

UCOS2.LIB

INT8U OSTaskCreateExt (void (*task)(), void *pdata, INT8U prio, INT16U id, INT16U stk_size, void *pext, INT16U opt); Description This function is similar to OSTaskCreate() except that it allows additional information about a task to be specified. Tasks can either be created prior to the start of multitasking or by a running task. A task cannot be created by an ISR. void OS_ENTER_CRITICAL(); void OS_EXIT_CRITICAL(); Description Enter and Exit a critical section.

8

OSSched functions

UCOS2.LIB

void OSSchedLock(void); Description Prevents task rescheduling. void OSSchedUnlock(void); Description Allow task rescheduling

9

OSSem functions

UCOS2.LIB

INT16U OSSemAccept (OS_EVENT *pevent); Description This function checks the semaphore to see if a resource is available or if an event occurred. OS_EVENT *OSSemCreate (INT16U cnt); Description Creates a semaphore. void OSSemPend (OS_EVENT *pevent, INT16U timeout, INT8U *err); Description Waits on a semaphore

10

OSSem functions

UCOS2.LIB

INT8U OSSemPost (OS_EVENT *pevent); Description This function signals a semaphore. INT8U OSSemQuery (OS_EVENT *pevent, OS_SEM_DATA *pdata); Description Obtains information about a semaphore.

11

OSFlag functions

(OS_FLAG.C)

OS_FLAGS OSFlagAccept (OS_FLAG_GRP *pgrp, OS_FLAGS flags, INT8U wait_type, INT8U *err); Description This function is called to check the status of a combination of bits to be set or cleared in an event flag group

OS_FLAG_GRP *OSFlagCreate (OS_FLAGS flags, INT8U *err); Description This function is called to create an event flag group.

12

OSFlag functions

(OS_FLAG.C)

OS_FLAG_GRP *OSFlagDel (OS_FLAG_GRP *pgrp, INT8U opt, INT8U *err); Description This function deletes an event flag group and readies all tasks pending on the event flag group. OS_FLAGS OSFlagPend (OS_FLAG_GRP *pgrp, OS_FLAGS flags, INT8U wait_type,INT16Utimeout,INT8U *err); Description This function is called to wait for a combination of bits to be set in an event flag group.

13

OSFlag functions

(OS_FLAG.C)

OS_FLAGS OSFlagPost (OS_FLAG_GRP *pgrp, OS_FLAGS flags, INT8U opt, INT8U *err); Description This function is called to set or clear some bits in an event flag group. OS_FLAGS OSFlagQuery (OS_FLAG_GRP *pgrp, INT8U *err); Description This function is used to check the value of the event flag group.

14

OSMbox functions

OS_MBOX.C

void *OSMboxAccept (OS_EVENT *pevent); Description OSMboxAccept() does not suspend the calling task if a message is not available OS_EVENT *OSMboxCreate (void *msg); Description Creates a message mailbox if event control blocks are available

15

OSMbox functions

OS_MBOX.C

OS_EVENT *OSMboxDel (OS_EVENT *pevent, INT8U opt, INT8U *err); Description This function deletes a mailbox and readies all tasks pending on the mailbox. void *OSMboxPend(OS_EVENT *pevent, INT16U timeout, INT8U *err); Description Waits for a message to be sent to a mailbox.

16

OSMbox functions

OS_MBOX.C

INT8U OSMboxPost (OS_EVENT *pevent, void *msg); Description Sends a message to the specified mailbox INT8U OSMboxPostOpt (OS_EVENT *pevent, void *msg, INT8U opt); Description This function sends a message to a mailbox. INT8U OSMboxQuery (OS_EVENT *pevent, OS_MBOX_DATA *pdata); Description Obtains information about a message mailbox.

17

OSMem Functions

UCOS2.LIB

OS_MEM *OSMemCreate (void *addr, INT32U nblks, INT32U blksize, INT8U *err); Description Creates a fixed-sized memory partition that will be managed by µC/OS-II. void *OSMemGet (OS_MEM *pmem, INT8U *err); Description Gets a memory block from the specified partition.

18

OSMem Functions

UCOS2.LIB

INT8U OSMemPut(OS_MEM *pmem, void *pblk); Description Returns a memory block to a partition. INT8U OSMemQuery (OS_MEM *pmem, OS_MEM_DATA *pdata); Description Determines the number of both free and used memory blocks in a memory partition.

19

OSMutex functions

OS_MUTEX.C

INT8U OSMutexAccept (OS_EVENT *pevent, INT8U *err); Description This function checks the mutual exclusion semaphore to see if a resource is available. OS_EVENT *OSMutexCreate (INT8U prio, INT8U *err); Description This function creates a mutual exclusion semaphore

20

OSMutex functions

OS_MUTEX.C

OS_EVENT *OSMutexCreate (INT8U prio, INT8U *err); Description This function creates a mutual exclusion semaphore. OS_EVENT *OSMutexDel (OS_EVENT *pevent, INT8U opt, INT8U *err); Description This function deletes a mutual exclusion semaphore and readies all tasks pending on it.

21

OSMutex functions

OS_MUTEX.C

void OSMutexPend (OS_EVENT *pevent, INT16U timeout, INT8U *err); Description This function waits for a mutual exclusion semaphore. INT8U OSMutexPost (OS_EVENT *pevent); Description This function signals a mutual exclusion semaphore. INT8U OSMutexQuery (OS_EVENT *pevent, OS_MUTEX_DATA *pdata); Description This function obtains information about a mutex.

22

OSQ functions

OS_Q.C

void *OSQAccept (OS_EVENT *pevent); Description Checks the queue to see if a message is available OS_EVENT *OSQCreate (void **start, INT16U qsize); Description Creates a message queue if event control blocks are available INT8U OSQQuery (OS_EVENT *pevent, OS_Q_DATA *pdata); Description Obtains information about a message queue

23

OSQ functions

OS_Q.C

OS_EVENT *OSQDel (OS_EVENT *pevent, INT8U opt, INT8U *err); Description Deletes a message queue and readies all tasks pending on the queue. INT8U OSQFlush (OS_EVENT *pevent); Description Flushes the contents of the message queue. INT8U OSQPostOpt (OS_EVENT *pevent, void *msg, INT8U opt); Description This function sends a message to a queue.

24

OSQ functions

OS_Q.C

void *OSQPend (OS_EVENT *pevent, INT16U timeout, INT8U *err); Description Waits for a message to be sent to a queue. INT8U OSQPost (OS_EVENT *pevent, void *msg); Description Sends a message to the specified queue. INT8U OSQPostFront (OS_EVENT *pevent, void *msg); Description Sends a message to the specified queue

25

Functions INT8U OSTaskChangePrio(INT8U oldprio, INT8U newprio); Description Allows a task's priority to be changed dynamically. Note that the new priority MUST be available. INT16U OSSetTickPerSec(INT16U TicksPerSec); Description Sets the amount of ticks per second void OSStatInit(void); Description Determines CPU usage.

26

EXAMPLE 1 #include <dos.h> #include "libepc.h" #include "os_cpu.h" #include "os_cfg.h" #include "ucos_ii.h" #define STK_SIZE 1024 int x=0,y=0; void task1() { while(1) { if(x==24) x=0; if(y==79) y=0; PutCharAt('B',++x,y++); OSTimeDly(100); PutCharAt('L',x,y++); OSTimeDly(100); } }

void task2() { while(1) { PutCharAt('A',x,y++); OSTimeDly(100); PutCharAt('U',x,y++); OSTimeDly(100); } }

27

EXAMPLE 1 int main() { static OS_STK T1_STK[STK_SIZE]; static OS_STK T2_STK[STK_SIZE]; ClearScreen(0x07); OSInit(); OSTaskCreate(task1,NULL,T1_S TK,11); OSTaskCreate(task2,NULL,T2_S TK,12); OSStart(); }

28

Example 2 #include <dos.h> #include "libepc.h" #include "os_cpu.h" #include "os_cfg.h" #include "ucos_ii.h" #define os_stk 1024 int x=0,y=0,z=0; char *err; OS_EVENT *p; void task1() { while(1) { OSTimeDly(100); OSSemPend(p,0,err); PutCharAt('G',x,y++); OSSemPost(p); OSTimeDly(100); } }

void task2() { while(1) { OSTimeDly(100); PutCharAt('S',++x,y++); OSSemPend(p,0,err); PutCharAt('M',x,y++); OSSemPost(p); OSTimeDly(100); } }

29

Example 2 void task3() { while(1) { OSSemPend(p,0,err); OSTimeDly(100); PutCharAt('I',x,y++); OSSemPost(p); PutCharAt('A',x,y++); OSTimeDly(100); } }

int main() { static OS_STK t1_stk[os_stk]; static OS_STK t2_stk[os_stk]; static OS_STK t3_stk[os_stk]; ClearScreen(0x07); OSInit(); OSTaskCreate(task1,NULL,t1_stk,11); OSTaskCreate(task2,NULL,t2_stk,12); OSTaskCreate(task3,NULL,t3_stk,13); p=OSSemCreate(1); OSStart(); }

30

1.Real-Time Systems •Real-time systems process events. •Events occurring on external inputs cause other events to occur as outputs. •Minimizing response time is usually a primary objective, or otherwise the entire system may fail to operate properly. Soft Real-Time System Compute output response as fast as possible, but no specific deadlines that must be met. Hard Real-Time System Output response must be computed by specified deadline or system fails.

31

1.Real-Time Systems • Soft Real-Time System •

Compute output response as fast as possible, but no specific deadlines that must be met.

• Hard Real-Time System •

Output response must be computed by specified deadline or system fails.

32

2. Multi-Tasking and Concurrency • Most real-time systems are also embedded systems w/several inputs and outputs and multiple events occurring independently. • Separating tasks simplifies programming, but requires somehow switching back and forth among the three task (multi-tasking). • Concurrency is the appearance of simultaneous execution of multiple tasks.

33

2. The build and load process for desktop application programs. Object Files Compiler

Loader

Linker

Assembler

Executabl e Image File

ReadWrite Memory (RAM)

Run-Time Library:

Operating System Image:

Boot Process

34

2. The build and load process for embedded application programs Object Files

Real-Time Kernel:

ROM Image File Locator

Re-Entrant Library:

Linker

Assemble r

Executabl e Image File

ROM "Burner"

ReadWrite Memory (RAM) Program Initialization ReadOnly Memory (ROM)

35

3.INTERRUPTS • Interrupts are signals to processor from hardware. • The interrupt comes generally in form of signal to special pin for interrupt. • Processor responds by stopping the current execution and starts to execute the ISR. • Sometimes same interrupt is shared between two or more devices. • Non Maskable Interrupt cannot be disabled, generally used in critical situations. • Priorities can be assigned to the interrupts to resolve confilcts. • The processor jumps to a particular address in response to an interrupt. • Processor does not stop in between an instruction in response to an interrupt. Nesting of interrupts is allowed. • Interrupts are disabled at start up.

36

3.INTERRUPTS Static int temp[2]; Void interrupt readtemp( void ){ temp[0]=read val; temp[1]=read val; } void main( void ){ int tem0,tem1; while(TRUE) { tem0=temp[0]; tem1=temp[1]; if(tem0!=tem1) { activate alarm } } }

SHARED DATA BUG

37

3.INTERRUPTS SOLUTION TO SHARED DATA BUG • Make “Critical Section” “Atomic” • The part of code, which cannot be interrupted, is called “Atomic”. • The set of instructions that must be atomic for the system to work properly is called “Critical Section”.

38

3.INTERRUPTS Static int temp[2]; Void interrupt readtemp( void ){ temp[0]=read val; temp[1]=read val; } void main( void ){ int tem0,tem1; while(TRUE) { disable(); tem0=temp[0]; tem1=temp[1]; enable(); if(tem0!=tem1) { activate alarm } } }

39

3.INTERRUPTS • Other solutions without disabling interrupts are like relying upon compiler to convert code to a single instruction but is not reliable. • Re-reading of values is another method. If both times value is same then it may be interpreted as nonoccurrence of shared data bug. • This method can be out done by compiler optimizations, which reuse the pre-read value, defeating the design. • This can be countered by using “Volatile” keyword.

40

3.INTERRUPTS INTERRUPT LATENCY • Defined as response time to an interrupt. • Depends on: • Duration for which interrupt is disabled. • Duration of higher priority interrupts • Time for bookkeeping. • Time to save the context. • Writing short and efficient code for ISR can reduce latency. • Make sure interrupts are not disabled for long durations.

41

3.INTERRUPTS Static int tempa[2]; Static int tempv[2]; Static BOOL usingb=FALSE; Void interrupt readtemp( void ) { if(usingb) { tempa[0]=read val; tempa[1]=read val; } else { tempb[0]=read val; tempb[1]=read val; } }

void main( void ) { int tem0,tem1; while(TRUE) { if(usingb) if(tempb[0]!=tempb[1]) alarm else if(tempa[0]!=tempa[1])alarm; } usingb=!usingb; }

42

4.SOFTWARE ARCHITECTURES ROUND-ROBIN ARCHITECTURE Features: • No interrupts • Simple. • Devices are polled and served turn by turn. • Can be used for applications like multimeter, with absolutely no time constraints

Void main( void) { while( TRUE) { if( Device A) serve A; if( Device B) serve B; if( Device C) serve C; ……. ……. if( Device Z) serve Z; } }

43

4.SOFTWARE ARCHITECTURES Disadvantages: • Worst case response is total of execution times of all routines. • Improvement is possible by polling faster device more often but still very slow. • System is fragile-add one more device and response times change drastically. • Absolutely no priorities.

44

4.SOFTWARE ARCHITECTURES ROUND-ROBIN WITH INTERRUPTS Features: • ISRs deal with very urgent needs of hardware. • Main routine may do the follow up. • More control over priority. • Shared data bug has to be taken care of.

45

4.SOFTWARE ARCHITECTURES BOOL devicea=false; BOOL deviceb=false; … … BOOL devicez=false; Void interrupt deviceA( void) { take care of A devicea=true; }

Void interrupt deviceB( void) { take care of B deviceb=true; } … … … Void interrupt deviceZ( void) { take care of Z devicez=true; }

46

4.SOFTWARE ARCHITECTURES void main( void) { while( true) { if(devicea) { devicea=false; handle data of device A } if(deviceb) { deviceb=false; handle data of device B }

… … … if(devicez) { devicez=false; handle data of device Z } } }

47

4.SOFTWARE ARCHITECTURES • • • • •

Not simple All task code has same priority. Putting code in ISR makes device get higher priority. But this makes other responses slow. Polling of higher priority device more is possible like basic round robin architecture. • This technique is very fragile. • Worst response is when interrupt happens just when round robin passed by.

48

4.SOFTWARE ARCHITECTURES FUNCTION QUEUE SCHEDULING • Queue of function pointers is maintained. • Whenever an interrupt occurs the ISR puts the pointer pertaining to that function on queue. • This function takes necessary action for that device. • Main calls these pointers from queue. • Pointers can be called in any order, so we can have complete control over priorities. • Worst wait for high priority function is the duration of longest other function. • This method may not be good enough for low priority interrupts.

49

4.SOFTWARE ARCHITECTURES Void interrupt deviceA( void) { take care of I/O A put function A pointer in queue } Void interrupt deviceB( void) { take care of I/O B put function B pointer in queue }

void main( void) { while( true) { while(queue is empty); call functions in order required } } void function A(void) { take care of A } void function B(void) { take care of B }

50

4.SOFTWARE ARCHITECTURES REAL TIME OPERATING SYSTEM • No shared data bug • Signaling among tasks happen through RTOS. • RTOS assigns priorities to even task code not only interrupts. • Any task can be suspended for higher priority one. • Response is stable. • Worst wait for high priority task is almost zero. • Throughput affected and slightly more memory consumed.

51

4.SOFTWARE ARCHITECTURES Void interrupt deviceA( void) { take care of I/O A set signal X } Void interrupt deviceB( void) { take care of I/O B set signal Y }

void task1( void) { while( true) { wait for X handle I/O for A } } void task2( void) { while( true) { wait for Y handle I/O for B } }

52

4.1 COMPARATIVE TABLE Architecture

Priorities

Worst response for task code

Stability of response on code change

Simplicity

Round-robin

None

Sum of all task code

Poor

very simple

Round-robin with interrupts

Interrupts in priority and all task code at same priority

Total time for all task code

Good for ISR poor for task code

Shared data problem to be tackled

Function queue scheduling

Interrupts in priority then tasks in priority

Time for longest function

Relatively good

Shared data problem and function queue code

RTOS

Interrupts in priority then tasks in priority

Zero

Very good

Most complex

53

4.2 SELECTING ARCHITECTURE • Select simplest system if it suits your requirements. • If response requirements are there go for RTOS • Combination of architectures is also possible.

54

5.RTOS BASICS FEATURES • Term “Real Time Operating System” and “Real Time Kernel” are used interchangingly. • Normal OS takes control of system as soon as it is turned on. • Application usually gets control of the system the RTOS gets control. • RTOS does not protect itself from the applications, generally if the application passes a wrong pointer to the RTOS, whole system crashes along with RTOS. • Only services needed for that particular system are included, no extra services present.

55

5.RTOS BASICS TASKS AND TASK STATES • Tasks are basic building blocks of a RTOS based software. • A task is a subroutine. • A task can be in three states: • Running: Presently executing. • Ready: Waiting to run if processor is available. • Blocked: Has nothing to generally unless some external event triggers it. • Other states like suspend, pending, waiting, dormant etc. are forms of either of above states.

56

5.RTOS BASICS SCHEDULER • Scheduler decides which task should run. • Decision is based on priorities among unblocked tasks. • Scheduler does not fiddle with priorities. • A task will decide for itself that it has to enter blocked state that means it has to run before moving to blocked state. • An interrupt or some other task has to pull out a task out of blocked state. • Scheduler takes care of shuffling between running and blocked states. • If all tasks are blocked system will hang.

57

5.RTOS BASICS PREEMPTIVE AND NON-PREEMPTIVE RTOS • Preemptive RTOS stops a low priority task immediately for a high priority task. • A non-preemptive RTOS stops a task after it enters blocked state.

58

5.RTOS BASICS Void Buttontask( void) /*higher priority*/ { while(true) { unblock on button push and respond } } void levels task( void) /* low priority*/ { while(true) { read levels and calculate } }

void main( void ) { initrtos(): starttask(buttontask, high); starttask(levelstask, low); startrtos(); }

59

5.RTOS BASICS • Each task will have its own context viz. stack, register values, PC, etc. • All other data is shared. • Tasks are more like threads-common data area than like processes-separate data area.

60

5.RTOS BASICS SHARED DATA BUG REVISITIED AGAIN Void task1( void ) { … … counterrors(9); … … } Void task2( void ) { … … counterrors(11);

61

5.RTOS BASICS … … } static int errors; void counterrors(int newerrors) { errors+=newerrors; }

Mov r1,(errors) Add r1,(newerrors) Mov (cerrors),r1 return

62

6.REENTERNCY • A function, which will work correctly even when called by, more than one task is, called reentrant function. • A function is reentrant if: •

• •

It should not use non-atomic variables unless they are stored in stack of calling task or are private variables of that task Should not call anther non-reentrant function. Should not use hardware in non-atomic way.

63

7.SEMAPHORES • A semaphore is akin to disabled interrupt for an ISR. • A semaphore is taken and released. • As long as a semaphore is taken by a task it won’t be interrupted. • Terms like get & give, take & release, pend & post, wait & signal etc. are used. • If a task calls take semaphore and does not call release semaphore then any other task calling take semaphore will be blocked.

64

7.SEMAPHORES Struct { long tanklevel; long timeupdated; }tankdata[max_tanks]; Void Buttontask( void) /*higher priority*/ { while(true) { unblock on button push and respond I=get id of tank where button pushed takesemaphore(); printf(“ time=%ld and level=%ld”, tankdata[I].timeupdatetankdata[I]. tanklevel); releasesemaphore(); } }

void levels task( void) /* low priority*/ { while(true) { takesemaphore(); set tankdata[I].timeupdate set tankdata[I].tanklevel releasesemaphore(); } }

void main( void ) { initrtos(): starttask(buttontask, high); starttask(levelstask, low); startrtos(); }

65

7.SEMAPHORES • Assume levels task took semaphore. • If button is pushed, because of lower priority levels task moves to ready state. • Button task tries to take a semaphore and since it is not released yet levels task is pushed into blocked state. • RTOS looks for ready tasks and since levels is ready it is run until it releases semaphore. • Semaphores make functions reentrant.

66

7.1 MULTIPLE SEMAPHORES • Many RTOSs support multiple semaphores. • Some data can be protected using semaphorea, some by semaphoreb etc. • The system response improves by this method • RTOS does not know which semaphore protects which data, its designer’s responsibility. • Semaphores can be used as signaling devices between tasks and ISRs aswell. • A semaphore can be released from inside an ISR unblocking a task. • A semaphore can be acquired from an ISR blocking task

67

7.2 SEMAPHORE PROBLEMS Priority inversion: • Task a, task b and task c are in decreasing order of priority. • Task c acquires semaphore. • Task b gets unblocked and takes control. • Task a wants semaphore and gets blocked. • Task c can’t release semaphore because task b is running. • So task b holds up higher priority task a, hence priority inversion. • Solved by priority inheritance where task c is temporarily elevated above task b.

68

7.2 SEMAPHORE PROBLEMS Deadlock or deadly embrace Void task1( void ) { take(semaphore1); take(semaphore2); a=b; give(semaphore1); give(semaphore2); }

Void task1( void ) { take(semaphore2); take(semaphore1); b=a; give(semaphore1); give(semaphore2); }

69

7.2 SEMAPHORE PROBLEMS     

Forget to initialize semaphore. Forget to take semaphore. Forget to give semaphore. Taking wrong semaphore. Holding semaphore too long.

70

7.3 SEMAPHORES TYPES • Counting semaphores: Taking increments count and giving up decrements count. Blocks when count is zero. • Resource semaphores: These are released only by a task and cannot be used to communicate with ISRs. • Mutex semaphores: These automatically take care of priority inversion.

71

8.MESSAGE QUEUES • The inter task communication is achieved using above said tools. • Where to use? • •

• •

Let’s assume two tasks 1 & 2 are of high priority and have important things to do. If from time to time these tasks detect error conditions that need to be reported, but reporting is a time consuming process. In these situations it’s preferable to call a separate task errors task which takes care of errors. Errors are queued and sent to errors task, which takes care of things to do.

72

8.1 PITFALLS

• Reading wrong information from wrong task. • Improper interpretation, writing of char pointer and reading as int pointer. • Running out of space.

73

9.COMPARISON OF COMMUNICATION METHODS

 Semaphores are fastest and simplest but can transfer only one bit of information, taking or releasing of semaphore.  Event though convey similar amount of information compared to a semaphore, a task can wait for more than one event at the same time.  Queues can send larger data but take more processor time and can cause more bugs. These points apply to mail boxes as well as pipes.

74

10.ISR IN RTOS ENVIRONMENT • Two rules are to be followed when using ISR’s with RTOS. •

•

Rule 1: ISR must not call any RTOS function that might block caller. Rule 2: An interrupt routine may not call any RTOS function that may cause switching of tasks unless RTOS knows it’s an ISR rather than a task which is calling the function.

75

10. IMPILICATIONS: RULE 1 static int tem[2]; void interrupt readtemp( void ) { while( 1 ) { getsem(); temp[0] = read temp[1] = read givesem(); } }

void testtemp( void ) { int temp0,temp1; while( 1 ) { getsem(); temp0 = temp[0]; temp1 = temp[1]; if(temp0 != temp1) set alarm; givesem(); } }

76

10. IMPILICATIONS: RULE 2

EXPECTED BEHAVIOUR OF RTOS WITH ISR

77

10. IMPILICATIONS: RULE 2

BEHAVIOUR WHEN THERE IS NO DIFFERENCE BETWEEN ISR AND A TASK

78

10. IMPILICATIONS: RULE 2

RTOS INTERCEPTS INTERRUPTS AND CALLS ISR

79

10. IMPILICATIONS: RULE 2

ISR INVOKES RTOS USING ISR SEMAPHORES

80

10.1 NESTED INTERRUPTS WITH RTOS

81