CSC560: Design and Analysis of Real Time Systems

We formally mention the requirements specified in os.h. We need to demonstrate that those requirements are fulfilled by our implementation. In this page we list the functional requirements we implemented and tested. Section Testing and Debugging contains the screen shots for these tests. We tried to be very thorough and accurate in reporting the status of our implementation and testing so that any user of our RTOS is aware of its limitations.

We do not check in our implementation if the following assumptions are violated. An user of our RTOS is expected to respect these assumptions.

• Timer2 and SWI interrupts are reserved.
• All runtime exceptions and unrecoverable errors get handled by calling OS_Abort().
• All timing parameters are defined in RTOS tick.

There are three different kind of tasks with three levels of priorities. They are in decreasing order of priorities:

1. System,
2. Periodic, and
3. Round Robin.

The scheduling policy is given below.

1. Ready (and schedulable ) higher priority tasks pre-empts running lower priority tasks.
2. System tasks run to completion, or until they voluntarily give up the CPU, or until they wait for an event.
3. System tasks and RR tasks are first come first served.
4. Periodic tasks do not execute more than its WCET (worst-case execution time).
5. Periodic tasks do not overlap.
6. Periodic and RR tasks' execution time are extended if they are interrupted or pre-empted by the duration of pre-emption.
7. RR tasks execute for two ticks.
8. RR tasks move to the front of the queue if they are interrupted or preempted.
9. RR tasks move to the back of the queue when they were able to execute for two RTOS ticks.

We endeavoured to implement these requirements as thoroughly as possible. Please, see Section Scheduling for details of our implementation.

Table 1: Implementation completion matrix for scheduling policy.

Requirement no.	Status	Tested
1.	✔	✔
2.	✔	✔
3.	✔	✔
4.	✔	✔
5.	✔	✔
6.	✔	×
7.	✔	✔
8.	✔	✔
9.	✔	✔

The accuracy of stretching or extending the WCET of a periodic task and the quantum of an RR task is limited to only one RTOS tick. That is if a task is interrupted for at least a millisecond but less than an RTOS tick (5 milliseconds) the task is extended for a whole RTOS tick (5 milliseconds). Also, if a task is interrupted for less than a millisecond in total the task is not stretched at all. Note that this stretching takes place when the kernel is aware of the pre-emption. If an ISR pre-empts a task and the kernel is not aware of this pre-emption then the task may not be stretched properly. This has some important consequences. A task can in reality has been executing for more than WCET time but the scheduler may still think that it has been executing for an RTOS tick only. This can happen when a task is interrupted by an ISR just before an RTOS tick takes place and gets back the CPU just after tick. Again, a task may execute for only a fraction of WCET or a quantum but the scheduler may think that it already has executed for its share of time. This can happen if a task is pre-empted by an ISR in the beginning of a tick and gets the CPU back just before an RTOS tick. Therefore, an application engineer must keep record of pre-emption time of cur_task in an ISR that takes place without the knowledge of the kernel and that returns the CPU to the interrupted task (not to the kernel). Following listing might be one way to handle this.

ISR(an_ISR)
{
	cur_task->preemption_begin_time = Now();
	/* ISR logic goes here */
	
	/* ISR logic ends above */
	
	cur_task->interrupted_time += (Now() - cur_task->preemption_begin_time);
	if (cur_task->interrupted_time / 5 > 0){
		cur_task->remaining_ticks += (cur_task->interrupted_time / 5);
		cur_task->interrupted_time = (cur_task->interrupted_time % 5);
	}
}
					

1. Periodic tasks never wait or block.
2. System and RR tasks can wait for events.
3. Any task can signal an event.
4. A signal for an event e can be generated before a task waits for it.
5. Only one task can wait for an event.

Although Requirement 5, that is, only one task can wait for an event, seems limiting it simplifies implementation and potentially removes priority inversion problem. We will talk more about IPC in Section IPC.

Table 2: Implementation completion matrix for IPC policy.

Requirement no.	Status	Tested
1.	✔	✔
2.	✔	✔
3.	✔	×
4.	✔	×
5.	✔	✔

Section Testing and Debugging contains screen shots for the test results.