WO2012019627A1

WO2012019627A1 - Device and method for executing applications under real-time conditions in an embedded system

Info

Publication number: WO2012019627A1
Application number: PCT/EP2010/004920
Authority: WO
Inventors: Wolfgang Hartmann; Karl-Heinz Krause
Original assignee: Siemens Aktiengesellschaft
Priority date: 2010-08-11
Filing date: 2010-08-11
Publication date: 2012-02-16

Abstract

Embedded systems operate in numerous application areas and devices. Even if there are hard real-time requirements for a computer deployment in the embedded field depending on the deployment and application, tasks without real-time requirements must also be processed in large volume. The aim of the invention is to specify a method that enables in particular Linux to be deployed on a two-kernel system for real-time requirements. Practically every interrupt controller has the ability to deactivate each individual interrupt. This is realized by a mask register, which is located between the interrupt request register and the CPU. Occurring interrupts are stored or delayed until the mask is lifted. Said ability is commonly used for protection (e.g., masking unconnected interrupt lines) or by special device drivers (e.g., for overlapped work between a device and an ISR). The use of said hardware function for the interrupt logging of a two-kernel solution is novel. If the real-time domain is always active (processing of real-time ISR or real-time threads), all Linux interrupts are masked.

Description

description

Apparatus and method for executing applications under real-time conditions in an embedded system

Field of the invention

The term "embedded system" refers to an electronic computer or computer that is embedded (embedded) in a technical context. The computer either has the task to control the system in which it is embedded, to control, to monitor or the computer is responsible for a form of data or Signalverarbei device, for example, during encryption or decryption, coding or decoding or filtering.

Embedded systems perform the service in a wide variety of application areas and devices - largely invisible to the user. Often embedded systems are specially adapted to a task. Such a design combines the great flexibility of software with the performance of the hardware. The software serves both to control the system itself and, if necessary, to interact with the outside world via defined interfaces or protocols.

Even if computer applications in the embedded sector are based on hard real-time requirements depending on the application and application, tasks without real-time requirements are also required to be processed on a larger scale.

The diversity of these tasks and the support of many computer architectures established in the embedded sector make Linux, for example, a preferred operating system. Unfortunately, the Linux kernel is not suitable for tasks with very hard real-time requirements. Background Art The problem is usually solved by the use of a second kernel embedded in the Linux kernel. This second core manages the tasks that must meet hard real-time requirements. In particular, long-running Interrupt Service Routines (ISRs) (by Linux) and long-running interrupt locks (by Linux) must not delay the processing of real-time ISRs or real-time tasks so that these can be met. For this purpose, for Linux certain interruptions (interrupts) once only noticed (interrupt logging). That is, instead of the original Linux interrupt routine, a short ISR occurs, setting only a corresponding flag bit, for example.

On the other hand, Linux interrupts are mapped to an S-lock bit for Linux. Once all real-time activities have ended, Linux will continue to run. Only if the SW-Lock bit for Linux is not set, the memory bits are also processed, d. H. running the appropriate original ISRs from Linux.

Even the short interruptions for setting the flag bit (logging ISRs) cause a delay in real-time processing. In particular, when several such activities are immediately following each other, and when the processor is not very fast.

It is an object of the invention to specify a method which makes it possible to use Linux on a two-kernel system for real-time requirements while avoiding the disadvantages outlined above. Presentation of the invention

This object is achieved by a device according to claim 1. The device for executing at least one application even under real-time conditions in an embedded system comprises a first computer kernel for processing applications and a second computer kernel in particular for processing tasks within the application under real time conditions , wherein the second computer kernel is embedded in the first computer kernel. The apparatus further comprises means for storing interrupt requests occurring during the execution of the at least one application, and means for checking the interrupt requests stored in the means for storage. Forwarding of the interrupt request occurring during the execution of the at least one application and intended for the first computer core can be blocked with the aid of at least one suitable filter mask if the at least one task is being executed under real-time conditions.

The object is further achieved by a method according to claim 6. The method for performing at least one application even under real time conditions runs on an embedded system containing at least a first

Computer kernel and at least a second computer kernel in particular for processing tasks under real-time conditions from, wherein the second computer kernel is embedded in the first computer kernel. An interrupt request occurring during the execution of the at least one application is stored and the stored interrupt request is checked. Then, a forwarding of the interrupt request occurring during the execution of the at least one application and determined for the first computer core is blocked with the aid of at least one suitable filter mask, provided that the at least one task is executed under real-time conditions.

The above drawback can be avoided by using the (HW) interrupt controller for interrupt logging.

An interrupt controller is the functional unit in the computer that is responsible for receiving and distributing the interrupts.

Virtually every interrupt controller has the ability to disable ("disarm") each individual interrupt, realized by a mask register located between the interrupt request register and the CPU.

Incoming interrupts are thus stored or delayed until the masking is canceled again. This capability is typically used to secure (eg masking unconnected interrupt lines) or special device drivers (eg for overlapping between device and ISR).

What's new is the use of this hardware function for the interrupt logging of a two-core solution. Whenever the real-time domain is active (processing real-time ISR or real-time threads), all Linux interrupts are masked.

Further advantageous embodiments are described in the subclaims.

A Linux interrupts lock must also be mapped to the masking of all Linux interrupts. The implementation must, however, take into account that interrupt masking can be changed within interrupt inhibits. For this, another interrupt mask, the so-called "shadow_mask", is introduced The "shadow_mask" is an image of the HW mask register, which is only needed if the Linux interrupts are disabled and with unmask (irq) the interrupt masking of one Interrupt request is canceled. This must not be done in the HW mask register in this situation, otherwise a Linux interrupt would be unlocked within the Linux interrupts, but will be noted in the "shadow_mask." If the Linux interrupts are canceled afterwards, then the "shadow_mask loaded into the HW mask register.

The Linux routine unmask (irq) only changes the "shadow_mask" and only when the interrupt is cleared with local_irq_enable () is the mask register loaded with the value of shadow_mask.

Furthermore, it must be taken into account that when ISR processing is started, the interrupts are already set to HW for Linux ISRs as well. In order to achieve unambiguity or uniformity (eg for the implementation of the function irqs_disabled ()), an additional stable bit (SW lock bit) is used. An additional stable bit also leads to a performance gain, ie an acceleration of the processing of the application. Unnecessary changes of interrupt masking can thus be avoided. In particular, when the interrupt masking comprises a plurality of mask registers, this is particularly relevant.

These measures can be used to completely avoid a delay in realtime processing by Li nux ISRs and Linux interrupts with minimal changes to the Linux code. Description of the preferred embodiments

BRIEF DESCRIPTION OF THE DRAWINGS The invention is explained below on the basis of exemplary embodiments. Show

Figure 1 is a schematic representation of the hardware, Figure 2 is a flowchart.

FIG. 1 shows a schematic structure of the device according to the invention. In a first computer core, Linux kernel is another core of computers, realtime kernel, embedded. All interrupt requests arrive through a register that can be used to store interrupt requests, an interrupt request register. By means of a suitable masking of the interruptions by means of an interrupt mask register, only such interrupt requests to the real-time computer kernel are transmitted when real-time critical applications expire, all further interrupt requests which are "only" intended for the Linux kernel are first stored in the register and retrieved at a later date.

The determination of the interrupt by the IR controller prologue is shown in Figure 2, 11, it is hardware-specific but unmodified Linux code, usually written in assembler. The lock state of the suspended state is saved to the stack. Only if the Linux interrupts were not locked, 12, it is necessary to set the interrupt masking, 21. For interrupt processing, a distinction must be made between a Linux interrupt, 31, and a real-time interrupt, 14. For this, a table entry of the "Linux interrupt table" has been extended by one element. This element is a function pointer to a "real-time ISR". One valid function pointer (! = NULL) means that a real time processing has been set up for this interrupt, 15.

The execution of the RT-ISR may have triggered the awakening of a (higher-priced) real-time thread. If necessary, switch to processing of the awake real-time thread with a check "Check for RT-Preemption", 17. It should be noted that until then the entire sequence runs under central interrupt lock, and is not until the beginning of the thread processing The release of the intrinsic controller, 16, could thus also take place earlier.At the end of the real-time processing, branching takes place due to the blocking state of the interrupted state, 18 ,.

- if the interrupted state was already blocked (Linux interrupt disable or RT thread execution was interrupted), the "interrupt state" is left directly, 19

- If the system returns to the unlocked Linux state, then the interrupt mask register is loaded with the current state (s adow_mas / and the "interrupt state" is exited via the standard Linux Interrupt Epilog, 43, 52. The real-time activity may also result in notification of Linux via so-called virtual interrupts (VIRQs), 42. The treatment of such pending VIRQs occurs before the epilogue, 43.

Claims

claims

Device for executing at least one application even under real time conditions in an embedded system

with a first computer kernel (Linux kernel)

and a second computer kernel (realtime kernel) for processing tasks under real-time conditions, wherein the second computer kernel is embedded in the first computer kernel, with

Means for storing (IRR) interruption requests occurring during the execution of the at least one application, and

Means for checking (IMR) the interrupt requests stored in the means for storing (IRR), wherein a forwarding of the interrupt request occurring during the execution of the at least one application and determined for the first computer core can be blocked by means of at least one suitable filter mask provided that at least a task is being executed under real-time conditions.

Device according to claim 1,

characterized in that

the at least one filter mask can be deactivated and stored interrupt requests can be forwarded provided that there are no tasks for execution under real-time conditions.

Device according to claim 1 or 2,

characterized in that

the at least one filter mask contained in the means for checking (IMR) the occurring interrupt requests is changeable. Device according to one of the preceding claims, characterized in that

the means for storing (IRR) interrupt requests occurring during the execution of the at least one application comprises a table and

the table contains one extra field per interrupt request entry,

in which a function pointer can be stored, which refers to a processing routine for the associated interrupt requests.

Device according to one of the preceding claims, characterized in that

the means for checking comprises a masking register located between the means for storing the interrupt request register and the CPU comprising the at least first and at least second computer kernel.

Method for executing at least one application even under real time conditions on an embedded system containing at least a first computer kernel (Linux kernel) and at least one second computer kernel (realtime kernel), in particular for processing tasks under real time conditions, wherein the second computer kernel is embedded in the first computer kernel , in which

an interrupt request occurring during the execution of the at least one application is stored, and

the stored interrupt request is checked, wherein a forwarding of the interrupt request occurring during the execution of the at least one application and determined for the first computer core is blocked by means of at least one suitable filter mask if the at least one task is being executed under real-time conditions. Method according to one of the preceding claims, characterized in that

the at least one filter mask is deactivated, and stored interrupt requests are forwarded unless there are tasks to perform under real-time conditions.

Method according to one of the claims 1 to 3, characterized in that

the at least one filter mask contained for checking (IMR) of the occurring interrupt requests can be changed.

Method according to one of the preceding claims, characterized in that

the interrupt requests occurring during the execution of the at least one application are stored in a table and

the table contains an additional field per interruption entry,

for a function pointer, which points to a processing routine for the associated interrupt requests.