JP2010039695A - Multitask operating system and debugging device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To measure time or fraction of a task state of each task operating on a multitask OS without imposing any labor on an operator, and to statistically and graphically display a result. <P>SOLUTION: A real time operating system includes a dispatcher being a mechanism for performing dispatch to switch a task to be executed by a processor, the dispatcher which detects the state change of the task in performing the dispatch. When detecting the state change of the task, the dispatcher calls a subroutine for managing the task state of each of the plurality of tasks in a prescribed storage region, and changes the state of the task to the changed state. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a multitask operating system and a debugging apparatus that can arbitrarily acquire and display trace information related to a plurality of task states with a simple operation.

  Conventionally, in the debugging work of application software that runs on a multitasking operating system (hereinafter referred to as a multitasking OS) or an embedded system that uses a multitasking OS, whether each task is operating as designed. The operator acquires the task state for each task from the trace information held in the multitasking OS and verifies whether it is operating efficiently.

For example, the operator inputs the address and task number where the task status in the program is stored, and when the address is written, the task status is acquired and displayed, or the task can set the allowable stop time. Technology that supports debugging work by displaying each stop cause when it exceeds the limit, or detecting whether the specified task is in the specified state over the time set by the operator is known. It has been.
Japanese Patent Application Laid-Open No. 60-037043 JP 9-179754 A JP 2000-215084 A

  However, in the prior art as described above, when an operator sets a task to be verified, a task state, a condition for detection, etc., various operations by the operator are required, and when monitoring a task stop state, Only the execution state and the stop state can be evaluated.

  Therefore, it was impossible to verify what state the task being traced was and whether the state of the plurality of tasks in the entire operation was efficient as the overall operation balance.

  Therefore, the object of the present invention is to measure the time and ratio of task state for each task in application software running on the multitasking OS and the embedded system using the multitasking OS without taking the effort of the operator, The result is statistical and graphical display so that the system can be easily evaluated.

  In order to solve the above-described problem, the real-time operating system is a mechanism for realizing dispatch for switching a task to be executed by a processor, and includes a dispatcher for detecting a state change of the task at the time of the dispatch. When a change in the state of the task is detected, a subroutine for managing the task state of each of the plurality of tasks in a predetermined storage area is called to change the state of the task to the changed state.

  In addition, a debugger capable of memory access to a predetermined storage area of a target, and a plurality of tasks stored in the predetermined storage area by causing the debugger to perform memory access according to an operation of acquiring a trace by an operator Trace information related to the state change is acquired, and the computer is caused to function as an analyzer that creates a display screen that statistically and graphically represents the state change for each task using the trace information.

  With a task program of an embedded system using a multitask OS, it is possible to acquire and display information related to the task status of each of a plurality of tasks without the operator's effort.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

The state of tasks managed in a multitasking operating system (hereinafter referred to as multitasking OS) is large.
RUN state (execution state): State processed by the processor State other than execution: State not processed by the processor

Furthermore, as a state other than this execution,
-READY state (executable state): a state where it can be executed anytime-WAITING state (waiting state): a state where it has been stopped for a certain period of time-WAITING-SUPEND state (double waiting state): WAITING state and SUSPEND state State that satisfies two waiting conditions: SUSPEND state (forced wait state): state that is forcibly waited by another task DORMANT state (pause state): a state where execution can be started as a task.

  In this embodiment, each state of a plurality of tasks in the operating multitasking OS is managed in a predetermined storage area (a trace memory described later), and the task state is acquired at the timing when the task state changes. Update from time to time. Focusing on when the task state changes, when the dispatcher is called and when the system call for calling the kernel function is performed, for example, the processing flow shown in FIG. 1 is executed. FIG. 1 is a diagram illustrating a processing flow according to a change in the state of a task.

  In FIG. 1, when a task dispatcher is generated and called (a), it is checked whether there is a change in the task state in the dispatcher (b). On the other hand, when a system call is called (c), it is checked whether there is a change in the task state in the system call (d).

  When a change is detected in the task state, the process jumps to a subroutine provided for notifying the change of the task state (e). In the task status change notification subroutine, data such as task status and system time for each task is buffered (f). Then, the buffered data is acquired via an emulator that emulates the target processor, and the data is analyzed and statistical information is displayed on the debug device, and a graph is displayed based on the results (g). As the emulator, for example, ICE (registered trademark) (InCircuit Emulator) or the like is used.

  Such processing is performed in cooperation with the multitasking OS and the debugging device in the application software using the multitasking OS or the embedded system using the multitasking OS in association with the task status for each task.

  FIG. 2 is a block diagram illustrating a configuration example of an embedded system that realizes a development environment. An embedded system 10 shown in FIG. 2 includes a processor 1, an input device 2, a monitor 3, a memory 4, and a debug device 5, and are connected to each other via a bus. The processor 1 reads the program code from the memory 4 and controls the entire embedded system 10. The input device 2 causes the operator to select whether to acquire a task state for each task. The monitor 3 displays statistical information or a graph from the data analyzed by the debugging device 5. The memory 4 stores a multitask OS, a task program, etc., and is read out and executed by the processor 1. The debug device 5 analyzes the trace information buffered by the multitask OS, and acquires the task state for each task.

  FIG. 3 is a block diagram illustrating a configuration example of the debugging device. In FIG. 3, the debugging device 5 functions as a language tool 21, a load module file 22, an integrated development environment (IDE) 23, an analyzer 24, a RIM (RTOS Interface Module) 25, and a debugger 26. These programs are read into the memory 4 and executed by the processor 1.

  The language tool 21 is provided with an RTOS (Real Time Operating System) 7a operating as a multitasking OS, a debug module 7b for verifying the target 1a, and a user application 7c incorporated in the target 1a. Then, a load module file 22 as a data processing program is created. The reason why the RTOS 7a is used is that, in the embedded system 10 that realizes the development environment in this embodiment, for example, the operating system (OS) needs to perform processing when the operator presses a button, and therefore the RTOS 7a is used.

  The load module file 22 is given to an integrated development environment (IDE) 23 for proceeding with development processing. Inside the IDE 23, an analyzer 24 and a debugger 26 are provided, and an RTOS interface module (RIM) 25 is provided between them. The analyzer 24 and the RIM 25 are connected by an RTOS access interface (RIF) 8a. The RIM 25 and the debugger 26 are connected by a target access interface (TIF) 8b. The analyzer 24, RIM 25, and debugger 226 are provided as DLL (Dynamic Link Library) files, for example. The debugger 26 can access the trace memory 7d in the target 1a via the ICE 6 by a memory access unit provided in the debugger 26.

  The target 1a is, for example, a processor under development, and includes a program area and a user memory area for storing an RTOS 7a, a debug module 7b, a user application 7c, a trace memory 7d, etc. in the memory 9 provided in the target 1a. ing. The target 1a is connected to the ICE 6 through a predetermined interface, and the ICE 6 is further connected to the embedded system 1 through a predetermined interface to communicate with the debugger 26.

  Next, a sequence flow for the debug device 5 to initialize the trace memory 7d of the target 1a in response to a trace start request from the operator will be described. FIG. 4 is a diagram showing a sequence flow for initializing the trace memory.

  In FIG. 4, when a trace start request is generated by an operator selecting a trace start button 32 from the screen 31 displayed on the monitor 3 by the analyzer 24 using the input device 2, the analyzer 24 displays the user memory area of the target 1 a. In order to read out task information and the like in memory, a memory reference request is issued to the RIM 25 (S1). In response to the memory reference request, the RIM 25 gives an instruction to read the contents of the memory 9 to the debugger 26 (S2), and the memory 9 of the target 1a is controlled from the debugger 26 via the ICE 6 by the memory access unit, task information, etc. In order to read the data, a data read access to the memory 9 is performed (S3).

  The contents of the read memory 9, that is, data such as task information, are notified to the debugger 26 by the ICE 6 via the memory access unit (S4), and from the debugger 26 to the RIM 25 (S5). Data such as task information required by the analyzer 24 is notified to the analyzer 24 by the RIM 25 (S6), and acquisition of data such as task information stored in the memory 9 of the target 1a is completed.

  The analyzer 24 makes a memory write request to the RIM 25 in order to write the acquired data such as task information as initialization information in the trace memory 7d of the target 1a (S7). The RIM 25 gives an instruction to write initialization information to the trace memory 7d to the debugger 26 (S8), and the data access to the trace memory 7d of the target 1a is performed from the debugger 26 via the ICE 6 by the memory access unit. 7d initialization is completed. In the initialization information written in the trace memory 7d, a task ID for identifying each of a plurality of tasks and a task state at the start of tracing are shown in correspondence with each other.

  When the initialization information is set in the trace memory 7d, during the trace, the task state changed every time the dispatcher or system call shown in FIG. 1 is called is stored in the trace memory 7d, and the task information is sequentially updated. The contents of the trace memory 7d are read out by a trace acquisition request, and are processed and displayed on the screen 31 in the graph display 34.

  FIG. 5 is a diagram showing a sequence flow for acquiring a trace after the trace is started. In FIG. 5, when a trace acquisition request is generated by the operator selecting the trace acquisition button 33 from the screen 31 displayed on the monitor 3 by the analyzer 24 using the input device 2, the analyzer 24 displays the user memory area of the target 1a. In order to read out the contents of the trace memory 9 in (1), the RIM 25 is requested to acquire a trace log (S11).

  Then, an instruction to read the contents of the trace memory 7d is given to the debugger 26 by the RIM 25 (S12), and the data is read from the memory 9 to read the contents of the trace memory 7d of the target 1a from the debugger 26 via the ICE 6 by the memory access unit. Access is made (S13).

  The content of the read trace memory 7d, that is, the trace information is notified to the debugger 26 by the memory access unit via the ICE 6 (S14), and is notified from the debugger 26 to the RIM 25 (S15). Then, the RIM 25 notifies the analyzer 24 of the trace information required by the analyzer 24 (S16), and the acquisition of the trace information stored in the trace memory 7d of the target 1a is completed.

  Next, various processes provided by the RTOS 7a of the target 1a will be described. FIG. 6 is a flowchart of the dispatcher process. The dispatcher process shown in FIG. 6 corresponds to (a), (b), and (e) of FIG. In FIG. 6, a task dispatcher is generated, the dispatcher is called, and the process moves to the dispatcher that performs the dispatch process (S21). It is checked whether or not the task state changes in the dispatcher (S22). If the task state has changed, a task change notification subroutine is called (S23). On the other hand, if the task state does not change, the process is terminated without calling a task change notification subroutine. The dispatcher notifies the task ID and task status of the task before switching and the task ID and task status of the task after switching when calling a subroutine for task change notification.

  FIG. 7 is a flowchart of the system call process. The system call process shown in FIG. 7 corresponds to (c), (d), and (e) in FIG. In FIG. 7, when a system call is called (S31), it is checked whether or not the state of the task changes in the system call (S32). A subroutine is called (S33). On the other hand, if the task state does not change, the process is terminated without calling a task change notification subroutine. The system call notifies the task ID and task state of the task to be processed when calling a task change notification subroutine.

  FIG. 8 is a flowchart of processing performed by the task status notification subroutine. The processing by the subroutine shown in FIG. 8 corresponds to (e), (f), and (g) in FIG. In FIG. 8, when dispatch occurs or when a system call is called and when the task state is changed, a task state change notification subroutine is called, and the process proceeds to the subroutine (S40).

  The subroutine for task state change notification refers to the trace memory 7d and calculates the elapsed time of the task state before the change from the task state before the change corresponding to the task ID notified when the task is called and the system time. The calculated time is buffered in the trace memory 7d as the accumulated time of the task state (S41). Further, the task state notified at the time of calling is buffered in the trace memory 7d in association with the task ID together with the current system time as the changed task state (S42). Then, the processing in the subroutine ends.

  By configuring the subroutine for task status notification as described above to be called from the system call and dispatcher, it is possible to save and manage task status changes in the trace memory 7d as needed. Such a subroutine may be provided in the RTOS 7a, or may be provided in a library in which a function call can be made from a system call and a dispatcher, for example. In addition, since the state changes of a plurality of tasks are sequentially managed by the above-described subroutine, trace information indicating the current states of the plurality of tasks from the start of the trace is provided in response to a trace acquisition request from the analyzer 24. It becomes possible.

  FIG. 9 is a diagram illustrating an example of trace information stored in the trace memory. In FIG. 9, the trace information stored in the trace memory 7d includes the current task state, the system time when the task state is changed, the accumulated time of the RUN state, and the accumulated time of the READY state in association with the task ID. , WAITING state accumulation time, WAITING-SUSPEND state accumulation time, SUSPEND state accumulation time, DORMANT state accumulation time, and the like.

  For example, as trace information, the current task state “READY”, the system time “20” when the task state is changed, the accumulated time “10” of the RUN state, and the READY state are associated with the task ID “IDLE”. Item values are stored such as accumulated time “90”, accumulated time “0” in the WAITING state, accumulated time “0” in the WAITING-SUSPEND state, accumulated time “0” in the SUSPEND state, and accumulated time “0” in the DORMANT state. Is done.

  The trace information shows a case where tasks exist as task IDs “TASK-1”, “TASK-2”, and “TASK-3”. Accordingly, in association with the task ID “TASK-1”, the current task state “RUN”, the system time “80” when the task state is changed, the accumulated time “50” of the RUN state, and the accumulated time of the READY state Item values are stored such as “20”, WAITING state cumulative time “10”, WAITING-SUSPEND state cumulative time “0”, SUSPEND state cumulative time “0”, and DORMANT state cumulative time “20”. .

  Further, in association with the task ID “TASK-2”, the current task state “READY”, the system time “50” when the task state is changed, the RUN state accumulated time “0”, and the READY state accumulated time. Item values are stored such as “50”, WAITING state cumulative time “40”, WAITING-SUSPEND state cumulative time “0”, SUSPEND state cumulative time “0”, and DORMANT state cumulative time “10”. .

  Further, in correspondence with the task ID “TASK-3”, the current task state “READY”, the system time “50” when the task state is changed, the accumulated time “10” of the RUN state, and the accumulated time of the READY state Item values are stored such as “10”, WAITING state cumulative time “10”, WAITING-SUSPEND state cumulative time “10”, SUSPEND state cumulative time “10”, and DORMANT state cumulative time “50”. .

  FIG. 10 is a diagram illustrating a graph display example of the trace information displayed by the analyzer. In FIG. 10, when the analyzer 24 acquires the trace information as shown in FIG. 9 from the trace memory 7d of the target 1a by the sequence shown in FIG. 5, each of the tasks from the start of the trace for each task indicated by the trace information to the acquisition of the trace. A task state ratio is calculated based on the task state accumulated time, and a display screen such as a graph display 34 is created and displayed on the monitor 3.

  In the graph display 34, trace information of a plurality of tasks is shown, and the calculated task state ratio shown in the graph and the accumulated time of each task state are shown in correspondence with the task ID of each task. The task state includes a RUN state, a READY state, a WAITING state, a WAITING-SUSPEND state, a SUSPEND state, and a DORMANT state according to the accumulated time items of the task state of the trace information in the trace memory 7d shown in FIG. , Each accumulated time is indicated.

  The operator who verifies the target 1a can arbitrarily acquire trace information related to the states of a plurality of tasks with a simple operation without operating each task. Further, the overall operation status of the user application 7b under development can be verified by the graph display 34 showing the states of a plurality of tasks. For example, since the READY state of the task “TASK-2” shows a higher rate of 50% than 20% of the other tasks “TASK-1” and 10% of “TASK-3”, the task is caused by some factor. Since the execution of “TASK-2” may be postponed, performance improvement can be expected by optimizing the program.

Regarding the above description, the following items are further disclosed.
(Appendix 1)
A mechanism that implements a dispatch for switching a task to be executed by a processor, and has a dispatcher that detects a state change of the task at the time of the dispatch
When the dispatcher detects a change in the state of the task, the dispatcher calls a subroutine for managing the task state of each of the plurality of tasks in a predetermined storage area, and changes the state of the task to the changed state. system.
(Appendix 2)
The subroutine called in the dispatcher performs a function to buffer the changed task state and the time when the task state is changed in correspondence with the task ID of the task in the predetermined storage area. The real time operating system according to appendix 1, wherein the state of the plurality of tasks is managed in units of tasks in the storage area.
(Appendix 3)
A mechanism used to call a kernel function, and has a system call that detects a change in the state of a task executed by the processor when called.
The real-time operating system according to claim 1, wherein when the system call detects a change in the state of the task, the subroutine is called to change the state of the task to a state after the change.
(Appendix 4)
A function for buffering the task state changed by the subroutine called in the system call and the time when the task state changed in the predetermined storage area in correspondence with the task ID of the task; 4. The real time operating system according to appendix 3, wherein the state of the plurality of tasks is managed in units of tasks in the storage area by being executed.
(Appendix 5)
The subroutine obtains the previous time when the state of the task stored in association with the task ID is changed from the predetermined storage area, calculates the accumulated time of the state, and uses the calculated value. The real time operating system according to appendix 2 or 4, wherein the accumulated time of the state corresponding to the task ID in the predetermined storage area is updated.
(Appendix 6)
The subroutine manages the accumulated time of a plurality of states for each task in the predetermined storage area, and the plurality of states include an executable state, a waiting state, a double waiting state, a stopped state, and a dormant state. The real time operating system according to any one of appendices 1 to 6.
(Appendix 7)
A debugger capable of memory access to a predetermined storage area of the target;
Trace information relating to a state change of a plurality of tasks stored in the predetermined storage area is acquired by causing the debugger to perform memory access in accordance with an operation of acquiring a trace by an operator, and each task is acquired using the trace information. A debugging device that allows a computer to function as an analyzer that creates a display screen that statistically and graphically represents changes in the state of a computer.
(Appendix 8)
8. The debugging device according to appendix 7, wherein the analyzer generates, for each task, the accumulated time of each of a plurality of states as statistical information, and creates the display screen in which the ratio of the accumulated time of each state to the total accumulated time is displayed in a graph. .
(Appendix 9)
The analyzer causes the debugger to read task information stored in the target user memory area in response to an operation of starting trace by the operator, and uses the task information to initialize the predetermined storage area to the debugger. The debugging device according to appendix 8, which is set.
(Appendix 10)
The debugging device according to appendix 9, wherein the task information includes a task ID for identifying each of the plurality of tasks and a current state of the task.
(Appendix 11)
The debugging device according to any one of appendices 8 to 10, wherein the plurality of states include an executable state, a wait state, a double wait state, a stop state, and a dormant state.

  The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of the claims.

It is a figure which shows the processing flow according to the change of the state of a task. It is a block diagram which shows the structural example of the embedded system which implement | achieves a development environment. It is a block diagram which shows the structural example of a debugging apparatus. It is a figure which shows the sequence flow for initializing a trace memory. It is a figure which shows the sequence flow which acquires a trace after a trace start. It is a flowchart figure of a dispatcher process. It is a flowchart figure of a system call process. It is a flowchart figure of the process which the subroutine for task state notification performs. It is a figure which shows the example of the trace information stored in a trace memory. It is a figure which shows the example of a graph display of the trace information displayed by an analyzer.

Explanation of symbols

1 processor 1a target 2 input device 3 monitor 4 memory 5 debug device 6 ICE
7a RTOS
7b Debug module 7c User application 9 Memory 10 Embedded system 21 Language tool 22 Load module 23 IDE
24 analyzer 25 RIM
26 Debugger

Claims (10)

A mechanism that implements a dispatch for switching a task to be executed by a processor, and has a dispatcher that detects a state change of the task at the time of the dispatch
When the dispatcher detects a change in the state of the task, the dispatcher calls a subroutine for managing the task state of each of the plurality of tasks in a predetermined storage area, and changes the state of the task to the changed state. system.   The subroutine called in the dispatcher performs a function to buffer the changed task state and the time when the task state is changed in correspondence with the task ID of the task in the predetermined storage area. The real time operating system according to claim 1, wherein the state of the plurality of tasks is managed in units of tasks in the storage area. A mechanism used to call a kernel function, and has a system call that detects a change in the state of a task executed by the processor when called.
2. The real time operating system according to claim 1, wherein when the system call detects a change in the state of the task, the system call calls the subroutine to change the state of the task to a state after the change.   A function for buffering the task state changed by the subroutine called in the system call and the time when the task state changed in the predetermined storage area in correspondence with the task ID of the task; 4. The real time operating system according to claim 3, wherein the state of the plurality of tasks is managed in the storage area in units of tasks by being executed.   The subroutine obtains the previous time when the state of the task stored in association with the task ID is changed from the predetermined storage area, calculates the accumulated time of the state, and uses the calculated value. 5. The real time operating system according to claim 2, wherein the accumulated time of the state corresponding to the task ID in the predetermined storage area is updated.   6. The accumulated time of a plurality of states is managed for each task in the predetermined storage area by the subroutine, and the plurality of states include states such as an execution state, an executable state, and a wait state. A real time operating system according to any one of the preceding claims. A debugger capable of memory access to a predetermined storage area of the target;
Trace information relating to a state change of a plurality of tasks stored in the predetermined storage area is acquired by causing the debugger to perform memory access in accordance with an operation of acquiring a trace by an operator, and each task is acquired using the trace information. A debugging device that causes a computer to function as an analyzer that creates a display screen that statistically represents changes in the state of a computer.   8. The debugging according to claim 7, wherein the analyzer generates, for each task, the display screen that shows a cumulative time of each of a plurality of states as statistical information, and displays a graph of a ratio of the cumulative time of each state to the total cumulative time. apparatus.   The analyzer causes the debugger to read task information stored in the target user memory area in response to an operation of starting trace by the operator, and uses the task information to initialize the predetermined storage area to the debugger. The debugging device according to claim 8 to be set.   The debugging device according to claim 9, wherein the task information includes a task ID for identifying each of the plurality of tasks and a current state of the task.

Images