L7 RTOS Services

8/3/2019 L7 RTOS Services

1/13

IN2305-IIEmbedded Programming

Lecture 7:

More OS Services


2/13

in2305-II: L7 2

Queues, Mailboxes, Pipes

Semaphores: synchronization

Queues etc.: synchronization + data communication

No shared data problems unlessyou pass pointer to

the original data in other task (cf. Fig. 7.4)

Same pitfalls as semaphores (deadlock, etc.)


3/13

in2305-II: L7 3

Time Delay Function

X32 delay(dt): busy waits (loops) until X32 clock hasadvanced dtms (polling)

OS OS_Delay(n): suspends caller (task) until time has

advanced nOS ticks (interrupt)OS delay is more efficient: schedules othertasks (doesuseful work) while waiting for time to pass

OS now needs a timer interruptmechanism toperiodically check if time has passed (NOTE: until now

the OS services (context switching) were initiated bytaskcalls, no interrupts were needed .. yet)

Timer interrupt called tick(e.g., 1 ms) whichdetermines delay resolution (and OS overhead ..)


4/13

in2305-II: L7 4

OS Delay Processing

Task 2

timer IRQ

timer ISR

Task 1

OS_Delay(2)

RTOS

highest priority task starts first

context switch

delay expired

tick tick


5/13


6/13

in2305-II: L7 6

RTOS and Interrupts (1)

Apart from OS-supported delays (and timers) RTOS andinterrupts are separate worlds

Nevertheless, any embedded program will use

interrupts in order to react/respond to external world(buttons, I/O lines, UART, decoder, ..)

In order to guarantee proper functioning of the RTOS inthe presence of interrupts, a number of programmingrules must be obeyed:


7/13

in2305-II: L7 7

RTOS and Interrupts (2)

Rule 1: an ISR must notcall any RTOS function thatmight blockthe caller. So nopend-type calls (this iswhy semaphores are not allowed to protect shared datain ISRs). Violating this rule may affect response timeand may even cause deadlock!

Rule 2: An ISR must notcall any RTOS function thatmight cause a context switch unlessRTOS knows thatits an ISR(and not a task) that is calling. So nopost-

type calls (which is typical use!) unless RTOS knows itsan ISR. Violating this rule may allow RTOS to switch toother task and the ISR may not complete for a longtime, thus greatly affecting response time!


8/13

in2305-II: L7 8

Example Violating Rule 1

void isr_read_temps(void) // (reactor){

OS_Pend(s);iTemp[0] = peripherals[..];iTemp[1] = peripherals[..];

OS_Post(s);}

void main(void){

...

OS_Pend(s);iTemp[0] = iTemperatures[0];iTemp[1] = iTemperatures[1];OS_Post(s);

...}

interrupt

ISR Deadlock!


9/13

in2305-II: L7 9


void isr_buttons(void) // (UTMS){

if (peripherals[BUTTONS] & 0x01) // button 0OS_Post(event); // signal event

}

void vButtonTask(void){

while (TRUE) {OS_Pend(event); // wait for eventprintf(current float levels: \n);

!! list them}

}


10/13

in2305-II: L7 10


vLevelsTask

button ISR

vButtonTask

RTOS

context switchafter ISR finished

How ISRs should work:

OS_Post

vLevelsTask

button ISR

vButtonTask

RTOS

context switchbefore ISR finished!

What would really happen:

OS_Post


11/13

in2305-II: L7 11

Solution to Satisfy Rule 2 (uC/OS)

Let the RTOS know an ISR is in progress by callingOSIntEnter()/OSIntExit() (uC/OS)

void isr_buttons(void) // (UTMS)

{OSIntEnter(); // warn uC/OS not to rescheduleif (peripherals[BUTTONS] & 0x01) // button 0

OS_Post(event); // signal eventOSIntExit(); // uC/OS free to reschedule

}

vLevelsTask

button ISR

vButtonTask

RTOS

OS_Post but NO context switch


12/13

in2305-II: L7 12

Rule 2 and Nested Interrupts (X32)

Apart from calling OSIntEnter()/OSIntExit()keep countof interrupt nesting; only allow RTOSrescheduling when allISRs are finished

low prio task

low prio ISR

high prio task

RTOS

OS_Post

high prio ISR

If no ISR nesting counted, RTOSwould reschedule instead ofallowing low prio ISR to finish!


13/13

in2305-II: L7 13

X32: Demo

Demo ..

(x32_projects.tgz: ucos_isr.c)

L7 RTOS Services

Documents

Transcript of L7 RTOS Services