JPH02234233A - Event driven type multi-task monitor - Google Patents

Abstract

PURPOSE:To monitor in real time the state of an input port with a simple constitution by giving a supervisor call to a user to keep the user waiting until the designated bit of the input port is set in a designated state. CONSTITUTION:Each signal line of sensors 1 - 16 is divided into two branches. One of these two branches is inputted to an input port and can check the state of the sensor with an input instruction. The other branch is inputted to an OR 10 and the output of the OR 10 is connected to an interruption 0. Thus the interruption 0 is produced when either one of sensors 1 - 16 is turned on. When the device control is carried out while monitoring the input of the sensor, etc., a supervisor call is included in an event driven type multi-task monitor from an application task produced by a user to make the user waiting until the designated bit of a designated input port is set in a designated state. Thus it is not required to set any special circuit in the hardware nor to contrive any process when an interruption is produced in the software.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to an event-driven multi-task monitor, and more particularly to an event-driven multi-task monitor used when controlling equipment while monitoring inputs from sensors and the like. [Common technology] Firstly, the task-driven method of the multi-task monitor has the following features:
Time slice (time division) method and event driven (
There is also an event-driven) method.

The time slice method allows one task to be executed for a certain period of time, and then the next task to be executed for a certain period of time.
Achieve multitasking. On the other hand, in the event-driven method, the C
When a task is recognized by an interrupt to the PU, the task that is currently being executed is made to wait, the task that was waiting for the interrupt is executed, and when the processing of that task is completed, the task that was made to wait is executed again, thereby realizing multitasking. ．． [Prior Art] Conventional event-driven multitasking monitors (hereinafter referred to as monitors) use an interrupt to the CPU as a trigger to check the status of application tasks created by the user and check the status of application tasks that are waiting for the interrupt. By assigning the CPU to the computer, the program was able to perform multitasking.

A conventional event-driven multitask monitor will be described in detail with reference to the drawings.

Figure 4 shows a conventional event-driven multitasking monitor.
It is a flowchart which shows an example of evening.

The event-driven multi-task monitor shown in Figure 4 shows an example in which processes 1 to 16 are assigned to tasks 1 to 8 and executed on a conventional monitor. Suppose that in order to move, it is necessary to wait until sensor 1 is turned on.

At this time, task 1 constantly reads the status of the input port and checks the status of sensor 1, waiting until sensor 1 is turned on.If you select the software, task 1 will monopolize the CPU. , parallel processing of tasks is not achieved.

Therefore, assuming that an interrupt O occurs when sensor 1 is turned on, task 1 sends an "interrupt monitoring request" to the monitor and then enters a standby state so that the monitor can start the next task.

With similar software, after process 2, sensor 2. Processing 3
After sensor 3... After processing 16, wait until sensor 16 is turned on.

FIG. 5 is a circuit diagram for executing tasks 1 to 8 shown in FIG. 4 on a conventional monitor.

The signal line from the sensor 1 to the sensor 16 is branched into two, one of which is input to the input port, and its status can be checked by input commands. The other signal line is connected to the input of the OR element.

Sensor 1 and sensor 2 are input to OR1, and by inputting the output of OR1 to interrupt 0, interrupt O is generated regardless of which sensor is turned on.

Similarly, sensor 3, sensor 4,...sensor 15, and sensor 16 are input to OR2,...OR8, respectively.

The outputs of OR2, . . ., the output of OR8 are input to interrupt 1, . . ., interrupt 7, respectively. FIG. 6 is a flow chart showing apparent operations when tasks 1 to 8 shown in FIG. 4 are executed on a conventional monitor on a CPU without connecting the circuit shown in FIG. 5.

It is assumed that task 1 is set to start at the start of execution.

While task 1 is executing process 1, the CPU is monopolized by task 1, so the monitor waits for process 1 to end.

When task 1 finishes processing 1, [Interrupt O monitoring request]
is generated and the monitor is returned to the CPU.

Upon receiving the request, the monitor places task 1 in a standby state and activates task 2. Similar processing is repeated, and task i uses sensor 2 during processing j.
When turned on and an interrupt occurs, the monitor causes task 1 to continue after processing j is completed and task i is placed on standby.

Task 1 checks the status of the input port, and since sensor 1 is not on, it issues an "interrupt O monitoring request" again.
Return the monitor to the CPU.

[Problem to be solved by the invention]

The conventional event-driven multitasking monitor described above uses the occurrence of an interrupt to the CPU as a trigger for switching tasks. Therefore, when controlling devices with a large number of input points, it is necessary to use hardware to connect multiple inputs to a single interrupt. The drawback was that it required a special circuit to be built and software to handle interrupts when they occurred.

Furthermore, since one interrupt cannot be received by multiple tasks at the same time, there is a drawback that as many interrupts as the number of tasks are required.

[Means to solve the problem]

The event-driven multitasking monitor of the present invention includes an interval timer and a supervisor call that requests the event-driven multitasking monitor from an application task created by the user to wait until a specified bit of a specified input port reaches a specified state. It consists of:

〔Example〕

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

FIG. 1 is a flowchart showing one embodiment of the present invention.

The event-driven multi-task monitor shown in FIG. 1 shows a case where processes 1 to 16 are assigned to tasks 1 to 8 for execution, and task 1 is executed after process 1 is completed but before moving on to the next process. , by requesting the monitor using the input port of sensor 1 and the bit position at the input port and a supervisor call to wait until the input port becomes ON.
Wait until sensor 1 turns on.

Similarly, process 2. After processing 3, ... processing 16,
Wait until sensor 2, sensor 3, . . . sensor 16 is turned on.

FIG. 2 is a circuit diagram in which tasks 1 to 8 shown in FIG. 1 are to be executed by the monitor of the present invention.

The signal lines from [sensor] to 16 are branched into two, one of which is input to the input port, and the state of the sensor can be seen by input commands.

The other is input to ORIO. The output of ORIO is connected to interrupt 0, and even if any of the sensors 1 to 16 is turned on, interrupt 0 is generated.

Figure 3 shows the first CPU connected to the circuit shown in Figure 2.
2 is a flowchart showing the apparent operation of the monitor when tasks 1 to 8 shown in the figure are executed.

The monitor starts task 1 first.

While task 1 is executing process 1, the CPU is waiting for the monitor to return.

When task 1 completes processing 1, it issues a "sensor 1 on wait request" to the monitor and returns the CPU to the monitor. The monitor puts task 1 into a standby state and activates task 2.

When the same process is repeated and sensor 2 is turned on while task i is executing the process and interrupt O occurs, task i returns the CPU to the monitor after process j is completed, the monitor makes task i wait, and then the monitor It looks at the state of the human port and determines whether the designated bits of the port for which monitoring is requested are in the designated state, and if none of the bits are in the designated state, it starts the next task.

Next, when sensor 1 is turned on and interrupt 0 occurs, the monitor looks at the bad condition of the input port when the right to use the CPU is handed over, and since it matches the request condition of task 1, task 1
Start.

〔Effect of the invention〕

The event-driven multitasking monitor of the present invention provides the user with a supervisor call that waits until a specified bit of a specified input port becomes a specified state.
without creating corresponding processing software.
This has the effect of allowing the status of the input port to be monitored in real time.

Fig. 2 is a circuit diagram for executing tasks 1 to 8 shown in Fig. 1 on the monitor of the present invention, and Fig. 3 is a circuit diagram for executing tasks 1 to 8 shown in Fig. 1 on a CPU connected to the circuit shown in Fig. 2. FIG. 4 is a flowchart showing an example of a conventional example, and FIG. 5 shows how tasks 1 to 8 shown in FIG. The circuit diagram for execution on a monitor, Figure 6, shows the apparent operation when tasks 1 to 8 shown in Figure 4 are executed on a conventional monitor on a CPU connected to the circuit shown in Figure 5. FIG.

1 to 16...Sensor, OR1 to OR8, ORIO......Order circuit.

Agent Patent Attorney Uchihara Buy

[Brief explanation of the drawing]

FIG. 1 is a flowchart showing an embodiment of the present invention. evening country y Otokuni

Claims (1)

[Claims] Event-driven multitasking characterized by including an interval timer and a supervisor call that requests an event-driven multitasking monitor from an application task created by a user to wait until a specified bit of a specified input port reaches a specified state. monitor.