Interrupt request

An interrupt request or English Interrupt Request (IRQ ) triggers an interrupt (interrupt ) from the process execution of a processor in the system. Usually this is signaled from devices in the system through a bus line called IRQ and said processor is responsive to a context switch, and performs the interrupt routine. After its completion IRQ is reset and the interrupted task is resumed.

For example, the keyboard generates an interrupt request when the user has pressed a key. The interrupt routine can now read each character from the keyboard control and forward it to the respective application.

Other examples in which devices can generate an interrupt request:

• Network card: if data has been received and are ready in the buffer
• Hard Disk: if the data previously requested were read and are ready for collection ( reading from disk takes a long time )
• Graphics card: if the current frame has finished drawing
• Sound Card: Sound again if data is required to play before the buffer is empty.

Operation

The CPU is connected to the hardware must be able to interrupt, i.e., produce an output signal ( voltage at an output pin) at the arrival of a particular event on the so-called interrupt line. The CPU has a corresponding input pin in the simplest case. Appear at this pin, an electric voltage, so within the CPU starts a sequence of instructions which initiate the interrupt routine.

Interrupt requests may be temporarily ignored by the CPU, for example, if another interrupt is being currently addressed. This applies to mask all interrupts except for the non-maskable (NMI: Non Maskable Interrupt), which are intended for special cases (hardware error, reset, etc.) and for the so -called software interrupts initiated by an instruction in a program (eg ' int IRQNUMMER ' on x86 - this command is used, for example, from Linux to switch to kernel mode from normal applications using system calls ( syscalls ) ).

Latency

The time between the application of the IRQ signal and the beginning of the respective processing is called latency. For an IRQ assigned the highest priority, the latency depends iW on the hardware - with shadow registers, the context changes are carried out in one clock cycle - for IRQs lower priority of the execution time of the preferred interrupt routines. Real -time operating systems are organized and configurable, so that real-time requirements can be easily met and provable.

IBM -compatible PC

The interrupt requests of the devices are first received by the Programmable Interrupt Controller, which then forwards them to a processor, and interrupts him with it. Running commands are then terminated, and the interrupt is acknowledged on the controller. Next, the CPU reads the number of the IRQ ( vector) from the controller and uses it as an index into the interrupt vector, which contains the corresponding handler for each IRQ, then to carry out the appropriate device-specific action.

In modern systems (for example, PCI systems ) known as the interrupt sharing is usually possible without any problems. Here, several devices share an interrupt. The handler for such an interrupt then you have all the drivers, the devices could have triggered this interrupt, call ( on IRQ, this can not be determined ). This can lead to problems if individual drivers, for example, are active for too long due to poor programming, and in the meantime the device that originally generated the interrupt, for example, the buffer becomes full and overflows (that is, in the worst case: loss of data).

In modern peripherals to the computer and the operating system take care of the assignment of IRQ numbers (PnP = Plug-and- Play devices ). In older cards, such as ISA cards, IRQs must be manually set or are hardwired on the cards.

On Linux, you can query the interrupts with the following command: cat / proc / interrupts

On Windows Vista and Windows XP, you can query the interrupts with the following command: msinfo32.exe → Hardware Resources → IRQs

IRQ Device Table (This list differs from system to system )