CHAPTER 15 REALTIME OS TASK ANALYZER
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.
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 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.
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.)
|
|
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
|
|
|
|
|
|
Implementation of user-own coding module and setup of the system configuration file
|
|
|
|
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.
|
|
|
Time precision (see Note)
|
|
|
|
0.64 
s
|
|
|
2.56 
s
|
|
|
10.24 
s
|
|
|
40.96 
s
|
|
|
|
0.32 
s
|
|
|
1.28 
s
|
|
|
5.12 
s
|
|
|
20.48 
s
|
Note Precision of time = __RIUSR_trcSW_base_time
2 ) __RIUSR_trcSW_init_tmr (Initialization function)
|
|
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.
|
|
|
|
Registers which do not need to guarantee
|
R1, R2, R3, R4, R5, R6, R7, R14, R15
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
3 ) __RIUSR_trcSW_read_cnt (Function to get time-stamp)
|
|
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.
|
|
|
|
Registers which do not need to guarantee
|
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
4 ) Interrupt handler (Arbitrary function name)
|
|
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;
};
|
|
|
|
Registers which do not need to guarantee
|
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
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.
|
|
|
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)
|
|
|
|
0.64 
s
|
|
5.12 
s
|
|
|
|
2.56 
s
|
|
20.48 
s
|
|
|
|
10.24 
s
|
|
81.92 
s
|
|
|
|
40.96 
s
|
|
327.68 
s
|
|
|
|
|
0.32 
s
|
|
2.56 
s
|
|
|
|
1.28 
s
|
|
10.24 
s
|
|
|
|
5.12 
s
|
|
40.96 
s
|
|
|
|
20.48 
s
|
|
163.84 
s
|
|
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)
|
|
This function is called-back from vsta_knl service call.
|
|
|
|
Registers which do not need to guarantee
|
R1, R2, R3, R4, R5, R6, R7, R14, R15
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
4 ) __RIUSR_trcLONG_read_cnt (Function to get time-stamp)
|
|
In the sample, this function returns the value of the CMT counter register.
|
|
|
|
Registers which do not need to guarantee
|
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
5 ) Interrupt handler (Arbitrary function name)
|
|
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;
};
|
|
|
|
Registers which do not need to guarantee
|
|
PSW when started (Do not change)
|
I = 0 (Disable all interrupts)
|
|
|
|
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.
|
|
This function updates the current time information managed by RI600V4.
This function should be called from the above interrupt handler.
|
|
|
|
Registers which are not guaranteed
|
|
|
|
I = 0 (Disable all interrupts)
|
|
|
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
|
|
|
Immediately after service call
|
|
Just before returning to application from RI600V4
|
|
|
|
|
When the RI600V4 enters Idling
|
|
When an interrupt handler starts
|
|
When an interrupt handler ends
|
|
When a cyclic handler starts
|
|
When a cyclic handler ends
|
|
When an alarm handler starts
|
|
When an alarm handler ends
|
|
When a task status changes
|
|
Table 15-3 The standard of time after used up the buffers
Event generating frequency
|
|
|
|
|
|
|
5 
s / Event
|
|
|
|
|
10 
s / Event
|
|
|
|
|
50 
s / Event
|
|
|
|
|
100 
s / Event
|
|
|
|
|
500 
s / Event
|
|
|
|
|
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.