In previous article, we have discussed the basics of interrupt. In order to be able to trigger an interrupt, the hardware connected to the main processor (CPU) must be interrupt-capable, i.e. generate an output signal (electrical voltage at an output pin) via the so-called interrupt line when a certain event occurs. The CPU generally has separate pins for maskable (disabled) interrupts (INTR) and non-maskable interrupts (NMI). Since the interrupt number must also be transmitted to the CPU for interrupts that cannot be masked, many systems have an interrupt controller to which this task is delegated in case the peripheral cannot do it itself.
Unmaskable Interrupt
When the NMI is triggered, the CPU disables the maskable interrupts and jumps to an address specified by the CPU manufacturer for NMI, which is usually located in the fixed-value memory, depending on the computer. The ISR (Interrupt Service Routine) stored there usually triggers a restart of the system or a global error handling. Application software has no influence whatsoever on the behavior of an NMI. Even the system software cannot prevent an NMI from being treated.
Masked interrupt
This section needs a major overhaul. More details should be provided on the talk page. Please help improve it, and then remove this marker.
If a signal ([Vcc]) appears on this pin, which is usually referred to as NMI, while interrupts are currently not masked (for x86 the interrupt flag (IF) is set), the CPU disables all maskable interrupts and reads the number of the requested interrupt from the system bus (Intel64 hardware distinguishes 256 interrupt numbers). There, the requester must create the number before the request. The CPU then consults the interrupt vector table and extracts the address of the corresponding interrupt service routine. This is part of the driver software of the triggering hardware. When executed, this routine must first secure the entire compromised processing context, i.e. the processor registers it will use. This is followed by the actual handling of the interrupt, and finally the return of the context and return to the statement that was last executed before the interrupt was handled. When rebounding, the previously locked interrupts are also unmasked (reactivated). For this, there is a special interrupt return statement from the CPU instruction set that is used instead of the normal return statement. Technically, the process is similar to that of a normal subroutine call with additional handling of interrupt masking.
---
Software-triggered interrupt
On many processors, interrupt handling can also be triggered by a machine instruction (“INT nn”). As with hardware interrupts, when handling the interruption request, the processor achieves a higher level of privilege at which the interrupt routine runs. This is how individual operating systems implement system calls.
Latency
The time between the creation of the IRQ signal and the start of the corresponding processing is called latency. For an interrupt of the highest assigned priority, the latency depends mainly on the hardware – with shadow registers, context switching can succeed in a clock cycle. For lower-priority interruptions, latency is determined by the execution time of the preferred interrupt routines. Real-time operating systems are organized and configurable in a way that makes real-time requirements easier and more demonstrable.
Masking
Interrupt requests can be temporarily ignored by the CPU, for example, when another interrupt is being handled. This may be necessary for certain time-sensitive and synchronizing routines, such as in device drivers. Masking (temporary blocking/deactivation) is possible for all interrupts except for the non-maskable interrupts (NMI: Non Maskable Interrupt). The latter are intended for special cases (power failure, hardware failure, etc.). Also not maskable are so-called software interrupts, which are triggered by a machine command in a program – for example, ‘int IRQNUMMER’ is used in Linux x86 systems to switch from normal applications to kernel mode via system calls (syscalls).
Asynchrony
External interrupts (hardware interrupts) are generally asynchronous with respect to the interrupted program, i.e. the execution of the program is at an indeterminate point when the interrupt occurs. Therefore, interrupts must not have a direct impact on programs (or program variables) or devices (such as hard drives) without special synchronization measures. ISRs are not tasks in the sense of the operating system. For ISRs, it should also be pointed out that interrupt masking may only be removed (interrupt enable) with special software concepts within the ISRs, as both interrupt nesting by third-party ISRs and a re-entry option of the same interrupt are created.
Some processors have special commands to trigger so-called “software interrupts” from a running task, which, apart from the special entry and return conditions, act like subroutine calls and are therefore not asynchronous. The same applies to traps that are triggered by the CPU itself in the event of errors (protected access, forbidden instructions (e.g. division by zero), single-step debugging, memory management events, but also as a standard interface to operating system calls, etc.) and usefully use the same mechanism.
Interrupt Service Routines as a Programming Principle
Especially in the case of hardware-related event-driven applications, as they are common in embedded systems, one possible approach is to move more or less the entire functionality of the system to the interrupt routines or tasks triggered by them. Typically, the processor can be put into an energy-saving hibernation state (idle state), from which it wakes up in the event of interrupt requests (i.e. external events). In extreme cases, the main program consists only of an initialization part, which is run through after the system starts, followed by an infinite loop in which – apart from activating the above-mentioned hibernation state – nothing happens.
Tagged With plainznk