JPH0327451A - Real time operating system - Google Patents

Abstract

PURPOSE:To debug the original motion of a task by making the control of a debugger task to be independent of multi-task control by means of the priority relation of a general application task. CONSTITUTION:When a real time operating system (OS) 1 receives a system call for starting the debugger task 7, the execution environment of the application task 8 is saved in a recording area which an executing pointer 20 designates, then, a request discrimination part 3 inputs it to a debugger task driving part 4. In the debugger task driving part 4, a debugger executing pointer 40 is acquired in spite of priority, and execution environment is restored from task control block (TCB) 41 of the debugger task 7 and control is shifted to the debugger task 7. Thus, control is shifted to the debugger task without conditions. Thus, the motion of the application task is prevented from stopping since the scheduling of the application task is independently continued via the request discrimination part 3 even while executing the debugger task.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of Industrial Application The present invention is applicable to real-time operating systems (O
S) This relates to a real-time OS that separates the underlying debugger processing and task control.

BACKGROUND OF THE INVENTION Conventionally, tasks managed by a real-time OS have been executed based on priority relationships. These task groups often malfunction in the initial stage of creation, and a program that investigates the cause of malfunctions at this stage while the real-time OS is running is called a devanoga program.

2 8-7 The debugger program must be controllable by the real-time OS. Therefore, debugger programs are generally created and registered as tasks rather than handlers.

Problems to be Solved by the Invention However, in the conventional method, the debugger task itself was included in the group of tasks to be debugged, and there was a problem that the original movement of the task could not be completely debugged. .

Therefore, it is an object of the present invention to enable debasogging of the original movement of a task.

Means for solving the problem In order to achieve the above purpose, the debugger program is a task that transitions according to rules independent of the task state transition rules under the real-time OS, and the real-time core is equipped with a part that drives the task. be.

Effect of the present invention In the above-mentioned structure, when the real-time OS receives a request to start a debugger task from an application task (that is, a task other than Debanogata 3 Base/Screen) or an interrupt handler, it interprets the request,
The debugger task driver unconditionally transfers control to the execution of the debugger task without scheduling the application task.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, referring to the drawings, there will be shown a block diagram of an S according to an embodiment of the present invention. In the figure, 1 is the real-time OS that manages tasks, and 3 is the system call (request) from the task.
4 is a debugger task driving unit for starting or stopping the debugger task;
8 is an execution environment recovery unit that recovers the task execution environment; 8 is an application task that issues a task startup request;
10 is an application task to be started, 9 is an interrupt processing handler that issues a start request by key human power, etc.;
Reference numeral 7 indicates a debugger task that operates upon receiving a startup request from the application side, 20 a pointer pointing to the application task being executed, and 40 a pointer pointing to the debugger task being executed.

The operation of the above configuration will be explained below.

The figure shows the behavior of the real-time OS when starting the devasoga task 7 from the application task 8 or the interrupt processing handler 9.
is application task 8 or interrupt handler 9
When a system call (=request) is received to start application task 10 from
The execution environment of the application task 8 is saved in the TCB) 21, and control is switched to the application task 10 according to the priority of the task using the schedule -y'5. This is the processing flow of a general real-time OS.

On the other hand, real-time OSI is application task 8
Alternatively, when a system call to start the debugger task 7 is received from the interrupt handler 9, the execution environment of the application 5'\1/ task 8 is saved in the recording area pointed to by the running pointer 20, but after that, the request determination unit 3
As a result, the debugger task driver 4 is entered.

A debugger task driving unit 4 acquires a debugger execution pointer 40 regardless of the priority, an execution environment unit 6 recovers the execution environment from the TCB 41 of the debugger task 7, and transfers control to the debugger task 7.

Through this process, no matter what kind of control processing is being performed on the application task group, if there is a request (system call) to start the debugger task, control will be given to the debugger task unconditionally (regardless of the priority of the task). will move. Further, even during execution of the debugger task, the scheduling of the application task is continued independently via the request determination unit 3, so the operation of the application task is not stopped.

Effects of the Invention As described above, the effect of the present invention is that the control of debugger tasks can be made independent of multitask control based on the priority relationship of general application tasks, and the effect as a real-time OS is 6... .

FIG. 2 is a block diagram of an OS.

Claims (1)

[Claims] A real-time operating system comprising at least a debugger task, and a debugger task drive section and a drive request determination section provided in a real-time core.