KR20170046358A - Method and apparatus for guaranteeing priority of logic in an embedded operating system - Google Patents

Abstract

According to an aspect of the present invention, a method for guaranteeing priority of a logic in an embedded operating system comprises: a step of dividing a task into a plurality of logics in the embedded operating system; a step of selecting a specific logic among the plurality of logics to be executed in a second priority higher than a first priority of the task; a step of generating interrupt having the second priority during the execution of the task; and a step of calling the selected specific logic in the interrupt into a subroutine. The present invention can prevent the specific logic required to secure a priority to be interrupted even if there is the task or the interrupt having the higher priority than a priority allocated to the task.

Description

[0001] The present invention relates to a method and an apparatus for guaranteeing priority of logic in an embedded operating system,

The present invention relates to a method and apparatus for guaranteeing the priority of logic in an embedded operating system. More particularly, to a method for generating artificial interrupts and a device for performing the method, in order to perform a specific logic which requires priority among logic constituting a task.

An embedded system is an electronic control system consisting of hardware and software of a computer and additional mechanical devices or other parts to perform predetermined functions. Mainly, the embedded system differs from a general purpose computer in that it is designed as a dedicated system specialized for a specific function.

For example, automotive ignition systems, engine control systems or brake systems are part of the embedded system. Also, embedded systems are included in household appliances such as televisions, refrigerators, microwave ovens, washing machines, and cameras. Furthermore, embedded systems are used in medical fields such as dialysis apparatuses and artificial organs.

As a more detailed example, in the case of a washing machine, a conventional washing machine was a simple device having only a washing and dehydrating function through a motor and a simple control device. However, recently, in consideration of the amount of laundry, the type of cloth of laundry, So that various washing methods can be set. These functions are difficult to implement in the former simple devices. To do so, the embedded system with the micro-processor and the control program is embedded in the washing machine.

There is an embedded operating system for running an embedded system such as Windows (Windows) or Linux (Linux) as an operating system for running a computer. For example, smartphones have built-in operating systems such as android, as well as open source such as eCos (Embedded Configurable Operating System), VxWorks, OSE, VRTX, Nucleus, pSOS, There are various embedded operating systems such as QNX.

In most embedded operating systems, a task has only one priority. In other words, since priority is defined and managed on a task-by-task basis, in some cases, a task that performs important logic performs less important logic, but the execution may be stopped by a higher-priority task. Therefore, there is a need for a method capable of performing logic with different priorities within a task.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a method and apparatus for guaranteeing the priority of logic in an embedded operating system.

The technical problems of the present invention are not limited to the above-mentioned technical problems, and other technical problems which are not mentioned can be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, there is provided a method for guaranteeing logic priority in an embedded operating system, the method comprising: dividing a task into a plurality of logic in an embedded operating system; Selecting a particular logic to be executed with a high second priority, generating an interrupt having the second priority during execution of the task, and calling the selected specific logic in the interrupt into a subroutine .

In one embodiment, the step of selecting the specific logic may include a step of comparing the execution time of the task with the execution time of the specific logic to determine whether to select the specific logic.

In another embodiment, the step of selecting the particular logic may comprise comparing the resource consumption of the task with the resource consumption of the particular logic to determine whether to select the particular logic

In yet another embodiment, the step of selecting the particular logic may include comparing the difference between the first priority of the task and the second priority to which the particular logic is to be executed to determine whether to select .

In yet another embodiment, the step of selecting the particular logic may comprise determining whether to select based on the scenario set in the embedded operating system.

In yet another embodiment, the step of generating an interrupt having the second priority may include the steps of excluding the particular logic in the task and generating the interrupt at the time when the excluded specific logic is to be performed in the task Step < / RTI >

According to another aspect of the present invention, there is provided an apparatus for ensuring priority of logic in an embedded operating system, the apparatus including an interface, a processor, a memory for loading a computer program executed by the processor, And the like. Here, the computer program may further comprise: an operation for dividing the task into a plurality of logic in an embedded operating system and an operation for selecting a specific logic to be executed at a second priority higher than the first priority of the task among the plurality of logic; An operation for generating the interrupt having the second priority while the task is being executed, and an operation for calling the selected specific logic in the interrupt into the subroutine.

According to the present invention as described above, it is possible to perform logic having different priorities in one task. Thus, even if a task or an interrupt having a priority higher than the priority assigned to the task is generated, it is possible to prevent the specific logic that needs priority assurance from being stopped during execution.

The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood to those of ordinary skill in the art from the following description.

1A through 1B illustrate the priorities of logic in a conventional embedded operating system It is a pseudocode to explain how to manage.
Figure 2 shows the priorities of logic in a conventional embedded operating system This is a conceptual diagram for explaining how to manage.
3A and 3B are pseudocode for explaining the priority that each subroutine can have.
Figures 4A-B illustrate the priorities of logic in a conventional embedded operating system FIG. 2 is an exemplary diagram for explaining an embodiment according to a method of managing a content.
6 through 7 are flowcharts of a method for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.
8 is a pseudocode explaining a method for assuring the priority of logic in an embedded operating system according to an embodiment of the present invention.
9A and 9B are diagrams for explaining a method for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.
10 is a hardware configuration diagram of an apparatus for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention and the manner of achieving them will become apparent with reference to the embodiments described in detail below with reference to the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Is provided to fully convey the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Unless defined otherwise, all terms (including technical and scientific terms) used herein may be used in a sense commonly understood by one of ordinary skill in the art to which this invention belongs. Also, commonly used predefined terms are not ideally or excessively interpreted unless explicitly defined otherwise. The terminology used herein is for the purpose of illustrating embodiments and is not intended to be limiting of the present invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification.

It is noted that the terms "comprises" and / or "comprising" used in the specification are intended to be inclusive in a manner similar to the components, steps, operations, and / Or additions.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

1A through 1B illustrate the priorities of logic in a conventional embedded operating system It is a pseudocode to explain how to manage.

An embedded system is an electronic control system consisting of hardware and software of a computer and additional mechanical devices or other parts to perform predetermined functions. In particular, a real-time operating system (RTOS) among the embedded operating systems for driving an embedded system must output a result within a predetermined time, so that priorities between tasks that consume resources of the microprocessor are managed Is very important.

Generally, in the embedded operating system, a scheduler is used to manage the priority among the tasks. Here, the scheduler is a part of determining the task to use the microprocessor at a specific time, which is the core of the embedded operating system. There are four major algorithms that are widely used as schedulers.

One is a first-in-first-out (FIFO) algorithm in which each task is executed until the end, and the next task is started when the task is finished. However, since the task is processed in order of request, it is a critical task, but there is a disadvantage that it can be carried out later in the order of request.

The other is a shortest job first algorithm. Each task is executed until the end of the task. When the task is finished, the task with the least time until the task finishes is selected. However, since the task is processed based on the execution time of the task, there is a disadvantage that the wait time may be longer than necessary in case of a task having a long execution time.

The other is a priority-based algorithm, which has priority for each task and is used to select the next task to be performed. Priority-based scheduling is preemptive and nonpreemptive. The preemptive type is a method of stopping a task that is being executed and performing a higher priority task when the task having a priority higher than that of the task is ready. In the non-linear type, each task is executed When the task is finished, the next highest priority task is selected.

The last is a round robin algorithm, in which each task is executed only for a specified period of time called a time slice. After that time, the task being executed is stopped and the next task is executed. If all tasks have similar priority, the round-robin algorithm can be advantageous, but if the priority difference between the tasks is large, it is an important task and it is treated the same.

Most embedded operating systems are real-time operating systems, and real-time operating systems perform priority management using preemptive scheduling among the algorithms described above to ensure real-time performance of each task. That is, a priority is assigned to each task, and when a request for execution of a task having a higher priority occurs, control is given to the task. However, conventionally, each task is executed with priority for each task or each interrupt, so that one task can have only one priority.

Referring to FIG. 1A, it can be seen that three piles of logic are executed in the pseudo code 101 of task # 1. That is, task # 1 is being executed in the order of logic> subroutine # 1> logic. Here, the logic of three chunks included in task # 1 all have the same priority. That is, the logic, subroutine # 1, and logic are executed with the priority of task # 1 unchanged. This also applies to the case of FIG.

1B, it can be seen that the subroutine # 1 defined in the pseudo code 103b of the external subroutine # 1 is called from the pseudo code 103a of the task # 1. Since subroutine # 1 is called with priority of task # 1 when subroutine # 1 is called in task # 1 even if subroutine # 1 is logic defined separately to task # 1, subroutine # 1 is performed under the priority of task # 1.

Conventionally, since one task can perform logic with only one priority, it is possible that a task performing important logic performs less important logic, but the execution may be stopped by a higher priority task have. In this regard, the priorities of the respective tasks and the interrupts will be described in more detail with reference to FIG.

Figure 2 shows the priorities of logic in a conventional embedded operating system This is a conceptual diagram for explaining how to manage.

It is a task or an interrupt that can be performed with priority in preemption scheduling. That is, the task scheduler 111 waits for each task to execute with a specific priority, and similarly, each interrupt has a specific priority in the interrupt table 115 and waits for an interrupt to occur.

For convenience of understanding, it is assumed that the priority exists from 1 to 6, and the lower the number, the higher the priority. That is, priority 1 is the highest priority and priority 6 is the lowest priority. In the example of FIG. 2, the task # 1 and the interrupt # 1 have the priority 1 having the highest priority, and the task # 6 and the interrupt # 6 have the priority 6 having the lowest priority. When priority is given below, it shall be accompanied by []. Priority 1 is represented by [1], and priority 6 is represented by [6].

In the example of FIG. 2, task # 1 has priority of [1] and calls subroutine # 1 internally. In this case, subroutine # 1 is executed with priority of [1], which is the priority of task # 1. Similarly, task # 2 has priority of [2] and calls subroutine # 2 internally. In task # 3, subroutine # 3 and subroutine # 4 are called with priority of [3], and subroutine # 6 is called with priority of [4] in case of task # 4. In task # 5, subroutine # 3 is called with priority of [5], and in case of task # 6, subroutine # 5 and subroutine # 6 are called with priority of [6].

In the example of FIG. 2, the interrupt # 1 and the interrupt # 2 do not call the specific subroutine. In the case of the interrupt # 3, the subroutine # 3 is called with the priority of [3]. In the case of the interrupt # 4 Call subroutine # 6 with the priority of [4]. As such, tasks and interrupts may take precedence, but each subroutine contained in the list (113) of subroutines has no priority. Instead, it is executed with the priority of the task or interrupt that invoked it. The priority of such a subroutine will be described in more detail with reference to FIGS. 3A to 3B.

3A and 3B are pseudocode for explaining the priority that each subroutine can have.

Referring to FIG. 3A, it can be seen that subroutine # 3 and subroutine # 4 are called in order in the pseudo code 105 of task # 3 internally. As such, one task can call multiple subroutines as needed. Of course, you may not even call any subroutines. Also, in the example of 3a, it is described that specific logic is executed before and after execution of subroutine # 3 and subroutine # 4, but it is not necessarily required to execute specific logic before and after execution of subroutine.

Here, a subroutine is a term referring to a series of codes that are separately made to perform specific logic, and is often called a function. Using subroutines can improve code reusability and readability. That is, a subroutine can be called from multiple tasks or interrupts, so it does not have its own priority, but rather inherits the priority of the task or interrupt that called it. In the example of FIG. 3A, the subroutine # 3 and the subroutine # 4 will be executed with priority of [3], even though they are different subroutines.

Referring to FIG. 3B, the pseudo code 107 of task # 5 internally calls subroutine # 3. In this case, subroutine # 3 will be executed with the priority of [5]. In the example of FIG. 3A, the same subroutine # 3 is executed with priority of [3] in the example of FIG. 3A according to the task calling it, and in the example of FIG. .

3A through 3B, even when a plurality of different subroutines are called in one task, they are executed with a single priority, and even if they are the same subroutine, We have seen that we can have priorities. Problems that may occur in this case will be described in more detail with reference to FIGS. 4A to 5B.

Figures 4A-B illustrate the priorities of logic in a conventional embedded operating system FIG. 2 is an exemplary diagram for explaining an embodiment according to a method of managing a content.

In the example of FIG. 4A, it can be seen that, during execution of task # 2 having the priority of [2], there is a request of task # 1 having the priority of [1]. First, at the time t1, the request 121 of the task # 2 comes in, and the logic and the subroutine of the task # 2 are being executed. Here, when the request 123 of the task # 1 occurs at the time t2 during execution of the subroutine # 2 of the task # 2, since the priority of the task # 1 is higher than the priority of the task # 2, The execution is suspended for a while. Instead, context switching occurs to task # 1 having a higher priority and context switching is again performed after completion of task # 1 and subroutine # 1 so that the remaining task # 2 Subroutine # 2 and logic are then executed.

Although subroutines are described as not having a specific priority but of following the priority of the task or interrupt that calls the subroutine, the subroutine itself is executed with specific logic, so there may be a significance between the subroutines. In the example of FIG. 2, it is assumed that subroutine # 1 and subroutine # 1, which are more important than task # 2 and subroutine # 2 in the case of FIG. 4A, It is not unreasonable to stop subroutine # 2 at time t2.

In the example of FIG. 4B, it can be seen that, during execution of task # 1 having the priority of [1], there is a request of task # 2 having the priority of [2]. First, the request 125 of the task # 1 comes in at the time t3, and the logic and the subroutine of the task # 1 are being executed. Here, when the request 127 of the task # 2 occurs at time t4 during execution of the subroutine # 1 of the task # 1, since the priority of the task # 1 is higher than the priority of the task # 2, Performance is suspended for a while. After execution of task # 1 having a higher priority is completed, logic is executed with subroutine # 2 of held task # 2.

Even in the case of FIG. 4B, the task # 1 and the subroutine # 1 having the higher priority are first processed in spite of the requests of the task # 2 and the subroutine # 2. Therefore, It is not unreasonable. If the task and the subroutine called by the task have similar priorities and importance, there is no problem with the existing method. However, this can be a problem if you call a more important subroutine in a task with a lower priority, or a less important subroutine in a task with a higher priority.

In the example of FIG. 5A, when the task # 5 having the priority of [5] is executed, the case of the task # 4 having the priority of [4] is found. First, at the time t5, the request 131 of the task # 5 comes in, and the logic and the subroutine of the task # 5 are being executed. Here, when the request 133 of the task # 4 occurs at the time t6 during the execution of the subroutine # 3 of the task # 5, since the priority of the task # 4 is higher than the priority of the task # 5, The execution is suspended for a while. Instead, context switching occurs with task # 4 having a higher priority and context switching is again performed after completion of task # 4 and subroutine # 6, and the remaining task # 5 Subroutine # 3 and logic are then executed.

At first glance, it looks similar to the case of FIG. However, in detail, even task # 5 with priority of [5] has subroutine # 3 as it is called task # 5, even though it is more important logic than the remaining logic of task # 5, so it has priority of [5] . For this reason, the execution of the subroutine # 3 must be stopped for the execution of the less important task # 4 or subroutine # 6.

Of course, in order to prevent this situation in advance, the priority of task # 5 may be set to a higher priority than [5], but in addition to subroutine # 3, the overall logic of task # 5 does not require high priority In case this setting is wasteful. At this time, the overall logic of task # 5 is performed with the priority of [5], but a scheduling method that can be performed with priority of only subroutine # 3 [3] is needed.

In the example of FIG. 5B, as in the example of FIG. 5A, it can be seen that there is a request of the interrupt # 4 having the priority of [4] during the execution of the task # 5 having the priority of [5]. First, at the time t7, the request 135 of the task # 5 comes in, and the logic and the subroutine of the task # 5 are being executed. When the request 137 of the interrupt # 4 occurs at the time t8 during the execution of the subroutine # 3 of the task # 5, since the priority of the interrupt # 4 is higher than the priority of the task # 5, The execution is suspended for a while. Instead, context switching occurs with interrupt # 4 having a higher priority and context switching occurs again after the execution of subroutine # 6 of interrupt # 4 is completed, Subroutine # 3 and logic are then executed.

At this time, as in the case of 5a, there occurs a situation in which the execution of the logic that needs to guarantee the priority is suspended due to the less important task or interrupt request due to the priority inherited from the task. That is, if you are performing an important subroutine in a task with a lower priority and you want to perform a less important subroutine in a task with a higher priority, you can simply create a problem due to scheduling based on task priority .

6 through 7 are flowcharts of a method for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.

Referring to FIG. 6, in order to enable the task to perform logic with different priorities, the logic is executed at the start of the task (S1100). The logic performed here may be omitted, if necessary, by the preprocessing logic before being called into the subroutine.

If it is determined that the subroutine is to be executed in step S1200, it is determined whether the subroutine is a subroutine requiring priority assurance. In the case of a subroutine requiring no guarantee of priority, the subroutine is called by the task as in the conventional case, and the subroutine is inherited from the priority of the task (S1310). On the contrary, in the case of a subroutine requiring priority guarantee, the task does not directly call the subroutine, but artificially generates an interrupt (S1360) and executes the subroutine in such a manner that the subroutine is called again in the corresponding interrupt ( S1370). Since interrupts artificially generated in a task have priority only for interrupts separately from tasks, a subroutine called in an interrupt can have a different priority from a task.

After the execution of the subroutine called by the interruption 1370 or the task 1310 by the interrupt is completed, the remaining logic of the task is executed (S1400). However, the postprocessing logic here may be omitted as needed, such as the preceding preprocessing logic. That is, in some cases, it may be possible to generate an interrupt without performing another logic in a specific task, to perform only a specific subroutine in the interrupt, and to terminate the task itself.

Of course, this will not work if a specific task executes only a specific subroutine through an interrupt and does not execute another logic. The purpose of executing a specific subroutine through an interrupt is to perform a specific subroutine with a different priority than the rest of the task's logic. That is, in the case of FIG. 5A, the general logic of the task # 5 is performed with the priority of [5], while the subroutine # 3 uses the interrupt to perform the priority of [3].

We have also seen in FIG. 3a that a plurality of subroutines can be executed in one task. In FIG. 6, only one subroutine is described as generating an interrupt for priority assurance, but in some cases, multiple interrupts may be sequentially generated in one task to execute several subroutines It will be possible. That is, it is also possible to separate a plurality of logic tasks according to their priorities and to schedule them in a manner of executing subroutines through various interrupts.

Referring to FIG. 7, the task is divided into a plurality of logic (S2100). It divides the general logic to be executed by inheriting the priority of the task as it is and the specific logic that needs to guarantee the priority to be performed with higher priority than the priority of the task. The remainder excluding the selected specific logic may be performed as general logic in step S1100 or S1400 of FIG. 6 based on the before and after the subroutine.

After the task is divided into a plurality of logic, the specific logic to be executed through the interrupt is selected from those tasks (S2200). The specific logic to be executed through the interrupt must be logic that is important enough to be performed at a higher priority than the priority of the task. There are several criteria for determining whether a particular logic is important or not.

For example, it is possible to determine whether or not to sort by comparing the execution time of the specific logic among the total execution time of the task. If it is a particular logic that takes less than the preset threshold of execution time of a task, it may be useless to perform it through an interrupt. Rather, there may be a case where an interrupt is generated and a loss due to an overhead due to a call of a subroutine is greater in the process of executing the specific logic by using the interrupt.

Likewise, it is possible to compare the resource consumption of the particular logic against the total resource consumption of the task to decide whether or not to select it. This is because, if the specific logic occupies less than a preset reference value in the entire resource consumption of the task in consideration of the usage rate of the processor or the memory usage rate, it can be determined that the importance is relatively low.

On the other hand, it is possible to judge whether the task is selected based on the difference between the priority of the task and the priority to be performed by the specific logic. If the difference between the task priority and the priority to be performed by the specific logic is less than the preset reference value, there may be a small disadvantage that may occur even if the specific logic is not performed with a separate priority through the interrupt. In other words, if the priority of the task is guaranteed to some extent, it will not be necessary to perform it through the interrupt.

Based on the other scenario, it may be judged whether or not to screen. As mentioned earlier, the subroutines themselves are not prioritized, but subroutines are intended to eventually perform specific logic and may be of varying importance depending on the logic. Therefore, it is necessary to define priority by converting the priority of the subroutine into priority in advance according to the scenario, and to judge whether the subroutine is selected by using it.

For example, if subroutine # 3 is defined as a subroutine to be executed with priority of [3], task # 4, task # 5, and task # 6, the call is made using interrupt # 3 when subroutine # 3 is called. Of course, in the case of Task # 1, Task # 2, and Task # 3 having a priority higher than or equal to [3], the scenario will not be applied.

These scenarios can be pre-configured by the designer of the embedded operating system on the embedded operating system. That is, by using such a scenario, the embedded OS can actually obtain the effect of defining and managing priorities in tasks, interrupts, and subroutines. In this way, subroutine-dependent priorities can be defined and managed by scenarios.

After the specific logic to be executed through the interrupt is selected, a separate interrupt is forcibly generated in order to execute the specific logic (S2300). Interrupts generated at this time are interrupts with higher priority than tasks, and perform the specific logic on behalf of the task. That is, in order to perform the specific logic within a task, an interrupt is generated instead of performing the specific logic directly in the task, and the specific logic is executed through the subroutine call in the interrupt. If the specific logic is executed in a separate interrupt via a subroutine call, it can have a priority different from the task.

After preparation of the interrupt is completed, a specific subroutine is called through the corresponding interrupt (S2400). This particular logic will then be executed with a higher priority than the task, so that it will be less likely to be stopped by another task or interrupt with a higher priority.

Through FIG. 6 to FIG. 7, a priority assurance method for performing a specific logic with a priority higher than a priority of a task has been described. However, in some cases, an interrupt having a lower priority than the priority of the task may be used to perform specific logic even if the task is performed at a lower priority than the priority of the task. That is, through the present invention, a plurality of logic included in a task can be performed with a priority different from that of the task, so that each logic of the task can be performed through interruption by appropriately adjusting the priority according to the priority will be.

8 is a pseudocode explaining a method for assuring the priority of logic in an embedded operating system according to an embodiment of the present invention.

Interrupt refers to a series of processes in which an unexpected special situation occurs during the execution of a task to stop the task, process the special situation first, and then return to the original task and continue the remaining tasks. Types of interrupts include hardware interrupts and software interrupts. Among them, it is possible to generate interrupts that are artificially different from the task through software interrupts and can be executed by calling specific subroutines through interrupts.

Referring to FIG. 8, the modified pseudo code 109 of task # 5 generates interrupt # 3 artificially instead of calling subroutine # 3, and executes subroutine # 3 through interrupt # 3 Can be seen. When subroutine # 3 is executed in this way, task # 5 can be executed with priority of [3], even if it has priority of [5].

9A and 9B are diagrams for explaining a method for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.

In the example of FIG. 9A, it can be seen that, during execution of task # 5 having the priority of [5], there is a request of task # 4 having the priority of [4]. First, at the time t9, the request 141 of the task # 5 comes in and the logic of the task # 5 is being executed. Here, when the logic of the task # 5 is performed and the execution of the subroutine # 3 is required, a separate interrupt # 3 is generated instead of the subroutine # 3 in the task # 5 to execute the subroutine # 3 in the interrupt # 3 . When the request 143 of the task # 4 occurs at the time t10 during the execution of the subroutine # 3, the priority of the task # 4 is higher than the priority of the task # 5, but is lower than the priority of the interrupt # 3 Interrupt # 3 continues without interruption. Instead, the context switching occurs only after the execution of the subroutine # 3 of the interrupt # 3 is completed, and the execution of the task # 4 and the subroutine # 6 is started. Then, after the execution of task # 4 and subroutine # 6 is completed, context switching again occurs, and the remaining logic of task # 5 is executed subsequently.

Compared with FIG. 5A, it can be seen that the important subroutine # 3 continues to run without interruption, despite the request of task # 4. That is, if subroutine # 3 is executed using an interrupt, at least subroutine # 3 can be prevented from being stopped by a task or an interrupt having a lower priority. Of course, even if subroutine # 3 is executed in this way, since the remaining general logic of task # 5 is basically performed according to the priority of task # 5, when the execution of subroutine # 3 is finished, the remaining logic of task # Instead, the logic of task # 4 and subroutine # 6 are performed. That is, the object of the present invention is to make only certain logic in a task have a separate priority. If you want to change the priority of all logic in a task, it is enough to change the priority of the task itself.

In the example of FIG. 9B, although the subroutine is executed using the interrupt, it can be seen that the subroutine is stopped by the task having the higher priority. That is, during the execution of the subroutine # 3 of the interrupt # 3 having the priority of [3], when the request of the task # 2 having the priority of [2] comes in, the subroutine # 3 is stopped. After the execution of task # 2 and subroutine # 2 is completed, the remaining subroutine # 3 through context switching is performed, and the remaining logic of task # 5 is executed again. That is, even if a subroutine is executed by an interrupt, it has a different priority from a task, and does not always guarantee that a subroutine executed through an interrupt always has the highest priority.

10 is a hardware configuration diagram of an apparatus for assuring priority of logic in an embedded operating system according to an embodiment of the present invention.

10, a logic priority assurance device 10 in an embedded operating system may include a processor 510, a memory 520, a storage 560, and an interface 570. The processor 510, the memory 520, the storage 560, and the interface 570 transmit and receive data via the system bus 550.

The processor 510 executes a computer program loaded into the memory 520 and the memory 520 loads the computer program from the storage 560. [ The computer program may include a task partitioning operation 521, a specific logic sorting operation 523, an interrupt generation operation 525, and a subroutine call operation 527. [

The task partitioning operation 521 can divide the task into a plurality of logic pieces by referring to the task information 561 of the storage 560. [ Through this, it is possible to select general logic to be executed by inheriting task priority and specific logic that needs priority guarantee.

The specific logic sorting operation 523 can select important logic based on the execution time of the logic, the resource consumption, the priority required to execute the corresponding logic, and the like for each logic divided by the task division operation 521. [

The interrupt generation operation 525 may be performed in the task such that it can be performed by inheriting the priority of the interrupt 563 instead of inheriting the priority of the task for the specific logic selected in the specific logic selection operation 523. [ And generates a separate interrupt 563 at the time when the selected logic is executed. The interrupt 563 generated at this time is characterized in that it has a higher priority than the task as an interrupt 563 for assuring the priority of the specific logic.

The subroutine call operation 527 refers to the subroutine 569 of the storage 560 and calls the specific logic through the interrupt instead of performing the specific logic in the task. This can at least reduce the situation in which certain logic stops executing due to other tasks or interrupts.

Each component in FIG. 10 may refer to software or hardware such as an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit). However, the components are not limited to software or hardware, and may be configured to be addressable storage media, and configured to perform one or more processors. The functions provided in the components may be implemented by a more detailed component, or may be implemented by a single component that performs a specific function by combining a plurality of components.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, You will understand. It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive.

Claims (7)

Dividing a task into a plurality of logic in an embedded operating system;
Selecting specific logic among the plurality of logic to be executed with a second priority higher than a first priority of the task;
Generating an interrupt having the second priority during the execution of the task; And
And calling the selected specific logic in the interrupt into a subroutine.
How to prioritize logic in embedded operating systems. The method according to claim 1,
The step of selecting the particular logic comprises:
And comparing the execution time of the task with the execution time of the specific logic,
How to prioritize logic in embedded operating systems. The method according to claim 1,
The step of selecting the particular logic comprises:
Comparing the resource consumption of the task with the resource consumption of the particular logic to determine whether the task is to be sorted;
How to prioritize logic in embedded operating systems. The method according to claim 1,
The step of selecting the particular logic comprises:
Comparing the difference between the first priority of the task and the second priority to which the particular logic is to be executed,
How to prioritize logic in embedded operating systems. The method according to claim 1,
The step of selecting the particular logic comprises:
And determining whether to screen based on the scenario set in the embedded operating system.
How to prioritize logic in embedded operating systems. The method according to claim 1,
The generating of the interrupt having the second priority may include:
Excluding the particular logic in the task;
And generating the interrupt at a time when the excluded specific logic is to be performed in the task.
How to prioritize logic in embedded operating systems. Interface and processor;
A memory for loading a computer program executed by the processor; And
Includes storage that stores tasks, interrupts, and subroutines,
The computer program comprising:
Dividing the task into a plurality of logic in an embedded operating system;
Selecting from among the plurality of logic specific logic to be executed at a second priority higher than the first priority of the task;
Generating an interrupt having the second priority while the task is being executed; And
And calling the selected specific logic in the interrupt into the subroutine.
A device for guaranteeing logic 's priority in an embedded operating system.

Images