JPS62160537A - Interrupt processing - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

DETAILED DESCRIPTION OF THE INVENTION A. Field of Industrial Application This invention relates generally to data processing systems, and more particularly to interrupt systems for processing priority interrupt requests.

B. Prior Art The processor of a typical data processing device is frequently required to perform various tasks or events within the device.

A task may be external to the processor or internal to the processor. External tasks are usually associated with external events. Such events include reading external sensors, receiving data from communication channels, and the like. Internal tasks include extracting states following completion of internal counters, etc.

In addition to the specified tasks, processors typically perform certain functions (sometimes referred to as background functions) when their services are not needed to process the specified tasks.

Common processors typically operate at electronic speeds.

Therefore, the processor itself requires relatively short time intervals to complete its assigned tasks. Similarly, a processor can perform multiple tasks within a very short time interval. Despite its speed, processors are serial devices. There are several tasks that require immediate attention when an event occurs that triggers a condition in which only one task can be performed during a particular time interval. For example, real-time peripherals typically require immediate attention. The situation is further complicated because most real-time peripherals operate asynchronously with the execution of background code. That is, the processor cannot predict the exact time that these devices will require service.

An interrupt system is provided to increase the flexibility of the processor. The interrupt system includes several prioritized interrupt levels.

Users typically report one or more events at interrupt level 1.
Assign to. An interrupt request is submitted each time an event occurs. Depending on the level of the interrupt, the processor either continues executing the code it was executing when the new interrupt occurred or stops processing that record and
Branching to new code that must be executed to service the new interrupt. If the interrupt request is at a higher level than the one currently executing, the processor branches to execute new code. When it finishes, the processor returns and executes the pre-branch code (i.e., the original code).6 On the other hand, if the interrupt request is at the same or lower level than the one currently executing, the processor Queue the interrupt request and continue executing your current code. There are some events that require immediate response.

Queuing is not a sufficient solution6 It is the queuing problem that the present invention seeks to improve.

Several interrupt systems have been described in the prior art. The disclosed system or configuration is:

All are aimed at improving the efficiency of the processor for handling interrupts. For example, U.S. Pat.
No. 1783, No. 4028664, No. 417228, and No. 3905025 describe several apparatus and methods for prioritizing the servicing of events at respective interrupt levels of a processor interrupt hierarchy.

Other prior art patents, such as U.S. Pat. It is being

SUMMARY OF THE INVENTION It is therefore a general object of the present invention to provide a method that allows a processor to perform prioritized tasks at a single interrupt level without queuing multiple interrupt requests. It is about providing.

Means to Solve the D0 Problem This method works as follows. If an interrupt occurs during the execution of background code (ie, code that services a lower priority task), the processor branches to execute the code that services the event that caused the interrupt. To minimize the time spent in the 6 interrupt levels where the address of the background code's location at the time of the interrupt is saved on the stack, two instructions are used: (a) “C
a1lSub-routine” (call) and (b
) ”Returnform Interrupt
” (RE T I ) is executed at interrupt level.

Execution of a calling instruction saves the next sequential address of the instruction to be processed on the top stack in a background location. In this particular situation the position of the interrupt level is saved on the stack.

Execution of the RET instruction takes the interrupt level location from the top of the stack and loads it into the program counter (P, C,).

The processor then executes a service routine starting at the address (location) in P,C,. Note that the RETI instruction clears the source of the interrupt (ie, resets all fluffs, etc.). The service routine (ie, code) associated with that interrupt executes at a background level, and the processor is now free to accept new interrupt requests of the same interrupt level. New interrupt requests are serviced immediately.

Finally, a return (RET) instruction is executed when the service routine that handles the interrupt request is completed. This causes the original background location to be taken off the stack and placed in the program counter, thereby allowing the processor to continue executing the background code.

E. EXAMPLE The invention described below can be used to prioritize interrupt requests in any type of data processing system. Since the invention works well in a store system, it will be described in that environment. However, since it is well within the skill of those skilled in the art to make minor changes to the present invention or apply the present invention to any computing system, the foregoing should be construed as limiting the scope of the present invention. should not do.

FIG. 1 shows the electrical blocks of the data processing system 10.
Show diagram. Data processing system 10 may be used in stores, retail stores, etc., such as to calculate customer purchases. The data processing system includes a microcontroller or microcomputer 12. As aforementioned.

Any kind of microcomputer can be used. However, in the preferred embodiment of the invention, the microcontroller is an Intel 8051 microcontroller. The 8051 type microcontroller is a well-known off-the-shelf microcomputer,
Therefore, the details will not be explained here. If you want to know more about this microcontroller, please refer to the Int.
You may want to refer to e1 company's materials. In the present invention,
The 8051 type microcontroller can be configured to perform multiple input/output functions and provide communication between each function and a remote computing device. This microcomputer has two interrupt levels. Each input/output device and communication channel that requires immediate attention must interrupt the microcontroller at one of these levels. If the interrupt is accepted, the microcontroller aborts the current job and executes code for the microcontroller to service the device that accepted the interrupt. Since the 8051 controller has only two interrupt levels, interrupts from each input/output device and communication channel must be bound to one of the interrupt levels. In other words, multiple interrupts must be serviced at one interrupt level.

Continuing to refer to FIG. 1, the input/output device includes a magnetic stripe reader (MSR) (not shown). The magnetic stripe reader is connected via connector 14 to network 16 and via conductors 18 and 20 to pins 05 and 12 of the microcontroller. Magnetic stripe readers can be used to read magnetic information such as credit cards. pin 12
The signal on top is the strobe signal and the signal on pin 05 is the magnetic stripe reader data (MSRDAT). For example, when a strobe signal is activated, the microcontroller is interrupted. If the interrupt is accepted by the processor within the microcontroller, the data on pin 05 is accepted.

connector 22, and pin 13 of the microcontroller
．． Modules 24 and 26 on 10.15 and 11 provide communication functionality. The received signal is provided on pin 10 and the transmitted signal is provided on pin 11. Each module (22, 24 and 26) is coupled by a decoupling network to the voltage supply +5 and to ground, respectively. Signals from a communication channel (not shown) are received via connector 22 and amplified by module 24. Texas Instruments
) driver module part number 75176 is suitable as a driver module. Signals from module 24 are sent to module 26.

Module 2.6 is an exclusive OR module and Te
This can be achieved by a module part number 74LS86 manufactured by XAS Instruments.

The administrator keylock 28 is detected by a lever switch 30 and sent via lead 32 to pin 03 of the microcontroller. The microcontroller scans the keylock switch from background mode. Crystal 34 is coupled via conductive wires to pins 18 and 19 of the microcontroller. Similarly, a watchdog module 36 is coupled to pins 04 and 09 of the microcontroller (crystal 34 is not an interrupt source; watchdog circuit 36 is used to reset the microcontroller). Generator 38
is controlled by an internal timer interrupt and module 4
0 to pins 01 and 02 of the microcontroller 12. Module 40 is a high current driver and provides current to the alarm generator via network 42. Any off-the-shelf high current driver module can be used for module 40. In a preferred embodiment of the invention, the Texas Instrument
The module part number 75451 manufactured by S Company (TI) is used.

Pins 3o and 32-39 of microcontroller 12 are connected to static RAM 41 and latch 44.
used to interconnect the microcontroller. Both RAM 41 and latch 44 are conventional devices and will not be described in detail. Static RAM and latches are connected to a common data line. In this configuration, the RAM address is first output on those lines and latched into latch 44. After latching up the address output on the bus, the data is then sent to RAM.

The microcontroller can access the keyboard from background mode.
Scan assembly 46. The keyboard assembly is coupled to pins 25-28 of the microcontroller via a 4-16 decoder module 48. The return signal from the keyboard 46 is connected to the resistive network R
A to pins 21-24 of the microcontroller. As explained later in the preferred embodiment of the invention, the code that monitors keystrokes is executed at the background level of the controller. Every time an interrupt occurs,
The processor temporarily branches from this code to service the interrupt. The LED portion of the keyboard is routed through the LED driver module 50 to pins 06.07.08 and 14 of the microcontroller. Another interrupt source not shown in FIG. 1 is an interrupt caused by an internal source. Such an internal source may be a timer. Generally, timers are set to generate interrupts at specific time intervals. Once a certain time interval has elapsed, the timer immediately generates an interrupt, forcing the microcontroller to branch from the then executing code to examine the new event. Typically, the microcontroller must execute a new set of code to service the new event.

FIG. 2 shows a conceptual diagram of a microprocessor and the events or input/output devices controlled by it. Some of these input/output devices require support at the interrupt level. To simplify the description of the invention, elements in FIG. 2 that are common to elements in FIG. 1 are designated by the same reference numerals. Reference number 12 represents the microprocessor running the background code.

As mentioned above, the background code includes the keyboard 46, the LED
45, used to monitor the administrator key lock 28 and RAM 41. Sources that can submit interrupts to force the microprocessor to branch include the serial communication channel 22, internal timer interrupts 52 (including the tone generator 38), and the magnetic stripe reader 14. This is striped data. Note that these interrupts are asynchronous to the background code. Interrupts are asynchronous because any input/output device can have its interrupt request line activated at any time. Furthermore, the microprocessor cannot predict when any of these interrupt request lines will be asserted.

FIG. 3 is a flowchart conceptually illustrating a simple technique for handling interrupt requests. Since interrupt requests are asynchronous in nature, it is inevitable that two or more interrupt requests with the same priority will require servicing during the same time interval. In short, once a processor accepts an interrupt request and begins executing code to service that interrupt, it will not accept another interrupt until it has finished processing that code. New interrupt requests are queued and wait for service. This situation is shown in Figure 3.

``The column marked Background level J is the background code (i.e.
The second column labeled "Interrupt Level" represents the level at which the records for servicing interrupt requests are being executed.

This level is also called the foreground level. "stack"
The third column, labeled , represents the storage area to which the microprocessor transfers the program address each time an interrupt request is accepted. In other words, each time the processor branches, the next sequential address in the program before the branch is stored on the stack. The address is held in the program counter (pc). Upon finishing execution of the code that services an interrupt by storing the contents of the program counter on the stack, the processor can resume at the next sequential address in the program that was being executed when the interrupt occurred. Finally, the direction of the arrow in FIG. 3 indicates the direction of program flow.

That is, arrow 52 indicates that the processor is executing code at background level when interrupt request 1 occurs at arrow 54. Interrupt request 1 is detected by the 8051 hardware. The processor finishes the background instruction it was processing at the time of the interrupt (block 56). As indicated by arrow 58, program control is transferred from the background level to the interrupt level. In other words, at block 60, the program branches from the background code to execute the code of Service Routine 1. Additionally, the background address in the program counter (pc) is placed on the stack, as indicated by arrow 62. It should be noted that the stack was empty before stacking the background address at arrow 62, as indicated by arrow 64.

If interrupt request 2 (arrow 66) is detected during execution of service routine 1 at block 60, the interrupt is requested or delayed until execution of the code of service routine 1 is completed. The program then descends to block 68. At block 68, the program returns “Return fr
om Interrupt" (RETI). Since this is a standard 8051 instruction, we will not show the details. The function that this instruction performs is only 1" as shown in block 70. In short, interrupt Control is transferred to the service routine for servicing request 2. When the code servicing interrupt request 2 has finished executing, the program descends to block 72.Block 7
At 2, the program executes the RETI instruction. This returns control of the program to the background level, as indicated by arrow 74. This instruction also takes the stacked background address at arrow 62, reloads it into the program counter, and empties the stack as shown at arrow 76. The program continues processing the background code, as indicated by block 78.

FIG. 3A is a timing diagram of the processing steps outlined in FIG. This timing diagram helps understand the problem posed by the simple approach of FIG. As you can understand from the graph, interrupt 1
As soon as the interrupt is detected, the code for servicing the interrupt (Service 1) is started. However, the servicing of interrupt 2 is delayed by a time T until it begins. Valuable data may be lost between the time an interrupt request is acknowledged and the interrupt processing actually begins.
This delay is unacceptable.

FIG. 4 illustrates a conceptual approach to handling interrupts in accordance with the teachings of the present invention. In this improved method, there is no delay between the second request when the processor is already servicing the first request. In short, when a processor receives the first interrupt request, the code to service that request is executed at the background level. When a program is running in background mode, any indicators set by the hardware, such as flags, are cleared, so the processor is free to accept interrupt requests of the same level. Similar to FIG. 3, FIG. 4 shows that the program for servicing interrupts can run at background level or interrupt level. When the processor branches from executing code at the background level to execute code at the interrupt level, the contents of the program counter are stored on the PC stack.

Arrow 77 indicates that the processor is executing code at background level when interrupt request 1 is detected. Interrupt request 1 occurs at the interrupt level and is indicated by arrow 79. Interrupt requests are detected by the 8051 hardware. Block 80 and arrow 83 indicate that the processor finishes processing the instruction and transfers control to service routine 1. As shown by arrow 82, the program
The background address in the counter is placed on the stack.

The processor then accesses block 84 at interrupt level. At block 84, the processor executes the subroutine “
Execute a call to “Label 2” (call)
. By executing this instruction at block 84, the processor places the next sequential address on the top stack of background addresses.

This is represented by arrow 86. The next sequential address is for service routine 1 and is shown at block 90. Following block 84, the processor descends to block 81.

At block 81, the processor executes a RETI instruction. This command returns control to the background level. This instruction also takes the next sequential instruction address at arrow 86 and loads it into the program counter. therefore,
At arrow 92 only the background address remains on the stack. To force the processor to execute the code to service the first interrupt at background level, the instructions in blocks 84 and 81 must be executed in the order shown.

Executing the specified instructions in the order shown clears any busy processor indicators that would normally be set when an interrupt request is picked up, leaving the processor free to accept other interrupt requests. can.

The instructions in blocks 84 and 81 are 8o51 instructions and will not be shown in detail. If you would like more information about these instructions, please refer to the documentation provided with the 8o51 microcontroller. moreover,
If you wish to use another microprocessor, it must handle similar instructions to force the processor to service interrupts at background level. The first block the processor enters after returning from interrupt level is block 90. At block 90, the processor begins executing code that services interrupt request 1. During execution of this code, interrupt request 2 is received at arrow 94. The program descends to block 96 and arrow 97, which terminates the instruction being processed and transfers control to Service Routine 2. At the same time, at arrow 98, the subroutine address in the program counter is transferred to the top stack of background addresses.

The service routine address of arrow 98 is the location within service routine 1 at which the processor continues execution of service routine 1 to service interrupt 1. ≦In other words, the subroutine of arrow 98
The address is the address of block 104. After control is transferred from Service Routine 1 to Service Routine 2, the processor enters block 100. At block 100, the processor executes service routine 2. Service Routine 2 is the code that the processor must execute to clear Interrupt Request 2. Upon finishing executing the code to clear interrupt request 2, the processor returns to block 102. At block 102.

The processor executes the (RETI) instruction. As before, the (RETI) instruction returns control to the background code and transfers the subroutine address at arrow 98 to the program counter. The processor then finishes executing the code of Service Routine 1. The processor then blocks 1
Descend to 06.

At block 106, the processor
neReturn” (RET) instruction. This takes the background address of arrow 108 and returns it to the program.
This is a normal 8051 instruction that moves to the counter.

The procedure for transferring addresses from the stack to the program counter is referred to as "pop stack" at block 106 and throughout this description.

From block 106, the program descends to block 110 where execution of the background code continues. Note that the stack is now empty and the processor continues executing code at background level until another set of new interrupts occurs.

FIG. 5 shows a timing diagram of the procedure shown in FIG. As is clear from this diagram, interrupt 1 and interrupt 2 can be processed without delaying the processing of interrupt 1 and interrupt 2.
They can coexist at the same interrupt level. In other words, Interrupt 2, which cannot tolerate delay, is processed immediately regardless of the activity of Interrupt 1.

As described in detail of the F1 invention, according to the present invention, when there is a first interrupt request, processing is temporarily transferred to the interrupt level, and at this level, processing is performed at the original pre-interrupt level, that is, at the background level. Set up so that one interrupt request is serviced. Processing is then returned from the interrupt level to the background level, the above-mentioned services are performed, and the first
The interrupt request flag is cleared. Therefore, other interrupt requests can be accepted at this stage. That is, multiple interrupt requests can be processed at a single interrupt level.

[Brief explanation of drawings]

1A, 1B, 1C and 1D are electrical block diagrams of a data processing system embodying the teachings of the present invention; FIG. 1 is a combination of FIGS. 1A-1D; , FIG. 2 is a conceptual diagram of a synchronous task controlled by a processor. 3 is a functional flowchart of a simplified method used to handle interrupts; FIG. 3A is a timing diagram of the method shown in FIG. 3; and FIGS. 4 is a combination of FIGS. 4A and 4B; and FIG. 5 is a timing diagram of the method of FIGS. 4A and 4B.

Claims (1)

[Scope of Claims] The steps of: accepting a first interrupt request from a source requesting a service; storing an address for the code; identifying an address at which the code for servicing the first interrupt request is stored; storing the address; and causing the processor to accept the second interrupt request. starting execution of code servicing said first interrupt request; accepting said second interrupt request; and suspending execution of code servicing said first interrupt request. and executing code for servicing the second interrupt request, prioritizing within one interrupt level and allowing the processor to service multiple events with different degrees of urgency. Interrupt handling method.