JPH10105415A - Real time os - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the reutilizing property of a task (program) by sharing a stack area with TCB between the tasks which are not simultaneously operated at the time of using a real time OS, reducing the capacitance of RAM to be used and also dividing the task into the operation units of a system. SOLUTION: The plural tasks 1 which are not simultaneously used within the tasks are made into a group, the plural tasks which are not simultaneously used share a task control block and the stack area 2, the usage of the stack area is exclusively controlled and memory capacity (RAM) 10 to be used is reduced. Actually, queuing is executed in the task control block waiting task queue of the task by the start system call of the task, the task control block is opened whenever the task using the task control block finishes execution and the queued task is executed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to a real-time OS.
In particular, the present invention relates to a memory-saving embedded real-time OS of an embedded microcomputer.

[0002]

2. Description of the Related Art A conventional real-time OS uses a task control block (TCB) to manage individual tasks. One TCB is required for each task, and is generated statically when the system is started. This TC
B stores information necessary for the operation of the task.
The OS can know the status of the task and other various information by referring to the TCB. To change information in the TCB, the OS changes the contents using a system call of the OS. The user cannot operate it directly. A task-specific memory space is statically created at system startup as a stack area for the task.
In other words, a system using a real-time OS requires the following RAM.

The number of tasks × TCB size + Σstack size of task n + memory required other than tasks.

FIGS. 18 to 21 show a conventional real-time O / O.
An operation example of S will be described. FIG. 18 shows a state immediately after the system is started. Task 1 is in the RUN state, and the other tasks are in the dormant state. After that, task 1 activates task 2 and the priority of task 2 becomes task 1
, The task 2 enters the RUN state, and the task 1 enters the ready state (FIG. 19). When the task 2 completes the processing, the task 1 enters the RUN state again (FIG. 20). Thereafter, when task 1 activates task 3, task 3 enters the RUN state and task 1 enters the ready state because the priority of task 3 is higher than the priority of task 1 (FIG. 21).

[0005]

In the above-described conventional real-time OS, the TCB and the stack area for all tasks are statically secured, and there are separate memory spaces for tasks that do not operate at the same time. Therefore, one set of TCB and a stack area are required for each task generated statically, and there is a problem that generating many tasks requires a large amount of memory (RAM).

Further, in the task division of the real-time OS, if each task is divided and defined based on one operation in the system, the number of tasks increases, and the RA to be used increases.
The capacity of M increases. On the other hand, in order to reduce the number of tasks in order to reduce the amount of RAM used, some operations are performed in one operation.
Although the tasks are grouped into individual tasks, there is a problem that the contents of the tasks become complicated, and it is difficult to divert them to other systems.

Accordingly, an object of the present invention is to provide a real-time O
By reducing the amount of RAM used by sharing the stack area with the TCB for tasks that do not operate at the same time when using S, and by dividing the tasks into system operation units, the reusability of the tasks (programs) is improved. It is to provide a real-time OS that can be improved.

[0008]

According to the present invention, there is provided a task control block (TC) in which information necessary for the operation of a task is stored.
In the real-time OS controlling the task status and other various information by referring to B), a plurality of non-simultaneous tasks among the tasks are grouped, and a plurality of non-simultaneous tasks are not used in the grouped tasks. A real-time OS is characterized in that a task shares a stack area with a task control block, exclusively controls use of the stack area, and reduces a memory capacity (RAM) used.

In addition, a task control block waiting task queue (TC
B task queue), releases the task control block each time the task using the task control block finishes execution, and the task queued in the task control block waiting queue (TCB waiting state) Preferably, it is performed.

[0010] Furthermore, the task control block wait queue of the task is preferably processed on a first-in first-out (FIFO) basis.

Still preferably, the task control block wait queue of the task is processed in priority order.

It is preferable that a sub-task control block is provided in addition to the task control block.

Further, it is preferable that one subtask control block is prepared for each task.

Further, it is preferable that the sub-task control block manages the task body, and the task control block manages the operation of the task.

In particular, the present invention groups a plurality of non-simultaneous tasks, and the tasks in the group utilize a set of TCBs and a stack area.

A plurality of non-simultaneous tasks are a set of T
By using the CB and the stack area, the memory (RAM) in the system can be used effectively.

Further, as a result, the task can be divided without increasing the use amount of the RAM, so that the reusability of the created task (program) can be improved.

[0018]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention will be described in detail with reference to the drawings.

FIGS. 1 to 6 show a first embodiment of the present invention. TC during operation of the real-time OS of the present invention
B shows the usage status of the stack area. Here, there are three tasks of task 1, task 2, and task 3, and task 2 and task 3 do not operate at the same time. Therefore, task 2 and task 3 are grouped.

FIG. 1 shows a state immediately after the system is started. Reference numeral 10 denotes a RAM, and reference numeral 20 denotes a ROM. In FIG. 1, task 1 is in the RUN state, and other tasks are in the dormant (DORMANT) state.

Thereafter, task 1 starts task 2.
The TCB used by task 2 is T
It turns out that it is CB2. Since TCB2 is not currently used, task 2 acquires TCB2 and performs startup processing. Since the priority of task 2 is lower than the priority of task 1, task 1 remains in the RUN state and task 2 enters the ready state (FIG. 2).

Subsequently, the task 1 issues a system call for activating the task 3. As in the case of the task 2, the TCB used by the task 3 is also determined by the TC from the task initialization information.
B2. However, TCB2 used by task 3 is
Since task 2 is using it, the system call contains "T
The error "CB is in use" is returned (FIG. 3).

Next, the priority of the task 1 is lowered, the task 2 is set to the RUN state, the task 2 is executed, and when the processing is completed, the task 2 releases the TCB 2 (FIG. 4).

When the task 2 completes the processing, the task 1 is again in the RUN state, and issues a system call to activate the task 3 again (FIG. 5).

This time, since TCB2 used by task 3 is not used, task 3 acquires TCB2 and
The RUN state is set (FIG. 6).

In the task group using TCB2, since only one task is operated, the stack area of the task does not need to exist for each task. One stack area exists for each task group, that is, one task area exists for each TCB. I just need.

In the first embodiment, a system call for activating a task is issued, and if the TCB used by the task is used by another task, an error is returned and the TCB is used.
It is necessary to issue a system call to start the task again after the CB is released.

FIGS. 7 to 11 show a second embodiment of the present invention. In the second embodiment, a method for queuing a task activation request will be described. Here, there are five tasks, task 1 to task 5, and task 2 to task 5 do not operate at the same time. Therefore, task 5 is grouped into task 2. Real-time O of this embodiment
In S, in addition to the TCB, a subtask control block (hereinafter referred to as Su)
bTCB) is introduced. This Sub
One TCB is prepared for each task. That is,
In the conventional real-time OS, the TCB manages all of the tasks.
Then, the TCB manages the operation of the task, and the SubTCB manages the task body (program).

FIG. 7 shows a state immediately after the system is started. Task 1 is in the RUN state, and the other tasks are in the dormant state. Then task 1 becomes task 2
Start The TCB used by task 2 is found to be TCB2 from the task initialization information of task 2. TCB
Since task 2 is not used at present, task 2 acquires TCB2 and starts up. Since the priority of task 2 is lower than the priority of task 1, task 2 remains in the RUN state and task 2 is in the ready state (FIG. 8).

Subsequently, the task 1 issues a system call for activating the task 3. As in the case of task 2, the task initialization information of task 3
CB is also TCB2. However, the T used by task 3
Since CB2 is used by task 2, S3 of task 3
ubTCB is linked to the waiting task queue of TCB2 (TCB waiting task queue) (FIG. 9).

Further, tasks 4 and 5 are also started,
It is also linked to the TCB waiting task queue of TCB2. The state of task 3, task 4, and task 5 at this time is called "TCB waiting state" (FIG. 10).

Next, the priority of the task 1 is lowered, the task 2 is set to the RUN state, the task 2 is executed, and when the processing is completed, the task 2 releases the TCB 2 and the OS
The TCB is allocated to the task of the SubTCB linked to the head of the TCB waiting queue, and scheduling is performed.
If the initial priority of task 3 is higher than the priority of task 1, task 3 is in the RUN state and task 1 is in the ready state. Task 4 and task 5 are TCB
It remains in the waiting state (FIG. 11).

Thereafter, every time the task using TCB2 is completed, TCB2 is released and TCB2 is released to TCB2.
The tasks in the CB waiting state sequentially transition to the ready state or the RUN state.

In the second embodiment, the tasks waiting for TCB are activated in the order in which the activation requests are issued. In the third embodiment, the activation order of tasks waiting for TCB is changed in the order of higher priority of the task. I do.

FIGS. 12 to 17 show the usage status of the TCB and the stack area according to the third embodiment. Here, there are five tasks, task 1 to task 5, and task 2 to task 5 do not operate at the same time. Therefore, tasks 2 to 5 are grouped. In the real-time OS according to the present embodiment, as in the second embodiment, the TCB
In addition, a control block called a sub-task control block (hereinafter referred to as SubTCB) is introduced, and in the present embodiment, the priority information of the task that has been in the TCB is moved to the SubTCB.

FIG. 12 shows a state immediately after the system is started. Task 1 is in the RUN state, and the other tasks are in the dormant state.

Thereafter, task 1 activates task 2.
The TCB used by task 2 is found to be TCB2 from the task initialization information of task 2. Since TCB2 is not currently used, task 2 acquires TCB2 and performs startup processing. Task 2 priority is Task 1
, The task 2 remains in the RUN state and the task 2 enters the ready state (FIG. 13).

Subsequently, the task 1 issues a system call for activating the task 3. As in the case of task 2, the task initialization information of task 3
CB is also TCB2. However, the T used by task 3
Since CB2 is used by task 2, S3 of task 3
ubTCB is linked to the wait queue of TCB2 (FIG. 14).

The task 3 has a higher priority than the task 2, but the task that is currently being executed or is ready
Since the information in the stack is lost in the B wait state, the task 2 is not placed in the TCB wait state and the task 3 is not made ready.

Further, task 1 activates task 4.
Because task 4 has a higher priority than task 3,
It is linked before task 3 in the waiting task queue of TCB2. Subsequently, the task 5 is also activated. Since the task 5 has the same priority as the task 4, the task 5 is linked behind the task 4 in the waiting task queue of the TCB2. this is,
For tasks of the same priority, first come
First Service (First Come Fir)
stService (FCFS) processing (FIG. 15).

Next, when the task 1 issues a system call for setting the priority of the task 3 higher than the priority of the task 4, the waiting task queue of the TCB 2 is changed (FIG. 16).

After that, the priority of the task 1 is lowered, the task 2 is set to the RUN state, the task 2 is executed, and when the processing is completed, the task 2 releases the TCB 2 and the OS 2
Is the SubTC linked to the head of the TC3 wait queue.
The TCB is assigned to the task B and scheduling is performed. The priority of task 3 at that time is task 1.
, The task 3 is in the RUN state and the task 1 is in the ready state. Task 4 and task 5 remain in the TCB waiting state (FIG. 17).

Thereafter, every time the task using TCB2 is completed, TCB2 is released and TCB2 is released to TCB2.
The tasks in the CB waiting state sequentially transition to the ready state or the RUN state.

[0044]

According to the present invention, by sharing the stack area with the TCB for tasks that do not operate at the same time,
Use efficiency is improved. Therefore, TCB in multiple tasks
By sharing the stack area with the memory, it is possible to reduce the number of memories (RAM) used.

Further, according to the present invention, the task can be divided according to the operation of the system without increasing the RAM capacity to be used, so that the task can be easily reused.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a memory map when a real-time OS is started according to a first embodiment of the present invention.

FIG. 2 is a block diagram illustrating a state after a real-time OS is started according to the first embodiment;

FIG. 3 is a block diagram illustrating a state after a real-time OS is started according to the first embodiment.

FIG. 4 is a block diagram illustrating a state after the real-time OS is started according to the first embodiment.

FIG. 5 is a block diagram illustrating a state after the real-time OS is started according to the first embodiment.

FIG. 6 is a block diagram illustrating a state after the real-time OS is started according to the first embodiment.

FIG. 7 is a block diagram illustrating a memory map when a real-time OS is started according to a second embodiment of this invention.

FIG. 8 is a block diagram illustrating a state after the real-time OS is started according to the second embodiment.

FIG. 9 is a block diagram illustrating a state after activation of a real-time OS according to the second embodiment.

FIG. 10 is a block diagram illustrating a state after the real-time OS is started according to the second embodiment.

FIG. 11 is a block diagram illustrating a state after the real-time OS is started according to the second embodiment.

FIG. 12 is a block diagram showing a memory map when a real-time OS is started according to a third embodiment of the present invention.

FIG. 13 is a block diagram illustrating a state after the real-time OS is started according to the third embodiment.

FIG. 14 is a block diagram illustrating a state after activation of a real-time OS according to the third embodiment.

FIG. 15 is a block diagram illustrating a state after activation of a real-time OS according to the third embodiment.

FIG. 16 is a block diagram illustrating a state after the real-time OS is started according to the third embodiment.

FIG. 17 is a block diagram showing a state after the real-time OS is started according to the third embodiment.

FIG. 18 is a block diagram showing a memory map when a conventional real-time OS is started.

FIG. 19 is a block diagram showing a memory map after a conventional real-time OS is started.

FIG. 20 is a block diagram showing a memory map after a conventional real-time OS is started.

FIG. 21 is a block diagram showing a memory map after a conventional real-time OS is started.

[Explanation of symbols]

 10 RAM 20 ROM

Claims (7)

[Claims] 1. A real-time OS for controlling a state of a task and various other information by referring to a task control block in which information necessary for the operation of the task is stored. Grouping tasks that are not to be used, and within the grouped tasks, the plurality of tasks that are not used at the same time share the stack area with the task control block, exclusively control use of the stack area, and use the memory capacity. A real-time OS characterized by reducing (RAM). 2. The system according to claim 1, wherein said task activation system call comprises:
The task is queued in a task control block waiting task queue, the task control block is released each time a task using the task control block finishes executing, and the task is queued in the task control block waiting queue. The real-time OS according to claim 1, wherein the task is executed. 3. The real-time OS according to claim 2, wherein the task control block waiting queue of the task is processed in a first-in first-out manner. 4. The real-time OS according to claim 2, wherein the task control block waiting queue of the task is processed in a priority order. 5. The real-time OS according to claim 1, further comprising a sub-task control block in addition to said task control block. 6. The real-time OS according to claim 1, wherein one subtask control block is prepared for each task. 7. The real-time OS according to claim 5, wherein the sub-task control block manages a task body, and the task control block manages a task operation.