Testing and Debugging

In this section we describe how we validate our implementation using tracing with logic analyser. We then show how we report error using a logic analyser. We have also implemented a kernel tracing mechanism. We set aside a circular trace buffer where function_id, enter/exit, and time of call is stored. The following listing shows the function prototype for adding a trace to the kernel. 
void add_trace(uint8_t process_number, uint8_t enter, uint16_t time);


This kernel trace can be used to prove the validity of our implementation. However, we preferred to use logic analyser as it is visually more intuitive.

API Conformance

1a. System Tasks Pre-empts Periodic Tasks and 2. System tasks run to completion


We show that System tasks pre-empts both the periodic and RR tasks. In addition, periodic tasks pre-empts RR tasks. These tests show that a higher priority task pre-empts a lower priority task.


Figure 1: System tasks pre-empting periodic tasks. Notice, that the periodic task was unaware of pre-emption. The system task was created by the preempted periodic task.


1b. System Tasks Pre-empts RR Tasks and 2. System tasks run to completion 7. RR tasks run for 2 RTOS ticks when not interrupted



Figure 2: System tasks pre-empting RR tasks.


1c. Periodic Tasks Pre-empts RR Tasks



Figure 3: Periodic tasks pre-empting RR tasks.


3a. System Tasks are First-Come-First-Served


We now show that system tasks are first come first served and that rr tasks go to the end of rr_queue if they are allowed execute two RTOS ticks without any interruption.


Figure 4: System tasks are first-come-first-served.


3b. RR Tasks are First-Come-First-Served





Figure 5: RR tasks are first-come-first-served.


8. RR Tasks move to the front of the queue





Figure 5: RR tasks go to the front of the queue when they are interrupted.


9. RR tasks goes to the end of queue



Figure 5: RR tasks go to the end of rr_queue when they are able to execute two RTOS ticks without interruption or pre-emption.


Error Detection and Reporting

We preferred error reporting with logic analyser instead of LEDs. However, both the methods are equivalent and interchangeable. Nevertheless, error reporting with logic analyser is much more helpful as it helps decode error messages quickly. In our implementation, each error has a unique number (beginning from 1). We set aside Channel 7 of a logic analyser for the error reporting. When an error occurs, we display corresponding number of highs each of 0.5ms duration followed by a 10 ms of continuous low. This process repeats indefinitely. The following listing shows how we implemented this. 

#ifdef TRACING_WITH_LOGIC_ANALYZER
INIT_LOGIC_ANALYZER 
while(1){
	for (i = 0; i <= kernel_error; ++i){
		LOGIC_ANALYZER_PORT |= _BV(LOGIC_ANALYZER_ERROR_CHANNEL);
		_delay_us(500);
		LOGIC_ANALYZER_PORT &= ~_BV(LOGIC_ANALYZER_ERROR_CHANNEL);
	}
	_delay_ms(10);
}
#endif

Total Number of Events Exceeded MAXEVENTS



Figure 6: Total number of events exceeded MAXEVENTS.


Total Number of Tasks Exceeded MAXPROCESS



Figure 7: Total number of events exceeded MAXEVENTS.


Periodic Task waiting on an Event



Figure 8: A periodic task called Event_Wait or Event_Wait_Next.


Multiple Periodic Tasks Scheduled at the Same Time



Figure 9: Multiple periodic tasks arrived (or scheduled) at the same time.


A Periodic Task Exceeded WCET



Figure 10: A Periodic task has executed for more than its WCET. RTOS aborted due to hard real time behaviour.


WCET is Greater than the Period



Figure 11: WCET of a periodic task is greater than its period.

Instrumentation

Table 1 shows the CPU time taken by several RTOS primitives on an 11.0592 MHz 8 bit ATmel AVR CPU. An user may need to instrument these functions again if their platform is different from ours.
Function Time
Task_Create_System 60 µs
Task_Create_Periodic 64 µs
Task_Create_RR 60 µs
Event_Init 40 µs
RTOS tick 15 µs
Enter Kernel 16 µs
Exit Kernel 16 µs
Task Terminate 32 µs
Table 1: RTOS instrumentation based on 11.0592 MHz. clock