JP2000066904A - Multitask control method and storage medium - Google Patents

Abstract

(57) [Summary] [PROBLEMS] In multitask control for controlling an application program including a plurality of tasks, it is possible to have the same interface specification on all platforms and perform the same operation by an application. A common part (103) includes an application (10).
1 performs scheduling related to the execution of the plurality of application tasks 102 and issues a task control instruction such as a task suspending process or a task resuming process to the model-dependent portion 10.
Issue to 6. The model dependent part 106 is the common part 103
The task is controlled based on the issued task control instruction. Here, if the operating environment of the application is on the actual MPU, the task suspending function 109 and the resuming function 110 directly rewrite the contents of the task control block. On the other hand, if the operating environment is on a general-purpose OS, the task is controlled using a system call supported by the general-purpose OS.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a multitask control method and a storage medium capable of performing multitask processing.

[0002]

2. Description of the Related Art Generally, a real-time OS (hereinafter, referred to as RT)
OS), there is an RTOS simulation development environment for simulating an RTOS running on a real machine on a general-purpose development machine such as a workstation or a PC.

These RTOS simulation environments include (1) a stub for RTOS system calls and a unit test for each application task performed on a development machine, and (2) a simulator for simulating the operation of a target MPU. (3) modify the hardware-dependent part of the target RTOS and convert it to a general-purpose machine OS (U
There are those that use a multi-thread mechanism provided by NIX or Windows to realize application tasks as threads.

In particular, the methods (2) and (3) are made to have almost the same function interface as the RTOS on the actual machine. As a result, it is possible to operate an application program that is substantially the same as that of the actual machine on the RTOS simulator.

[0005] As a debug environment for an RTOS application, a source level debugger that operates on the development machine by connecting the development machine to the real machine on the actual machine via an ICE or ROM emulator or by remote debugging is used. What is used is common. As a debug environment for an RTOS simulator operated on a development machine, in the case of the above (2), the MPU simulator usually includes a source-level debugger such as a machine language or C language. Regarding the above (1) and (3), debugging / testing can be performed using a native source level debugger operated on a development machine.

However, in debugging an RTOS application, it is not always possible to effectively perform a debugging style in which the use of these source-level debuggers causes a break to temporarily suspend the operation of the application or perform step execution. That is, in such an application that requires real-time properties, the reproducibility of the application is lost at the moment when the program is stopped.

For this reason, in recent years, the history of system calls and task switches is recorded without stopping the application program, and the information is then taken out and displayed graphically on a development machine.
A tool (hereinafter, referred to as a task switch viewer) capable of analyzing whether the movement of an application task is as intended has been developed and started to spread.

Further, a system which employs a dynamic loading method, such as the "real-time simulation development mechanism" of Japanese Patent Application Laid-Open No. 5-282160, is intended to operate an application in a real machine and a simulation development environment without any change. Also exists.

[0009]

However, in the above method (1), only the behavior of each task is confirmed, and a test relating to synchronization and communication between tasks cannot be performed. In addition, the method (2) has a problem that the execution speed is low, so that there is no real-time property in a test of a large-scale application, and a problem in efficiency. On the other hand, the method (3) is relatively easy to realize a simulation development environment,
In terms of execution speed, it is said to be the closest to the actual machine. However, the method (3) has the following problems with respect to the behavior of the application and the debug environment.

[0010] Application behavior between platforms is different: In a conventional RTOS, the same application runs exactly the same between an RTOS running on a real machine and an RTOS simulator running on a general-purpose OS of a development computer. Is not guaranteed to do so. It is a general-purpose OS (U
This is because a multi-thread mechanism provided by NIX or Windows is used as it is to realize a synchronization / communication function between tasks (threads). That is,
In the multi-thread mechanism provided by the general-purpose OS, the scheduling is performed on the general-purpose OS. Therefore, there is a possibility that the result of the scheduling may change due to the influence of access to other processes and peripheral devices running simultaneously.

[0011] The problem of porting between platforms: A similar problem, a general-purpose OS that runs an RTOS simulator
Is changed (for example, from UNIX to Windows
Since the interface specifications and operations of the multithread mechanism provided by each general-purpose OS are different, it is difficult to ensure the reproducibility of the operation of the application even between OS simulators. Further, since the multi-thread mechanism API provided by the general-purpose OS is scattered in the simulator program, porting (porting) is not easy.

Difficulty acquiring debug information (trace information): When a debug device such as a task switch viewer is used on the actual device, the trace information is extracted and recorded in a portion of the actual device that performs a task switch of the RTOS. A function is added, and the recorded information is transmitted by some method (physical communication means prepared in the actual device: for example, serial (= serial communication; one of bit-based communication methods represented by RS-232C, etc.)) It is sufficient to provide a mechanism for extracting data to an external display device (such as a task switch / viewer) by using a socket or a socket (an API for using a TCP / IP network). However, when the thread synchronization / communication mechanism of the general-purpose OS is used in the RTOS simulator, the thread context switch (that is, the task switch) is performed on the general-purpose OS. It is necessary to enter the inside of the general-purpose OS, which is very difficult. Therefore, it is not easy to collect trace information of the RTOS simulator.

Japanese Patent Application Laid-Open No. 5-282160 aims to solve the above problem, but there is no mention of the type of system call used in a general-purpose OS, and task scheduling depends on a general-purpose OS for operating a simulator. I have. Also, there is no mechanism for displaying task switch trace information as described above.

The present invention has been made in view of the above problems, and an object of the present invention is to provide an RTOS structure that has the same interface specifications on all platforms and enables applications to perform the same operations. To provide.

Another object of the present invention is to provide an RT that has the same interface specifications on all platforms and enables an application to perform the same operation.
OS debugging environment (task switch / viewer, etc.)
The object of the present invention is to provide a mechanism that can collect unified debug information on all platforms.

[0016]

According to the present invention, there is provided a multitask control method comprising the following steps. That is, a multi-task control method for controlling an application program including a plurality of tasks, wherein a scheduling step of performing a scheduling related to the execution of the plurality of tasks and issuing a task control instruction is provided. Executing the task in accordance with the operation environment of the application program based on the task control instruction.

Further, according to the present invention, there is provided a storage medium for storing a control program for causing a computer to implement the multitask control method.

[0018]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described below in detail with reference to the accompanying drawings.

[First Embodiment] FIG. 24 is a diagram showing a computer device for providing a program simulation environment according to the first embodiment. Reference numeral 10 denotes a computer device for providing a simulation environment. The computer device 10 includes a CPU 11, a ROM 12, an RA
M13, input device 14, display device 15, external storage device 1
6 which are connected by a bus 17.
The external storage device 16 includes an application 101 to be executed in the actual device 20 and a common part 103 of the RTOS.
And the general-purpose OS-dependent portion 106a of the RTOS.

On the other hand, the actual machine 20 is a CPU
1, a ROM 22, a RAM 23, and an I / O interface 24, and controls the control target device 25 based on an application 101 stored in the ROM 22. CPU
Reference numeral 21 denotes a control program (application 101, common part 103 of RTOS, RTO) stored in ROM 22.
By executing the hardware-dependent portion 106b) of S, the control target device 25 is controlled.

FIG. 1 is a basic configuration diagram of the RTOS in the first embodiment. Reference numeral 101 denotes an application to be developed. Reference numeral 102 denotes an application task, and the application 101 is a set of a plurality of application tasks 102. Each application task 102 uses the function of the RTOS by issuing a system call.

Reference numeral 103 denotes a common part of the RTOS including components independent of hardware. 104 is RTO
It is a set of entities of the S system call. R used here
The TOS system call does not include hardware-dependent ones such as a file system and a network interface, and includes general tasks such as task control and inter-task synchronization / communication functions (semaphores, locks, mailboxes, event flags, queues, etc). It is assumed that it does not depend on hardware. After the execution of the system call, the scheduling function 105 reschedules the task switch.

Reference numeral 106 denotes a component group that depends on the hardware / model of the RTOS (hereinafter, referred to as a model-dependent portion). In the model-dependent portion 106, reference numeral 109 denotes a function for interrupting a currently executing task, and reference numeral 110 denotes a function for restarting execution of a task in an interrupted state. A task switch control function 108 switches a running task to another task using the task suspending function 109 and the task resuming function 110. It should be noted that the model-dependent portion 106 is shown in FIG.
4, the generic OS-dependent part 106a and the hardware-dependent part 106b described above are collectively referred to. 111 is MP
U or a general-purpose OS.

When a system call is issued to the RTOS from the application task 102 or the like, the common part 103 executes the system call entity 104.
Is executed, and as a result, when it is necessary to perform rescheduling, the scheduling function 105 is called to perform rescheduling. Task switch control function 10
8 switches the task in response to a request for suspending and resuming the task.

FIG. 2 is a flowchart showing the procedure of processing by the common part from the system call issuance to the task switch. Upon receiving the call of the system call function, a task interruption request is issued to the task switch control function 108 in step S702. Then, in step S703, the system call body 1
Execute 04. The inside of the system call function of the real-time OS is functionally divided into two parts. It controls task execution (task switch: suspends tasks, reschedules, resumes tasks)
Part and system call body part. In other words, system calls include task creation / destruction, message queues,
There are semaphores, pending / post event flags, etc. The part that executes those functions is the "system call" itself, and task execution control (task switching) is performed according to the result of executing the function. . Then, as a result of executing the system call body 104, if scheduling becomes necessary, the process proceeds from step S704 to step S705, in which the scheduling mechanism 105 is called to perform rescheduling. Note that scheduling may not be necessary depending on the type of the system call or the situation. For example, execution of a system call, such as generating a new semaphore or checking the current value of an event flag, does not cause a state change that causes a task switch. In this case, there is no need to call the scheduling mechanism. Conversely, semaphores, post-pending of event flags, and the like cause a state change that causes a task switch. Therefore, scheduling is always performed after executing such a system call. That is, there are system calls that require scheduling and system calls that do not. The determination is made by a flag (scheduling request flag) set in the system call itself. Next, in step S706, a task restart request is issued to the task control function 108, and this processing ends. The task whose execution should be resumed next is determined by the scheduling mechanism in step S705. If there is no need for scheduling,
The previous task is selected. Therefore, step S706
Then, a procedure for restarting the currently selected next execution task is performed.

Various types of scheduling algorithms in the scheduling function 105 can be considered, such as priority order, time sharing, or a combination thereof. For example,
FIG. 3 is a diagram illustrating an example in which a scheduling algorithm in priority order is realized. In this case, the scheduling function 105 holds an execution waiting queue 770. The execution waiting queue 770 holds tasks in the execution waiting state on a list for each priority, and manages the order of the tasks as a FIFO queue as a queue. The first task 774 among the tasks linked to the highest priority execution wait queue 771 is determined as the next execution task.
The scheduling algorithm in FIG. 3 is in priority + waiting order. Executable tasks are arranged in an independent queue (FIFO) for each priority. Among the executable tasks, the task having the highest priority and located at the head of the queue is the next task to be executed. That is, the task at the upper left of FIG. 3 always obtains the execution right (task 1 in FIG. 3). Therefore, the numbers (numbers) in tasks 1 to 7 in FIG. 3 do not indicate the order in which they are executed. When the task being executed (task 1 in the figure) is removed from the executable task group due to a resource wait or the like, the task at the next upper left (task 2 in the figure)
Gets execution right. Further, when a task having a higher priority than the task currently being executed is in an executable state, the task gets the execution right.

As another example, FIG. 4 is a diagram showing an example in which scheduling by time sharing is realized. According to FIG. 4, the scheduling function 105
Holds the execution wait queue 790. The execution queue 790 is managed as a FIFO queue as a queue. If the first task 791 in the execution state has passed for a certain period of time, the task is sent to the end of the queue, the second task 792 in the queue becomes the first task, and the task is determined as the next execution task. in this way,
The tasks waiting to be executed are sequentially switched over according to time. As a scheduling algorithm, a combination of these, a method of determining based on a more complicated calculation formula, and the like are conceivable.

Next, the RT having the above basic configuration
A description will be given of the model-dependent portion 106 for applying the OS to (1) the actual machine and (2) the UNIX workstation, and the scheduling function 105. The common part 103 uses the same program module for both (1) and (2).

(1) RTOS in Real Machine The RTOS according to the present embodiment is operated on a real machine 20 equipped with a Motorola MC68000 as the CPU 21. Model dependent part 106 in FIG.
(Hardware dependent part 10 of RTOS in FIG. 24
The component 6b) will be described. In this embodiment,
A task control block (hereinafter, referred to as TCB) for storing context information (hardware register, program counter, task stack, etc.) specific to the task accessed by the model-dependent portion 106 is created on the memory (RAM 23). . It is assumed that the application task is defined in the initialization file of the RTOS and is statically arranged at the time of compilation.

Task Suspension Function 109: FIG. 5 is a flowchart showing the flow of processing of the task suspension function on the actual machine side. Upon receiving the task suspension request, the task switch control function 108 executes the task suspension function 109. The task suspending function 109 saves context information of the currently executing task in the TCB of the task. Specifically, the value of the program counter stored on the stack is read, and the read value of the program counter, the value of the hardware register, the stack pointer, and the like are written to the TCB of the task (steps S502 and S50).
3). Then, the state of the task in the TCB is set to the suspended state, and the suspension processing is completed (step S50).
4).

Task Resuming Function 110: FIG. 6 is a flowchart showing the flow of processing of the task resuming function 109 on the actual machine side. When the task resuming request is received, the task resuming function 109 first acquires the ID of the task to be resumed from the task resuming request (step S602). And
The state of the task in the TCB of the task corresponding to the acquired task ID is set to “executing” (step S603). Further, the context information of the suspended task is stored in the TC of the task.
Load from B (step S604). In particular,
By reading the values of the hardware register, program counter, and stack pointer stored in the corresponding TCB and setting them in the respective hardware registers, the task can be resumed from the previously suspended state.

Task switch control function 108: Switches the task in the execution state. Specifically, upon receiving the task suspension request, the above-described task suspension function 109 is activated, and the context information of the task that has been in the execution state is stored to be in the suspension state. When a task resumption request is received, the above-described task resumption function 110 is activated, the context information of the next execution task is loaded, and the task in the suspended state is switched to the execution state.

The above (1) to (3) correspond to the model-dependent part 10.
6 are written in assembly language,
At its core is the function of performing context operations such as task switches. The RTOS system call entity 104 and the scheduling function 105 are included in the common part 103.

(2) RT in a simulation environment
OS Next, as an implementation example of the RTOS in the simulation environment, SunOS5. A case will be described in which the simulator of the present RTOS is operated on a workstation equipped with x (x is a number representing a minor version; hereinafter, simply referred to as SunOS). In the following, components of the model-dependent portion 106 in FIG. 1 (a model-dependent portion on the simulation environment side and corresponding to the general-purpose OS-dependent portion 106a in FIG. 24) will be described. In the present embodiment, an application task is operated as a thread in a single process by using a multithread library provided by SunOS.

In SunOS, suspension and resumption of a thread are realized by a system call provided by a library. The application task is generated by a system call in the initialization routine of the main thread.

Task Suspension Function 109: FIG. 7 is a flowchart showing the processing flow of the task suspension function on the simulation machine side. When the task suspension function is executed in response to the task suspension request, the execution of the threaded task is suspended by the thr_suspend () system call provided by the thread library (step S120).
2). Task context information is properly stored by the SunOS. After that, in step S1203, the “task state” in the TCB of the task is set to “interrupted state”.

Task Resume Function 110: FIG. 8 is a flow chart showing the processing flow of the task restart function on the simulation machine side. When the task resuming function is activated by the task resuming request, the task ID of the task whose execution is to be resumed is obtained from the task resuming request (step S130).
2). Next, the “task state” in the TCB of the task whose execution is to be resumed is set to “executing” (step S13).
02). Next, thr_resu provided by the thread library
By the me () system call (using the task ID obtained in step S1302 as an argument), the threaded task in the suspended state can be put into the execution state (step S1304). The context information of the task is Su
The task is properly returned by the nOS, and execution of the specified task can be resumed from the previous interrupt position.

Task switch control function 108: Switches the task in the execution state. Specifically, upon receiving the task suspension request, the task suspension function 109 is activated, and the task (thread) that has been in the execution state is brought into the suspension state. In addition, the task resuming function 110 is activated in response to the task resuming request,
Put the next task (thread) to be executed. As a result, the application tasks that are in the running state are:
Since there is always one in this system (when one task is resumed, one running task is suspended, so
Even if thread scheduling by SunOS occurs, a target task (thread) is always executed. This mechanism allows this RTOS to run on real machines
The tasks are guaranteed to be executed in the same order as.

It should be noted that the above-mentioned is the model-dependent portion 106
Are written in C using the multithread library of SunOS, and the main function is a function for performing a context operation such as a task switch.

As described above, R in the first embodiment is
According to TOS, the parts that depend on the hardware are cut out to the minimum necessary, and the other parts are written in C so that they can be commonly used on various platforms. It has a structure to minimize the influence.

That is, the hardware-dependent parts are a function of interrupting the execution of a task, a function of resuming the execution of the interrupted task, and a function of controlling a task switch using these functions. The program modules that realize these functions need to be rewritten by the target MPU or general-purpose OS.

On the other hand, all other RTOS functional parts, such as task control, inter-task synchronization / communication functions, and task switch scheduling functions, that is, the layers that provide RTOS system calls, are all described in C language. This is a hierarchy that does not depend on the hardware. In this way, the model-dependent part realized by a very limited function such as task context control and the common part realizing the system call body have a completely separated structure, so that the same interface specifications can be used on all platforms. And the application can perform the same operation.

Therefore, according to the first embodiment, the RTOS
The system calls and scheduling functions related to the behavior of the system are diverted as a common part that does not depend on the model, and only the primitive functions that depend on the minimally extracted platform are implemented. Even so, the application can behave the same. In addition, since the number of machine-dependent parts is small and concentrated on a limited part, transplantation can be easily performed.

[Second Embodiment] Hereinafter, a second embodiment will be described in detail. In the second embodiment, in the RTOS described in the first embodiment, a function of dynamically generating / deleting a task is added to the model-dependent portion 106. That is, in the first embodiment, a system in which dynamic generation / deletion of a task is not performed (or need not be performed) is described. In the second embodiment, dynamic generation / deletion of a task can be performed. The expanded system is shown below.

(1) RTOS on Actual Machine As in the first embodiment, an MC680 manufactured by Motorola is used.
It is assumed that the present RTOS is operated with respect to an actual device on which 00 is mounted. FIG. 9 shows the RT on the actual device side according to the second embodiment.
FIG. 2 is a block diagram illustrating a configuration of an OS. RTOS in FIG. 9
Has a configuration in which a task generation function 112b and a task deletion function 113b are added to the basic configuration of the RTOS shown in FIG. Reference numeral 114b denotes a memory (RAM2) for storing task-specific context information (hardware register, program counter, task stack, etc.).
3) The upper region (TCB).

Task generation function 112b: The task generation function 112 generates task context information. Here, the context information of the task is a hardware register (register inside the CPU) at a certain moment of the task,
These are the contents of the program counter and the task stack, and are information unique to each task. The contents of the context, such as the stack pointer and the program counter, are initialized to appropriate values. The context information is generated in a free area on a memory prepared in advance (tax information 114b).

FIG. 10 is a flowchart for explaining the processing of the task generation function on the real machine side. When the task generation function 112 is activated by a task generation request, first, in step S302, it is checked whether or not a free memory area for generating a new TCB exists in the RAM 23. If there is no free memory area, error processing is performed in step S304. That is, since the return value of the system call indicates the state (success / failure) after the execution of the system call, an error number indicating "insufficient memory" is set as the return value in the process of step S304 in FIG. Perform processing. On the other hand, if there is a free memory area,
Proceeding to step S303, one TCB is secured from the free memory area. Then, in step S304,
The stack pointer and program counter of the secured TCB are initialized to appropriate values.

FIG. 11 is a flowchart showing the processing of the task deletion function on the actual device side. The task deletion function 113 deletes context information of the corresponding task in response to the task deletion request. More specifically, the area 114 on the memory storing the context information is released to make it unused (step S4).
02).

(2) RT in a simulation environment
OS As in the first embodiment, as an implementation example in a simulation environment, an RTOS simulator is operated on a workstation equipped with a SunOS.

FIG. 12 is a block diagram showing the configuration of the simulation-side RTOS according to the second embodiment.
In the RTOS shown in FIG. 12, a task generation function 112a and a task deletion function 1 are added to the basic configuration of the RTOS shown in FIG.
13a is added. Reference numeral 114a denotes task-specific context information, which is an area on a memory managed inside the SunOS system.

Task generation function 112a: The task generation function 112a generates a task as a thread using a thr_create () system call provided by a thread library in response to a task generation request. The SunOS manages thread context information. That is, the task information 114a in FIG. 12 is an area managed inside the SunOS. Note that this system call can be specified by a flag as to whether a thread is generated in an execution state or in a suspended state, but in this embodiment, it is generated in a suspended state and execution is started by the task resuming function 110. I do.

FIG. 13 is a flowchart showing the processing procedure of the task generation function on the simulation side. First, in step S1002, it is determined whether there is a free memory, and if there is no free memory, in step S1004, FIG.
0, the same error processing as in step S304 is performed. If there is a free memory, the process advances to step S1003 to secure a memory area for one TCB from the free memory area. Then, in step S1005, a thr_create () system call is called to generate a suspended thread. Thereafter, in step S1006, the ID of the thread is set to T.
Register with CB. In this RTOS, a memory area called a workspace is collectively secured at the time of initialization. Then, all the system management information such as TCB is taken in this workspace. Therefore, if a memory area of the same size is secured between the real machine and the simulation machine (at the time of initialization), the owned memory area (size) in the real machine / simulation machine matches, so that the same free memory check as the real machine can be performed. . Also, RTOS
In the shared part of, the task execution and interruption are instructed by the task ID, but both the task ID and the thread ID are stored in the TCB. Here, since the TCB exists in the model-dependent part, the task ID and the thread ID can be associated one-to-one. Step S1005 in FIG.
Then, task creation is performed using the thr_Create () system call, and the ID of the thread created by this system call is returned from the function. Therefore, this thread ID is associated with the task ID.

Task deletion function 113a: By the thr_delete () system call provided by the thread library,
Delete threaded tasks. FIG. 14 is a flowchart showing processing of the task deletion function on the simulation side. When the task deletion request is accepted, the thread ID included in the task deletion request is acquired, and the thr_delete () system call is performed using the thread ID as an argument (step S).
1102). After that, the memory area used by the TCB corresponding to the thread is released to make it unused.

[Third Embodiment] In the third embodiment,
A case in which a function of managing an interrupt is further added to the RTOS in the first and second embodiments will be described.

(1) RTOS in Real Machine As in the first and second embodiments, the RTOS is operated on a real machine equipped with Motorola MC68000. Hereinafter, a new RTOS will be used in the third embodiment. A function for managing the interrupt added to the above will be described.

FIG. 15 is a block diagram showing the configuration of the RTOS on the actual device according to the third embodiment. In the configuration shown in FIG. 9, the interrupt management function 120, the interrupt controller 1
21, an interrupt handler 122 has been added. In addition,
The interrupt controller is hardware that controls a hardware interrupt. 82 for AT compatible machines
It is known as a 59A LSI. Hardware interrupts are sent to the CPU via this interrupt controller.
And an interrupt handler corresponding to the generated interrupt is started. The role of the interrupt controller and the interrupt handler in FIG. 15 is to notify the interrupt management function of the RTOS that a hardware interrupt has occurred.

Interrupt management function 120: In response to an interrupt start request, the task interruption function 109b is called, and the context is stored in the TCB 114 of the task being executed.
If multiple interrupts occur, the system stack 12
By stacking the registers on the number 3, it is possible to cope with multiple interrupts. In response to the interrupt end request, the scheduling function 106 is called, and then the task resuming function 115
To return the context from the TCB 114 of the next task. In the case of returning from multiple interrupts, the context is restored from the system stack 123.

FIG. 16 is a flowchart for explaining the interrupt processing on the real machine side. When a hardware interrupt occurs, the interrupt management function 12
0, an interrupt start request is issued (step S80).
2). Note that the beginning of the interrupt handler is a step that the handler routine processes first. Upon receiving the interrupt start request, the interrupt management function 120 first determines whether the interrupt request is a multiple interrupt. If it is a multiple interrupt, the process advances to step S805 to save the register in the system stack 123. On the other hand, if it is not a multiple interrupt, steps S803 to S80
Proceed to step 4 to activate the task suspending function 109. In addition,
As an attribute value of the system, there is a counter for counting the number of (multiple) interrupts. The counter is incremented when the interrupt processing is started by the interrupt management function, and the counter is decremented immediately before the end of the interrupt processing. The determination as to whether or not it is a multiple interrupt is made based on the value of this counter. What is saved in the system stack 123 in step S805 is a register value related to an interrupt being processed. For example, the register value at the moment when the interrupt A currently being processed is interrupted by the interrupt B having a higher priority is saved in the system stack, and after the processing of the interrupt B having the higher priority is completed, the processing of the interrupt A is performed. To be able to resume.

Next, in step S806, the main body of the interrupt handler 122 is executed. After executing the interrupt processing main body, immediately before terminating the interrupt handler, an interrupt end request is issued to the interrupt management function 120 (step S807). In step S806, the original processing of the handler such as the I / O processing based on the cause of the interruption is performed. For example, in serial communication such as RS-232C, a reception interrupt occurs when data is set to a serial port, and a corresponding interrupt handler is activated. In the interrupt handler, I / O processing for reading the received data is performed. And processing for filling the read data into a buffer or the like. This is the processing of the body of the handler here. S807 is the operation itself of calling the interrupt management function, as in step S802.
The processing in the broken line drawn below in FIG. 16 will be performed.

Interrupt management incompetence 1 receiving interrupt end request
20 determines in step S808 whether the interrupt is a multiple interrupt. If it is a multiple interrupt,
The process proceeds to step S811 to restore the register from the system stack 123, and proceeds to step S812. On the other hand, if it is not a multiple interrupt, the process advances to step S809 to call the scheduling function 105 and acquire the task ID of the task to be restarted next. Then, in step S810, the task restart function 110 is activated. Then, in step S812, the hardware interrupt is completed, that is, an interrupt return instruction is executed, and the present process ends. The interrupt return instruction releases the interrupt level (returns to the previous level), the PC (program counter) saved on the system stack,
An SR (status register) or the like is read to return to the interrupted location. Note that restoring other registers must be performed in advance. Step S80
In the processing of the interrupt handler body of No. 6, this RTOS
May execute the following system call. In such a case, the state of the system changes due to the execution of the system call, and a situation occurs in which the task being executed waits for resources or a task with a higher priority acquires the execution right. Normally, scheduling is performed immediately before the end of the system call. However, since task switching cannot be performed during interrupt processing, it is necessary to perform scheduling immediately before the end of interrupt processing. Therefore, step S81
The task restarted at 0 is not necessarily the task that was executed immediately before the interruption.

(2) RT in simulation environment
OS Similar to the first embodiment, as an example of implementation in a simulation environment, a description will be given of an interrupt management function that operates a simulator of the present RTOS that operates on a workstation equipped with a SunOS.

FIG. 17 is a diagram showing the configuration of the RTOS on the simulation device side according to the third embodiment. FIG.
FIG. 7 shows a configuration in which an interrupt management function 132 is added to the basic configuration of the RTOS on the simulation side.

Interrupt management function (super signal thread) 132: Interrupt management function 132 shown in FIG.
Is a mechanism that simulates multiple hardware interrupts using specific signals. This is implemented as a super-signal thread dedicated to interrupt management that runs independently of the thread group that binds to the application task. A signal handler 131 is called when a signal is received from the general-purpose OS. The signal handler 131 notifies the super signal thread 132 of the occurrence of an event. The super signal thread 132 has its own stack 13 to simulate multiple interrupts.
In step 3, the interrupt level is managed. One interrupt handler is generated and activated as one thread (handler thread) 134. That is, when multiple interrupts occur, the number of handler threads 134 equal to the number of multiple nests
Is generated. The super signal thread 132 performs interrupt level control and management of the handler thread 134, and simulates multiple interrupts.

FIG. 18 is a flowchart showing the flow of processing of the interrupt management function 132 when an event such as an interrupt signal occurs. In step S1601, when the signal handler 131 detects the occurrence of an interrupt, the signal handler 131
2 is notified of the occurrence of an interrupt event.

The super signal thread 132 that has received the notification of the interrupt event determines whether the interrupt is a multiple interrupt. If it is a multiple interrupt, step S
The process proceeds from step 1602 to step S1604, in which the running handler thread is suspended, and is stacked on the stack 133. On the other hand, if it is not a multiple interrupt, step S16
02 to step S1603, the task suspending function 1
09 is started to interrupt the task being executed. next,
In step S1605, a corresponding handler thread is generated.

In step S1606, the generated handler thread 134 is activated, and the interrupt handler itself is executed. Next, in step S1608, it is determined whether or not it is a multiple interrupt. If it is a multiple interrupt, the process proceeds to step S1610. In step S1610, the suspended handler thread is fetched from the stack and put into an execution state. Note that the suspended thread for the handler is resumed (executed) in step S1610 in the super signal thread, but the actual resuming timing of the thread is left to the scheduling of the general-purpose OS. You. Normally, the super signal thread is created as the highest priority thread, so
A series of interrupt processing flows to S1610 and S1612, and ends. Thereafter, the thread put into the execution state in S1610 is restarted (by the general-purpose OS).

In the simulation environment, it is necessary to simulate the interrupt management function. Therefore, in order to simulate multiple interrupts, the interrupt handler must be interrupted / restarted and controlled. Therefore, a thread provided by the general-purpose OS is generated, a handler is executed by the thread, and operations such as suspension / resumption are managed by a super signal thread. In the figure, step S1606 is a step for generating a thread for a handler, and the interrupt handler body in step S1607 is a function (or block) describing specific processing for the cause of the interrupt.

If it is not a multiple interrupt in step S1608 (including the case where the last interrupt processing was obtained in multiple interrupts), the flow advances to step S1609 to read out the scheduling function 105, and call the task restart function 110 in step S1611. Here, the interrupt on the simulation side is issued, for example, as follows. In order to handle interrupts in the simulation environment, an independent running thread or process
You have to notify the super signal thread.
For example, a timer interrupt generates a completely independent timer thread and notifies the super signal thread periodically. Notification of the interrupt factor from outside the process
A signal handler provided by a general-purpose OS is used. UN
Taking IX as an example, a signal handler is registered in advance in an RTOS process, and a signal is sent from another process to the process using a kill command or the like. Then, an interrupt is notified to the super signal thread from the activated signal handler.

As described above, according to the third embodiment, R
Interrupt processing can be handled in the simulation of an application using TOS.

In each of the above embodiments, the case where SunOS is used as the simulation environment has been described.
Other OS, such as Microsoft's Windows 9
5. A similar RTOS simulator can be constructed using the multi-thread function provided by Win32-API such as WindowsNT. That is, the RTOS described in the above-described embodiment uses the SunOS system calls (thr_create (), thr_create) introduced in the first to third embodiments.
It can be easily ported as a simulator that runs on a general-purpose OS that provides system calls equivalent to delete (), thr_suspend (), and thr_resume ().

[Fourth Embodiment] FIG. 19 is a diagram showing the structure of an RTOS according to a fourth embodiment. In FIG. 19, a function of acquiring debug information is added to the RTOS (simulation machine side) shown in FIG.

The substance of the system call of the RTOS is in the common part 103, and each system call is structured to pass through a common system call entry point 1801. The system call entry point 1801 has a trace information recording function 1802. The trace information recording function 1802 generates execution trace information 901 as shown in FIG. 20 every time a system call is issued. That is, the trace information recording function 1802 takes out the issued system call,
Call task ID 902, system call execution information 9
03, information such as a time stamp 904 is extracted and temporarily stored as execution trace information 901. Here, the calling task ID 902 is the task ID or O
S is information for identifying an interrupt identifier. The system call execution information 903 includes a system call name (ID) and a parameter group. Further, the time stamp 904 is
Indicates the value of the timer counter when the system call is issued.

Further, the debug information transfer function 1803
Visualization tool (task switch viewer) 180 for graphically displaying the stored execution trace information 901
6 and the like.

Since the trace information recording function 1802 records one piece of execution trace information having the structure shown in FIG. 20 by one system call, the history of a series of operations of the application may require a large storage capacity. . In addition, since resources such as a memory area are generally limited in a real machine environment, it is necessary to devise some method for recording data. As a method for dealing with such a problem, for example, a recording method using a ring buffer can be considered. The ring buffer is a mechanism that efficiently records only the most recent data among a huge amount of data generated continuously.When the number of data to be recorded exceeds the buffer size, the oldest data is overwritten. is there. FIG. 19 shows an example in which the execution trace information 901 generated by the trace information recording function 1802 is stored in the ring buffer 1807. Ring buffer 1807
Is located on the memory and indicates the recording start position.
rt pointer 1808 and En indicating the recording end position
Data recording and retrieval operations are performed using the d pointer 1809.

FIG. 21 shows a trace information recording function 1802.
3 is a flowchart showing the flow of the processing of FIG. First, when execution trace information is generated in step S1901 by issuing a system call or the like, step S19
In 02, the execution trace information is written into the ring buffer 1807 at the position indicated by the End pointer 1809. Next, in step S1903, it is determined whether the number of valid data is equal to or larger than the buffer size. If the number of valid data is smaller than the buffer size, step S19
In step 05, the number of valid data is incremented by one.
On the other hand, when the number of valid data is equal to or larger than the buffer size, the start pointer 1808 is incremented. At this time, if the position of the start pointer 1808 is overrun, it is returned to the beginning. And step S
In 1906, the position of the end pointer 1809 is incremented, and if overrun occurs, the position is returned to the beginning.
The ring buffer uses a normal physically linear buffer and has a mechanism that makes it look like a logical ring. The pointer indicating the Start position or the End position is incremented each time the operation is performed, but reaches the end of the physical buffer. If the value is further incremented, the buffer is overrun. At that point, the pointer is reset to the beginning of the buffer. With this mechanism, it is possible to make it look like a logical ring.

The debug information transfer function 1803
Although implemented inside the common part 103 in FIG. 1, the physical communication path depends on the target system. Therefore, a debug communication module 1805 is provided in the hardware-dependent portion 106 in order to use the communication means provided in the target system. The debug communication module 1805 provides an I / F for performing read / write of a buffer. Specifically, serial, socket, shared memory, ICE, ROM
An emulator or the like is conceivable.

FIG. 22 is a flowchart showing a procedure of processing when the ring buffer shown in the above example is used in the debug information transfer function 1803. First, in step S2002, the debug information transfer function 1803 determines whether the number of valid data is one or more. If the number of valid data is one or more, it is determined that there is execution trace information to be transferred, and the process proceeds to step S2003.
In step S2003, one piece of data is extracted from the ring buffer. Then, in step S2004,
The extracted execution trace information is transferred to an external module (for example, a visualization tool 1806) via the debug communication module 1805. Then, in step S2005, the number of valid data is reduced by one, and in step S20
Return to 02.

FIG. 23 shows an example of an overview of a task switch viewer 1806 as a display device for graphically displaying the trace information thus transferred.

As described above, by implementing means for acquiring a system call, task switch history, system management information, and the like effective as debug information of the RTOS in a common part, debugging can be performed with a unified concept even on different platforms. It can be carried out.

As described above, the RTOS of the fourth embodiment
Is written in C language so that the parts that depend on the hardware are cut to the minimum necessary, and the other parts are written in C language so that they can be commonly used on various platforms, and the effects of hardware differences are reduced It has a structure such that all system calls are called via a common entry point, and the scheduling function is called after the execution of the system call. At this common entry point, (1) a calling task ID, (2) a trace information recording function for storing information such as system call execution information, and (3) a time stamp, and the saved trace information is stored in a task switch viewer or the like. By providing the means for transferring to an external module, it is possible to provide platform-independent debug information.

As described above, according to the above embodiments, the following effects can be expected. (1) Platform Independence The same behavior can be performed on different platforms such as a real machine and a general-purpose development machine without any modification of the application task. (2) Ease of porting Since the machine-dependent part is cut out to a minimum, porting to another platform can be easily realized. (3) Platform-independent debugger If only a module that performs hardware-dependent physical communication is implemented, the same debugger can be used on various platforms. (4) Unification of Debug Information Since the acquired debug information is information independent of the platform, it is possible to debug with a unified concept even between different platforms.

An object of the present invention is to supply a storage medium storing a program code of software for realizing the functions of the above-described embodiments to a system or an apparatus, and to provide a computer (or CPU) of the system or the apparatus.
And MPU) read and execute the program code stored in the storage medium.

In this case, the program code itself read from the storage medium implements the functions of the above-described embodiment, and the storage medium storing the program code constitutes the present invention.

Examples of the storage medium for supplying the program code include a floppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM, and CD.
-R, DVD, magnetic tape, nonvolatile memory card,
A ROM or the like can be used.

When the computer executes the readout program code, not only the functions of the above-described embodiment are realized, but also the OS (Operating System) running on the computer based on the instruction of the program code. ) May perform some or all of the actual processing, and the processing may realize the functions of the above-described embodiments.

Further, after the program code read from the storage medium is written into a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, based on the instructions of the program code, It goes without saying that the CPU included in the function expansion board or the function expansion unit performs part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.

[0087]

As described above, according to the multitask control method of the present invention, it is possible to have the same interface specifications on all platforms and perform the same operation by applications.

Also, according to the present invention, an RT that has the same interface specifications on all platforms and enables an application to perform the same operation
OS debugging environment (task switch / viewer, etc.)
, It is possible to collect unified debug information on any platform.

[0089]

[Brief description of the drawings]

FIG. 1 is a basic configuration diagram of an RTOS according to a first embodiment.

FIG. 2 is a flowchart showing a procedure of processing by a common part from a system call issuance to a task switch.

FIG. 3 is a diagram illustrating an example of realizing a scheduling algorithm in priority order.

FIG. 4 is a diagram showing an example in which scheduling by time sharing is realized.

FIG. 5 is a flowchart illustrating a flow of processing of a task suspending function on the actual device side.

FIG. 6 is a flowchart illustrating a flow of a process of a task restart function 109 on the actual device side.

FIG. 7 is a flowchart illustrating a flow of a process of a task suspending function on the simulation machine side.

FIG. 8 is a flowchart showing a processing flow of a task resuming function on the simulation machine side.

FIG. 9 is a block diagram illustrating a configuration of a real-time RTOS according to a second embodiment;

FIG. 10 is a flowchart illustrating processing of a task generation function on the real machine side.

FIG. 11 is a flowchart illustrating a process of a task deletion function on the real device side.

FIG. 12 is a block diagram illustrating a configuration of an RTOS on a simulation side according to a second embodiment.

FIG. 13 is a flowchart illustrating a processing procedure of a task generation function on the simulation side.

FIG. 14 is a flowchart showing processing of a task deletion function on the simulation side.

FIG. 15 is a block diagram illustrating a configuration of an RTOS on an actual device according to a third embodiment.

FIG. 16 is a flowchart illustrating an actual machine-side interrupt process;

FIG. 17 is a diagram illustrating a configuration of an RTOS on a simulation device side according to a third embodiment.

FIG. 18 is a flowchart showing a flow of processing of the interrupt management function 132 when an event such as a signal occurs.

FIG. 19 is a diagram showing a structure of an RTOS according to a fourth embodiment.

FIG. 20 is a diagram illustrating a data configuration example of execution trace information.

FIG. 21 is a flowchart showing a processing flow of a trace information recording function 1802.

FIG. 22 is a flowchart showing a procedure of processing when the ring buffer shown in the previous example is used in the debug information transfer function 1803.

FIG. 23 is a diagram illustrating an example of an overview of a task switch viewer 1806.

FIG. 24 is a diagram illustrating a real device and a computer device that provides a simulation environment according to the first embodiment.

[Explanation of symbols]

 Reference Signs List 101 application 102 application / task 103 common part of RTOS 104 set of entities of RTOS system call 105 scheduling function 106 model-dependent part of RTOS 108 task switch control function 109 task interruption function 110 task restart function

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Yoichi Iwabuchi 3-30-2 Shimomaruko, Ota-ku, Tokyo Canon Inc. (72) Inventor Junji Yamada 3-30-2 Shimomaruko, Ota-ku, Tokyo Canon F term (reference) in corporation 5B098 GA02 GA04 GA08 GB02 GB09 GB11 GB13 GC03 GC14 JJ07

Claims (11)

[Claims] 1. A multi-task control method for controlling an application program including a plurality of tasks, comprising: a scheduling step of performing scheduling related to execution of the plurality of tasks and issuing a task control instruction; An execution step of controlling execution of a task in accordance with the operation environment of the application program based on the task control instruction issued in the step (a). 2. The task control instruction includes a task suspension instruction and a resume instruction, and the execution step is performed according to an operation environment of the application program based on the suspension instruction and the resume instruction issued in the scheduling step. 2. The multitask control method according to claim 1, wherein a task suspending process and a task resuming process are executed. 3. The multi-task control according to claim 1, wherein the execution step controls the task by rewriting data of a task control block for controlling the task based on the task control instruction. Method. 4. The multitask control method according to claim 1, wherein the execution step controls the task by issuing a general-purpose OS system call based on the task control instruction. 5. The multitask control method according to claim 1, wherein the task control instruction in the scheduling step includes a task generation instruction and a task deletion instruction. 6. The multitask control method according to claim 1, wherein said execution step further includes an interrupt process according to an operation environment of said application program. 7. The execution process according to claim 6, wherein a thread for executing an interrupt process is generated in response to an interrupt signal from a general-purpose OS, and the interrupt process is executed.
2. The multitask control method according to item 1. 8. A holding step of holding history information on the task control instruction issued in the scheduling step, and an output step of outputting the history information held in the holding step in a form according to the operating environment of the application program. The multitask control method according to claim 1, further comprising: 9. A storage medium for storing a multitask control program for causing a computer to control an application program including a plurality of tasks, wherein the multitask control program performs scheduling related to execution of the plurality of tasks. And a code for an execution step for controlling task execution according to the operating environment of the application program based on the task control instruction issued in the scheduling step. A storage medium characterized by the above-mentioned. 10. The code of a holding step for holding history information on the task control instruction issued in the scheduling step, wherein the multitask control program stores the history information held in the holding step in an operating environment of the application program. 10. A code for an output step of outputting in a corresponding form.
A storage medium according to claim 1. 11. The storage medium according to claim 9, wherein the code of the scheduling step is described in the text of a C language program.