EENG 383

Real Time Operating Systems

Interrupt background

• How does the MCU know where to find the ISR?
• Can the MCU interrupt in the middle of an instruction?
• If 2 interrupts occur at the same time which interrupt is serviced first?
• Can an interrupt interrupt another ISR?
• What happen to an interrupt if interrupts are disabled?
• What happen if interrupts are disabled and not reenabled?
• What happens if I disable/enable interrupts and their are already disabled/enabled?

Shared Data Problem

1. The temperature is changing.
2. We have just finished executing the "iTemp0..." line in main
3. The interrupt occurs and updates both values of iTemp[]

Shared Data Problem

	Before		After		Value used by
	Interrupt	Interrupt	SecSinceMidnight
iHr	3		4		3
iMin	59		00		00
iSec	59		00		00

Volatile

    int8 flag;
void main() {
    ...
    while(flag == FALSE);
    ...
} // end main

void TMR0_ISR() {
    ...
    flag = TRUE;
    ...
} // end ISR

	mov	flag, R1
loop:	sub	R1,ZERO
	btfsc	status,z
	goto	loop

    volatile int8 flag;

loop:	mov	flag, R1
	sub	R1,ZERO
	btfsc	status,z
	goto	loop

Embedded Software Architectures

• Round-Robin (or superloop).
• Round-Robin with interrupts
• Non-preemptive Real-Time Operating System
• Preemptive Real-Time Operating System

Round-Robin (or superloop)

void main() {
    init();
    while(1) {
	task1();
	task2();
	...
}   }

Round-Robin with interrupts

int8 data_for_device_A;

void main() {
    init();
    while(1) {
	task1();
	task2();
	...
	if (global_flag_A) taskA();
}   }

void ISR_deviceA() {
    service_A(data_for_device_A);
    set(global_flag_A);
}

Non-preemptive Real-Time Operating System

Preemptive Real-Time Operating System

Conclusion

• Priorities
  • RR - none
  • RR w/ INTs - Interrupt routine priorities
  • RTOS - Interrupt routine priorities and then task priorities
• Worst Response Time for critical Task Code
  • RR - total execution time for all tasks
  • RR w/ INTs - total execution time for all tasks + time for all ISRs
  • nonpremptive RTOS - time of longest tasks + time for all ISRs
  • premptive RTOS - time for all ISRs.
• Stability of Response when the code changes
  • RR - poor
  • RR w/ INTs - good for interrupts, poor for tasks
  • nonpremptive RTOS - realitively good.
  • premptive RTOS - very good.
• Simplicity
  • RR - very simple.
  • RR w/ INTs - must deal with shared data problem.
  • RTOS - must set-up system, otherwise not too bad

Real Time Operating Systems

• They allow a user to write independent programs called tasks.
• They give users tools to work with system resources.
• They allow the MCU to be shared between different tasks.

• A PC operating system takes charge of the computer on start-up. A RTOS initially gives the user control of the CPU, the user sets-up the tasks, and then starts the RTOS.
• A RTOS does not protect itself as carefully from your applications as a PC OS. For example, most PC OS check that you are using a valid pointer, a RTOS will skip this step in the interest of better performance.
• Most RTOS allow you to extensively configure them in order to eliminate any modules that you do not need.

Tasks

• Running - the MCU is executing this task. A running task will puts itself into the blocked state if waits on an event or another task with higher priority becomes unblocked.
• Ready - Another task is running but this task has things that it could do if the MCU became available. The scheduler moves a task from the ready to the running state.
• Blocked - the task does not have anything to do. Tasks get into this state because they are waiting for some external event.
  • A task will only enter the blocked state because it decides for itself that it has run out of useful things to do. Other tasks in the system or the scheduler cannot decide for a task that it needs top wait for something. As a consequence of this, a task had to be running just before it is blocked. It has to execute the instruction that figures out that there 's nothing else to do.
  • While a task is blocked it never get the CPU. Therefore, some other task must signal that whatever the task was waiting for has happened. Otherwise the task will be blocked forever.
  • An event is an occurrence which a task can wait for, examples include
    • An interrupt
    • An error
    • A timer timing out
    • Periodic interrupt
    • A resource being freed
    • An I/O pin changing state
    • A keypress
    • RS-232 Tx or Rx
    • message being passed

Scheduler

Common Questions

• How does the scheduler know when a task has become blocked or unblocked?
• What happens if all the tasks are blocked?
• What if two tasks with the same prioity are ready?
• If a task with a higher priority is unblocked does it become the running task?

A Simple Example

event GREEN_CHEESE, CLOCK_STRIKE_ONE;
int8 NUM_MICE;

//---------------------------------------------------
//---------------------------------------------------
main() {
    CreateTask(CowTask, high);
    CreateTask(MouseTask, low);

    CreateEvent(FULL_MOON);
    CreateEvent(CLOCK_STRIKE_ONE);
    CreateEvent(GREEN_CHEESE);

    StartMultitasking();
}


//---------------------------------------------------
//---------------------------------------------------
CowTask() {
    while(1) {
	WaitForEvent(FULL_MOON);
	JUMP_OVER_MOON();
	SignalEvent(GREEN_CHEESE);
}   }

//---------------------------------------------------
//---------------------------------------------------
MouseTask() {
    while(1) {
	WaitForEvent(GREEN_CHEESE);
	RUN_UP_THE_CLOCK();
	WaitForEvent(CLOCK_STIKE_ONE);
	mice -= 1;
	RUN_DOWN_THE_CLOCK();
}   }


//---------------------------------------------------
//---------------------------------------------------
TMR0_ISR() {
    static int8 hour=0;
    if (hour == 24) hour = 0;
    if (hour == 1) SignalEvent(CLOCK_STRIKE_ONE);
}	

Allocation of memory

static int8 x;
int8 y=4;
char *string = "Where does it go?";
void *ptr;

void fnc(int8 a, int8 *b) {
    static int8 a;
    int8 local;
    ...
}

• static int8 x;

• int8 y=4;

  This should be given a fixed address because any function in this C file's context can access and manipulate this var. This also opens it up for shared variable problems.

• char *string = "Where does it go?";

• void *ptr;

Review

A very simple RTOS application

void taskB() {
    while(1) {
	WaitForEvent(eventA);
	SignalEvent(eventB);
	taskB_stuff();
}   }

void taskA() {
    while(1) {
	SignalEvent(eventA);
	WaitForEvent(eventB);
	taskA_stuff();
}   }

Review

1. Process do not go from the blocked to the running state. First a process must be unblocked, it then moves to the ready queue. From their the RTOS might move it to the running state.
2. A running process can block itself by waiting for an event.
3. A ready process can become the running process if
   1. The running process blocked itself.
   2. The ready process (lets call it task B) has a higher priority then the actively running process (called task A). Lets look at this situation more carefully. We know that when the RTOS is given a choice of tasks to run it will always pick the one with the highest priority. From this we can infer that when the RTOS choose to run task A, task B was blocked. While task A was running, task B must have become unblocked. There are two different ways that this could have happened:
      1. If task A signaled some event which task B was waiting on. Hence task A is responsible for its loosing the CPU.
      2. An ISR signaled some event on which task B was waiting.
4. A running task is moved to the ready state if another process with a higher priority enters the ready state and the RTOS preempts the currently running task. Thus, this can only happen in a preemptive RTOS.
5. A task is moves from the blocked to the ready state when an event is triggered by the currently running task or an ISR.
6. Ready tasks are never blocked. They must first run, even if for a very short period of time.

Priority Inversion

Shared Data Problem

signed int8 total=0;

// High priority task 
void taskA() {
    while(1) {
	WaitForEvent(eventISR);
	foobar(-1);
	taskA_stuff();
}   } // end taskA

// Low priority task 
void taskB() {
    while(1) {
	foobar(+1);
	taskB_stuff();
}   } // end taskB

void foobar(int8 val) {
    // a VERY complex time consuming function which
    // manipulates static locals and global variables.
} // end foobar

void tmr0_isr() {
    SignalEvent(eventISR);
    // Set TMR0 to some value
} // end tmr0_isr

1. RTOS initializes and puts taskA and taskB into the ready state. The RTOS then picks taskA to run since it has the higher priority.
2. taskA blocks on eventISR
3. The RTOS moves taskA to the blocked state.
4. The RTOS moves taskB to the running state.
5. taskB calls foobar(+1) (and will be a while completing it).
6. The ISR wakes up signals eventISR.
7. The RTOS move taskA from the blocked state to the ready state.
8. The preemptive RTOS notices that a ready task has a higher priority then the running task.
9. The preemptive RTOS move taskB to the ready state and moves taskA to the running state.
10. taskA runs foobar(-1) and contaminates the local variables what taskB was using. At some point taskA will block waiting for eventISR>
11. RTOS will move taskA to the blocked state and taskB to the running state.
12. taskB will resume execution with the corrupted values for the global variables used by foobar.

Reentrant functions

//--------------------------------------------------------
// foobar(int8 val)
// A VERY complex time consuming function.  This function
// has many reentrant problems.
//--------------------------------------------------------
void foobar(int8 val, char *string) {
    int8 temp;		// locals are allocated on the stack
    static int8 temp;	// static locals are allocated on the heap

    temp = global;
    temp += 1;		// interrupting here is bad
    global = temp;
    *ptr  = val;
    WRITE_LCD(string);	// interrupting here is bad
    global = fnc(val);	// interrupting here is bad
} // end foobar

//--------------------------------------------------------
// fnc(int8 val)
// A nonreentrant function
//--------------------------------------------------------
void fnc(int8 val) {
    nonreentrant_stuff();
}

1. A reentrant function may not use variables in a non-atomic way unless they are stored on the stack of the task that called the function or are otherwise the private variables of that task. An atomic operation is one which requires a single assembly instructions to complete. An atomic operation is not interruptable. Thus a variable which can be shared between several invocations must be manipulated in an atomic way, otherwise the function is non-atomic.
2. A reentrant function may not call any other functions that are not themselves reentrant.
3. A reentrant function may not use the hardware in a non-atomic way.

Semaphore

void TaskA() {
    ....
    TakeSemaphore(semaphoreSQRT);
    a = SQRT(b);
    ReleaseSemaphore(semaphoreSQRT);
    ....
} 

void TaskB() {
    ....
    TakeSemaphore(semaphoreSQRT);
    c = SQRT(d);
    ReleaseSemaphore(semaphoreSQRT);
    ....
} 

1. The failure of a task to claim a semaphore must prohibit the task from using the shared resources. In general a task which is unable to claim a semaphore should be blocked.
2. The access to the sempahore must be atomic.

• DECFSZ - Decrement f, Skip if 0
• DCFSNZ - Decrement f, Skip if Not 0
• INCFSZ - Increment f, Skip if 0
• INFSNZ - Increment f, Skip if Not 0

Semaphore Problems

void TaskA() {
    ....
    TakeSemaphore(A);
    TakeSemaphore(B);
    stuff();
    ....
    ReleaseSemaphore(B);
    ReleaseSemaphore(A);
} 

void TaskB() {
    ....
    TakeSemaphore(A);
    TakeSemaphore(B);
    stuff();
    ....
    ReleaseSemaphore(B);
    ReleaseSemaphore(A);
    ....
}