Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output access regulation
Reexamination Certificate
1998-11-13
2001-02-27
Lee, Thomas C. (Department: 2782)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output access regulation
C710S046000, C710S063000, C710S063000, C710S063000
Reexamination Certificate
active
06195715
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to a method and apparatus controlling communications between various components of a computer system. More particularly, the present invention relates to interrupt control in a computer system.
Computer systems typically include numerous components, such as application software, peripheral devices and internal circuitry. In order for these components to function properly, each must communicate with the system's processor without interfering with the remaining components.
During normal operation, the processor constantly processes internal software commands. When a peripheral device, such as a keyboard, requires processor time, an external event occurs. To obtain the necessary processor time, the keyboard initiates an “interrupt”, halting the processor from the aforementioned processes so that input from the keyboard can he decoded by the computer system employing the processor. Specifically, upon receiving an interrupt signal, the processor should halts routine processing, services the interrupting signal, and then returns to the pre-interrupt processing.
A typical computer system will have a set of interrupt request lines. If the processor detects an interrupt signal at one of these interrupt request lines, the processor completes current software instructions and then halts normal operation. Such an interrupt can be generated by the keyboard in response to user initiated keypad input. The processor will then jump to a software routine stored in memory, hereinafter to be called an “Interrupt Service Routine” or “ISR.” Depending on which interrupt request line of the processor receives the interrupt signal, the processor determines a jump location and then begins execution of an ISR located at that memory location. Interrupt Service Routines may be considered as being device specific software programs that integrate the operation of peripheral devices and normal processor operation. At the end of the Interrupt Service Routine (ISR), the ISR sends a command to the processor to restore the pre-existing condition of the processor. Thus, interrupts enable transfer of control from one program to another, to be initiated by an event external to the computer. Since interrupts can occur at any time, frequently the execution of events by the processor are altered, creating interactions between software and hardware that were not anticipated in the design of the computer system.
Interrupt requests typically originate from two sources. One source of interrupt requests generates an interrupt event that does not need to be cleared. For example, in a Real Time Clock (RTC), the interrupt events generated are pulses and are inherently self-resetting. Another origin of interrupt requests requires servicing to clear or reset the interrupt event. In this manner, an interrupt event is generated that requires an action to be performed subsequent to the generating event to clear the interrupt request. An example of this type of interrupt request is a keyboard that, by pressing a key, causes a level shift signal to be generated. The level shift signal remains at a predetermined level until the keyboard is serviced by an ISR to determine which key was pressed. Resetting its signal level to allow the occurrence of another keyboard-generated event to be processed then clears the interrupt event.
To ensure proper computer system operation it is necessary to make sure that the device generating he interrupt event is serviced and cleared before a subsequent interrupt event is generated, i.e., to avoid interrupt confusion. Otherwise the computer system resources might become overburdened and data may be lost. Prior art attempts to avoid data loss due to interrupt confusion includes preventing the generation of a second interrupt by employing a disabling command as the first instruction of the ISR. The interrupt would then be re-enabled before returning from the interrupt. However, this solution is not effective if more than one origin of interrupts is present. Another prior art solution with avoiding interrupt confusion is to have the processor automatically disable the interrupts before starting the execution of the ISR. A third option uses level transition interrupt where the interrupt detecting hardware detects only the edge of the interrupt transition, so that only one such transition is seen for each interrupt.
The problems associated with interrupt confusion are exacerbated if more than one device is connected to a common interrupt of the processor. A situation may arise in which more than one device may request an interrupt during the same time interval. Therefore, the computer system design must take into account how to recognize the origin of an interrupt, as well as, how the processor will determine which ISR to run for each interrupt origins, and how to prioritize the interrupts to determine the hierarchical order in which interrupts are be handled.
Prior art solutions concerning with peripheral devices connected to a common processor terminal are identified by the addresses in the memory map of the computer system. The peripheral device interrupt request can be connected to the inputs of an OR circuit. The output of the circuit transmits the device interrupt requests to the processor interrupt terminal. Because the output of the OR circuit is essentially shared by the devices requesting interrupts, there could always be another device interrupting on the same line without the processor knowing about it. A solution to this problem has used a method where status registers, physically located on each of the connected devices, are set by a corresponding interrupt request signal. The outputs of the individual status registers are OR'ed to indicate the presence of interrupt signals. During an active interrupt, if an interrupt request is signaled by another device, the request is stored in the associated status register. Upon completing the servicing of the first interrupt, the second interrupting device will still be indicating the interrupt status of the second device at the OR circuit output. The computer system can reset these registers to clear the interrupts by writing to the individual address location identifying the register. Depending on the number of interrupting devices, this method may require a large number of computer system address locations. This in turn can increase the complexity of the decoding scheme used in the processor architecture. Another disadvantage of using such an implementation is the time required for polling the registers to determine their status. An alternative design is for the device to send a code or “vector” along with its interrupt signal. The processor can then immediately start executing the ISR pointed to by the code. In a computer that has multiple interrupt request lines, vectored interrupts may be implemented by simply associating a unique starting address with each line. The two alternatives can be mixed; the vectors can identify groups of inputs from which the processor can identify a particular one by polling.
A problem associated with both approaches is that there are inherent delays in the processing of interrupts. These delays can cause a subsequent interrupt to be missed. One such delay results from the necessity in some computer systems to globally disable interrupts upon a valid interrupt request. During this period, until re-enablement of the interrupts, other interrupting devices cannot be identified. Computer system delays can arise during critical sequences when interrupts are disabled during the time required to poll the interrupting devices, the time required to complete the current processor instruction sequence before jumping to the interrupt, and due to the necessity to process higher priority interrupts first. Since the processor may require the use of the system bus to process its normal functions during this delay, the interrupting device should not be allowed to put data on the bus until the processor is ready to receive it. This can be achieved through the
Hoge Stephen
Lange Eric W.
Creative Technology Ltd.
Lee Thomas C.
Penveen Rehana
Townsend and Townsend / and Crew LLP
LandOfFree
Interrupt control for multiple programs communicating with a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Interrupt control for multiple programs communicating with a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interrupt control for multiple programs communicating with a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2609261