Everything

CHAPTER 15 REALTIME OS TASK ANALYZER


15.1 Outline
The following information is required when analyzing the system incorporating Realtime OS.
- The execution situation of processing programs
- The use situation of Realtime OS resources
- The CPU usage rate for every processing program
The tool for realizing the above is "Realtime OS Task Analyzer". The Realtime OS Task Analyzer analyzes the information outputted by Realtime OS and displays it graphically.
This chapter describes the procedure for using Realtime OS Task Analyzer. See "RI600V4 Analysis" for the functions and operation method of the Realtime OS Task Analyzer.
15.2 Trace Mode
There is the type of usage shown below in the Realtime OS Task Analyzer. The trace mode is selected in [ Task Analyzer ] tab.
- Taking in trace chart by hardware trace mode
In this mode, the trace information is collected in the trace memory which emulator or simulator has.
- Taking in trace chart by software trace mode
In this mode, the trace information is collected in the trace buffer secured on the user memory area. The buffer size is specified in [ Task Analyzer ] tab. Please refer to "15.4 Trace Buffer Size (Taking in Trace Chart by Software Trace Mode)" for the estimate of the size of the trace buffer.
To use this mode, implementation of user-own coding module and setup of the system configuration file are required. For details, refer to "15.3.1 Taking in trace chart by software trace mode".
- Taking in long-statistics by software trace mode
In this mode, the trace information is collected in the RI600V4's variable secured on the user memory area. The size of this variable is roughly 2 K-bytes. For details, refer to "19.20.1 BRI_RAM section".
To use this mode, implementation of user-own coding module and setup of the system configuration file are required. For details, refer to "15.3.2 Taking in long-statistics by software trace mode".
- Not tracing
The Realtime OS Task Analyzer can not be used.
The measurable maximum time and the time precision differ for every trace mode. The standard is shown to Figure 15-1.
Figure 15-1 Measurable maximum time and the time precision

Note 1 In the "Taking in trace chart by hardware trace mode", the measurable maximum time depends on the size of the trace memory which the emulator or simulator has. And the time precision depends on the emulator or simulator specification.
Note 2 In the "Taking in trace chart by softwarre trace mode", the measurable maximum time depends on the size of the trace buffer. And refer to "15.3.1 Taking in trace chart by software trace mode" for the time precision.
Note 3 In the "Taking in long-statistics by software trace mode", refer to "15.3.2 Taking in long-statistics by software trace mode" for the measurable maximum time and the time precision.
When using the Realtime OS Task Analyzer, compared with the case where it is not used,it has the influence shown in Table 15-1 on the target system. Note, the processing time in Table 15-1 is approximate value when the CPU clock is 100MHz.
Table 15-1 Influence on Target System
Taking in trace chart by hardware trace mode
Taking in trace chart by software trace mode
Taking in long-statistics by software trace mode
Service call processing time
Worse for about 0.5 - 1.5 s (It depends on the number of tasks state change.)
Worse for about 1.5 - 5 s (It depends on the number of tasks state change.)
No degradation
Task-dispatching processing time
Worse for about 0.2 s
Worse for about 0.7 s
Worse for about 0.6 s
Interrupt processing time
Worse for about 0.5 s
Worse for about 1 - 2 s
Worse for about 1 - 2 s
Consumption of RAM
No degradation
Needs a buffer
Roughly 2 K-bytes
Implementation of user-own coding module and setup of the system configuration file
Not required
Required
Required

Reference to the function of each mode , Figure 15-1 and Table 15-1, please decide the trace mode to be used.
The trace mode is selected in [ Task Analyzer ] tab. Then by performing a build, the load module which contains the Realtime OS module that corresponds the trace mode to be selected is generated.
15.3 User-Own Coding Module for Software Trace Mode
15.3.1 Taking in trace chart by software trace mode
In this mode, the RI600V4 gets time-stamp from user-own coding module. Usually, the hardware timer is used in order to generate time-stamp. The bit width of the counter of the hardware timer has necessity of 16 bits or more. Note, CMT (Compare Match Timer), which is built in RX family MCU as standard, satisfies this requirement.
This section describes the specification of function and variables to be implemented as user-own coding module. Since each function does not follow ABI (Application Binary Interface) of the RX family C/C++ compiler, it needs to be implemented by using assembly language. In this section, function and variable name are described in assembly language level.
Note The sample file provided by the RI600V4 is "trcSW_cmt.src". This file uses CMT channel-1.
1 ) __RIUSR_trcSW_base_time (Time precision)
Define the unit of the time returned by __RIUSR_trcSW_read_cnt (Function to get time-stamp) as a constant for the 32 bit- unsigned integer. Usually, please set up the time of 1 count of hardware timer counter.
A typical setup in the case of using CMT is shown below.
PCLK
Dividing rate
Time precision (see Note)
12.5 MHz
8
0.64 s
32
2.56 s
128
10.24 s
512
40.96 s
25 MHz
8
0.32 s
32
1.28 s
128
5.12 s
512
20.48 s

Note Precision of time = __RIUSR_trcSW_base_time
2 ) __RIUSR_trcSW_init_tmr (Initialization function)
Description
This function initializes the hardware timer so that specification of __RIUSR_trcSW_read_cnt (Function to get time-stamp) may be realized.
In the sample, this function initializes the CMT so that interruption may be generated, when the timer clock is counted 65536 times.
This function is called-back from vsta_knl service call.
Parameter
None
Registers which do not need to guarantee
R1, R2, R3, R4, R5, R6, R7, R14, R15
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Up to 8 bytes

3 ) __RIUSR_trcSW_read_cnt (Function to get time-stamp)
Description
This function returns the elapsed time from the time of __RIUSR_trcSW_init_tmr (Initialization function) was called. The value returned must be in the range of from 0 and 0x7FFFFFFF, in units of the __RIUSR_trcSW_base_time (Time precision).
In the sample, the lower 16 bits of the return value is CMT counter register, and the upper 16 bits is the number of the timer interruption.
The return value must not be less than the previous return value.
Parameter
R5 (Out) : Elapsed time
Registers which do not need to guarantee
R3, R4
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Up to 8 bytes
4 ) Interrupt handler (Arbitrary function name)
Description
In the sample, this interrupt occurs when the timer clock is counted 65536 times.
This handler must not call service calls.
This handler exits by RTE instruction.
And this interrupt handler should be defined as follows in the system configuration file. Here, an example in case the vector number is 29 and function name is __RIUSR_trcSW_interrupt (assembly language level) is shown.
     interrupt_vector[29] {
         entry_address = _RIUSR_trcSW_interrupt();
         os_int = NO;
     };
Parameter
None
Registers which do not need to guarantee
None
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Please take into consideration in "D.4 System Stack Size Estimation".

15.3.2 Taking in long-statistics by software trace mode
In this mode, the RI600V4 gets time-stamp from user-own coding module. Usually, the hardware timer is used in order to generate time-stamp. The bit width of the counter of the hardware timer has necessity of 16 bits or more, and must be able to generate an interrupt when the timer clock is counted 65536 times. Note, CMT (Compare Match Timer) standardly built in RX family MCU is satisfying this requirement.
This section describes the specification of function and variables to be implemented as user-own coding module. Since each function does not follow ABI (Application Binary Interface) of the RX family C/C++ compiler, it needs to be implemented by using assembly language. In this section, function and variable name are described in assembly language level.
Note The sample file provided by the RI600V4 is "trcLONG_cmt.src". This file uses CMT channel-1.
1 ) __RIUSR_trcLONG_base_time (TIme precision)
Define the unit of the time returned by __RIUSR_trcLONG_read_cnt (Function to get time-stamp) as a constant for the 32 bit- unsigned integer.
Usually, please set up the time of 1 count of hardware timer counter.
A typical setup in the case of using CMT is shown below.
PCLK
Dividing rate
Time precision of interrupt handler execution time (see Note 1)
Measurable maximum time of interrupt handler execution time (see Note 2)
Time precision of task execution time (see Note 3)
Measurable maximum time of task execution time (see Note 4)
12.5 MHz
8
0.64 s
About 41 ms
5.12 s
About 6 hr. 6 min.
32
2.56 s
About 167 ms
20.48 s
About 24 hr. 26 min.
128
10.24 s
About 671 ms
81.92 s
About 97 hr. 44 min.
256
40.96 s
About 2684 ms
327.68 s
About 390 hr. 56 min.
25 MHz
8
0.32 s
About 20 ms
2.56 s
About 3 hr. 3 min.
32
1.28 s
About 83 ms
10.24 s
About 12 hr. 13 min.
128
5.12 s
About 335 ms
40.96 s
About 48 hr. 52 min.
256
20.48 s
About 1342 ms
163.84 s
About 195 hr. 28 min.

Note 1 Time precision of interrupt handler execution time = __RIUSR_trcLONG_base_time
Note 2 Measurable maximum time of interrupt handler execution time = __RIUSR_trcLONG_base_time * 65536
Note 3 Time precision of task execution time = __RIUSR_trcLONG_base_time * 8
Note 4 Measurable maximum time of task execution time = __RIUSR_trcLONG_base_time * 8 * 0xFFFFFFFF
2 ) __RIUSR_trcLONG_timer_lvl (Interrupt priority level)
Define the interrupt priority level of the using hardware timer as a constant for the 8 bit- unsigned integer.
The execution time of interrupt handlers with interrupt priority level more than or equal to this interrupt priority level are not measured. The execution time of that interrupt handlers are appropriated for the execution time of the processing program (tasks, another interrupt handlers, or kernel idling) which was executing when that interrupt occurred.
The interrupt priority level of this timer recommends using the highest.
3 ) __RIUSR_trcLONG_init_tmr (Initialization function)
Description
This function initializes the hardware timer so that interruption which interrupt priority level is __RIUSR_trcLONG_timer_lvl (Interrupt priority level) may be generated, when the timer clock is counted 65536 times.
This function is called-back from vsta_knl service call.
Parameter
None
Registers which do not need to guarantee
R1, R2, R3, R4, R5, R6, R7, R14, R15
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Up to 8 bytes

4 ) __RIUSR_trcLONG_read_cnt (Function to get time-stamp)
Description
This function returns the elapsed time from the previous interruption. The value returned must be in the range of from 0 and 65535 in units of the __RIUSR_trcLONG_base_time (TIme precision).
In the sample, this function returns the value of the CMT counter register.
Parameter
R1 (Out) : Elapsed time
Registers which do not need to guarantee
R4
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Up to 8 bytes
5 ) Interrupt handler (Arbitrary function name)
Description
This handler must not call service calls.
This handler exits by RTE instruction.
And this interrupt handler should be defined as follows in the system configuration file. Here, an example in case the vector number is 29 and function name is __RIUSR_trcLONG_interrupt (assembly language level) is shown.
     interrupt_vector[29] {
         entry_address = _RIUSR_trcLONG_interrupt();
         os_int = NO;
     };
Parameter
None
Registers which do not need to guarantee
None
PSW when started (Do not change)
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Available stack size
Please take into consideration in "D.4 System Stack Size Estimation".

6 ) RI600V4's __RI_trcLONG_update_time function
This function is not user-own coding module, is implemented in the RI600V4. The following is a specification of this function.
Description
This function updates the current time information managed by RI600V4.
This function should be called from the above interrupt handler.
Parameter
None
Registers which are not guaranteed
R1, R2
PSW when calling
PM = 0 (Supervisor mode)
I = 0 (Disable all interrupts)
U = 0 (System stack)
Stack size
0 bytes (It does not include 4 bytes which is used by BSR instruction for calling this function.)

15.4 Trace Buffer Size (Taking in Trace Chart by Software Trace Mode)
Table 15-2 shows the timing by which the trace buffer is consumed.
Table 15-2 Timing by which the trace buffer is consumed
Timing
Size to consume
Immediately after service call
12 bytes
Just before returning to application from RI600V4
8 bytes
When a task dispatches
8 bytes
When the RI600V4 enters Idling
8 bytes
When an interrupt handler starts
8 bytes
When an interrupt handler ends
8 bytes
When a cyclic handler starts
8 bytes
When a cyclic handler ends
8 bytes
When an alarm handler starts
8 bytes
When an alarm handler ends
8 bytes
When a task status changes
8 bytes

Table 15-3 shows the standard of measurable time.
Table 15-3 The standard of time after used up the buffers
Event generating frequency
Buffer Size
1 KB
4 KB
16 KB
64 KB
5 s / Event
About 0.6 ms
About 2.4 ms
About 9.6 ms
About 38 ms
10 s / Event
About 1.2 ms
About 4.8 ms
About 19 ms
About 77ms
50 s / Event
About 6 ms
About 24 ms
About 96 ms
About 385ms
100 s / Event
About 12 ms
About 48 ms
About 192 ms
About 771 ms
500 s / Event
About 60 ms
About 240 ms
About 963 ms
About 3855 ms

15.5 Error of Total Execution Time
Total execution time of tasks or interrupt handlers is calculated by adding the execution time of each time. Therefore, the error of total execution time will also become large if the execution count increases.