1. Field of the Invention
The invention relates to micro control units (MCU), and in particular to an embedded system handling interruption requests with priority control.
2. Description of the Related Art
FIG. 1 shows a conventional embedded system, in which a processor 110 is interruptible to provide particular services. For old type processor chips such as 8051 or ARM7, only a few ports, e.g. 2 ports, are implemented to receive interruption requests. In practice, the ports are referred to as #IRQ and #FIQ according to the specification. An interruption request asserted on the ports #IRQ of #FIQ may be originated from various events each requesting a different service routine. A plurality of events may simultaneously occur, and status registers 102 and 104 respectively associated to the ports #IRQ and #FIQ are provided to represent statuses of each event. Every bit (or may be byte) R0 to Rn in the status registers 102 and 104 may represent whether a particular event is requesting a service routine. When an event occurs, the status registers 102 or 104 is modified, and the interruption request is sent to the processor 110 as a trigger. The events may be defined with different priorities based on their importance, and conventionally, the priorities of the events are equal to precedence of the bits R0 to Rn where their statuses are stored.
The embedded system further comprises an interruption vector table 120 coupled to the processor 110, comprising two fields 122 and 124 each storing a branch instruction. For example, when an interruption request #INTa is asserted on the port #IRQ, the processor 110 suspends its current operation to execute the branch instruction in the IRQ field 122. Likewise, when the port #FIQ receives an interruption request #INTb, the processor 110 is interrupted to execute the branch instruction in the FIQ field 124. A branch instruction is typically a jump command followed by a destination address, acting as a program launcher that leads the processor 110 to access and execute a particular program in a memory device 130. As described, an interruption request may be asserted by various events, thus a determination mechanism is required before a corresponding service routine can be initialized. Specifically, the particular program referred by the branch instructions in the interruption vector table 120 is a priority control program for handling the events. The priority control programs 132 and 134, along with a plurality of service routines 136 each serving an event, may be provided by firmware or operating system and stored in the memory device 130. When an interruption request is received by the ports #IRQ or #FIQ, the processor 110 executes a corresponding branch instruction in the fields 122 or 124 to load the priority control program 132 or 134. By executing the priority control programs, statuses of the events recorded in the status registers 102 and 104 are sequentially scanned to accordingly trigger related service routines 136.
FIG. 2 is flowchart of conventional service routine executions. In the flowchart, a priority control program is executed to identify the source event which asserts the interruption request. In practice, the bits R0 to Rn in the status register 102 or 104 are recursively scanned. Since one of the bits R0 to Rn represents status of one event, if one of the bits is found asserted, a corresponding service routine 136 is loaded for execution. In step 200, the priority control program is initialized to scan the status register 102 or 104. In step 202, the first bit R0 is scanned, determining whether a first event is requesting a first service routine. If so, step 212 is processed, the first service routine is executed. Otherwise, a next bit is scanned in step 204. When the execution of first service routine in step 212 is completed, the process may go to step 204 for a next bit scanning, or loop back to step 202 via the dot line 299 to start over the scanning. In step 204, a second bit R1 is likewise scanned, whereby a second service routine may be triggered in step 214 if a positive value is detected in the second bit R1. Similarly, when step 214 is completed, a next bit scanning may further be proceeded, or alternatively, the scanning process may be reset to go back to step 202. The scanning and execution repeat until all bits in the status register 102 or 104 are scanned.
The described method for handling interruption requests is typically a software based implementation. The branch instructions 122 and 124 are executed by the processor 110 upon the ports #IRQ and #FIQ are respectively asserted by events, and consequently, the priority control programs 132 and 134 are executed by the processor 110 to scan status register 102 and 104. In this way, a service routine corresponding to the source event can be found and executed. Priorities of the events are simply defined by precedence of their corresponding bits in the status register 102 and 104, and the priority policy can be flexibly modified by redefining different scanning order in the priority control programs 132 and 134. The software based implementation, however, is deemed ineffective as it consumes processor resources. More than that, when a large number of interruption requests are simultaneously asserted, services routines of lower priority may be infinitely put off that causing undeterminable system dead lock. Hence an enhancement is therefore desirable.
USPTO Backgrounds
USPTO Backgrounds