Conversation with Merlin [email protected] · Mon Nov 27 2023

Enable and Disable Interrupts  Two more ways to enable and disable interrupts are:  Setting Processor Status register bit to 1/0  Processor automatically disables or enables interrupts by updating the interrupt enable/disable bit in PSR.  Setting to 1 enables interrupt  Setting to 0 disables interrupt  Using Interrupt request line  Processor has interrupt request line for which interrupt handling circuit responds only to the leading the edge of the signal called edge triggered.  In this case, processor will receive only one request and there is no danger of multiple interruptions and no need of disable interrupt request Handling Multiple devices  Multiple I/O devices may be connected to the processor and the memory via a bus. Some or all of these devices may be capable of generating interrupt requests.  Each device operates independently, and hence no definite order can be imposed on how the devices generate interrupt requests. This gives rise to a number of questions:  How does the processor know which device has generated an interrupt?  How does the processor know which interrupt service routine needs to be executed?  When the processor is executing an interrupt service routine for one device, can other device interrupt the processor?  If two interrupt-requests are received simultaneously, then how to break the tie? Handling Multiple Devices  Consider a simple arrangement where all devices send their interrupt-requests over a single control line in the bus.  When the processor receives an interrupt request over this control line, how does it know which device is requesting an interrupt?  This information is available in the status register of the device requesting an interrupt:  The status register of each device has an IRQ bit which it sets to 1 when it requests an interrupt.  Interrupt service routine can poll the I/O devices connected to the bus. The first device with IRQ equal to 1 is the one that is serviced.  Polling mechanism is easy, but time consuming to query the status bits of all the I/O devices connected to the bus. Vectored Interrupts: Handling Multiple Devices  Another method: The device requesting an interrupt may identify itself directly to the processor.  Device can do so by sending a special code (4 to 8 bits) to the processor over the bus.  Code supplied by the device may represent a part of the starting address of the interrupt-service routine.  The remainder of the starting address is obtained by the processor based on other information such as the range of memory addresses where interrupt service routines are located.  Programmer gains some flexibility by storing a branch instruction to the appropriate ISR.  Usually the location pointed to by the interrupting device is used to store the starting address of the interrupt-service routine.  Processor reads this address called Interrupt Vector. Nested Interrupts  Previously, before the processor started executing the interrupt service routine for a device, it disabled the interrupts from the device.  In general, same arrangement is used when multiple devices can send interrupt requests to the processor.  During the execution of an interrupt service routine of device, the processor does not accept interrupt requests from any other device.  Since the interrupt service routines are usually short, the delay that this causes is generally acceptable.  However, for certain devices this delay may not be acceptable.  Which devices can be allowed to interrupt a processor when it is executing an interrupt service routine of another device? Nested Interrupts  I/O devices are organized in a priority structure:  An interrupt request from a high-priority device is accepted while the processor is executing the interrupt service routine of a low priority device.  A priority level is assigned to a processor that can be changed under program control.  Priority level of a processor is the priority of the program that is currently being executed.  When the processor starts executing the interrupt service routine of a device, its priority is raised to that of the device.  If the device sending an interrupt request has a higher priority than the processor, the processor accepts the interrupt request. Nested Interrupts  Processor’s priority is encoded in a few bits of the processor status register.  Priority can be changed by instructions that write into the processor status register.  Usually, these are privileged instructions, or instructions that can be executed only in the supervisor mode.  Privileged instructions cannot be executed in the user mode.  Prevents a user program from accidentally or intentionally changing the priority of the processor.  If there is an attempt to execute a privileged instruction in the user mode, it causes a special type of interrupt called as privilege exception. Implementation of interrupt priority using individual interrupt request and acknowledge lines Priority arbitration Device 1 Device 2 Device p INTA1 INT R 1 I NT R p INTA p •Each device has a separate interrupt-request and interrupt-acknowledge line. •Each interrupt-request line is assigned a different priority level. •Interrupt requests received over these lines are sent to a priority arbitration circuit in the processor. •If the interrupt request has a higher priority level than the priority of the processor, then the request is accepted. Processor Handling Simultaneous Requests  Which interrupt request does the processor accept if it receives interrupt requests from two or more devices simultaneously?.  If the I/O devices are organized in a priority structure, the processor accepts the interrupt request from a device with higher priority.  Each device has its own interrupt request and interrupt acknowledge line.  A different priority level is assigned to the interrupt request line of each device.  However, if the devices share an interrupt request line, then how does the processor decide which interrupt request to accept? Handling Simultaneous Requests Device 2 I NT R INTA Device n Device 1 Polling scheme: •If the processor uses a polling mechanism to poll the status registers of I/O devices to determine which device is requesting an interrupt. •In this case the priority is determined by the order in which the devices are polled. •The first device with status bit set to 1 is the device whose interrupt request is accepted. Daisy chain scheme: •Devices are connected to form a daisy chain. •Devices share the interrupt-request line, and interrupt-acknowledge line is connected to form a daisy chain. •When devices raise an interrupt request, the interrupt-request line is activated. •The processor in response activates interrupt-acknowledge. •Received by device 1, if device 1 does not need service, it passes the signal to device 2. •Device that is electrically closest to the processor has the highest priority. Processor Handling Simultaneous Requests •When I/O devices were organized into a priority structure, each device had its own interrupt-request and interrupt-acknowledge line. •When I/O devices were organized in a daisy chain fashion, the devices shared an interrupt-request line, and the interrupt-acknowledge propagated through the devices. •A combination of priority structure and daisy chain scheme can also used. Device Device circuit Priority arbitration Device Device I NT R 1 INT R p INTA1 INTA p •Devices are organized into groups. •Each group is assigned a different priority level. •All the devices within a single group share an interrupt-request line, and are connected to form a daisy chain. Processor Controlling I/O Devices(4.2.4)  Only those devices that are being used in a program should be allowed to generate interrupt requests.  To control which devices are allowed to generate interrupt requests, the interface circuit of each I/O device has an interrupt-enable bit.  If the interrupt-enable bit in the device interface is set to 1, then the device is allowed to generate an interrupt-request.  Interrupt-enable bit in the device’s interface circuit determines whether the device is allowed to generate an interrupt request.  Interrupt-enable bit in the processor status register or the priority structure of the interrupts determines whether a given interrupt will be accepted.

Explain these topics in simpler terms

Here's a simpler explanation of the mentioned topics:

Enable and Disables: Enabling and disabling interrupts can be done in a couple of ways. For instance, one method involves updating the Processor Status Register (PSR) bit: setting it to 1 enables interrupts, while setting it to 0 disables interrupts. Another way is using the interrupt request line, which responds to the leading edge of the signal for edge-triggered interrupts.

Handling Multiple Devices: When multiple I/O devices are connected to a processor, each device may be capable of generating interrupt requests. The processor needs to know which device has generated an interrupt and which interrupt service routine needs to be executed. To handle this, different methods can be used, such as polling the I/O devices or using special codes from the devices to identify themselves to the processor.

Nested Interrupts: In certain cases, a processor needs to decide if it should allow an interrupt from a device while it's already dealing with an interrupt from another device. Nested interrupts handle this by organizing I/O devices based on priority. The interrupt service routine of a device can be interrupted by a higher-priority device. This is done by changing the priority level of the processor to that of the interrupting device.

Handling Simultaneous Requests: If the processor receives interrupt requests from multiple devices simultaneously, it needs a method to determine which request to accept. This can be done using a polling or daisy chain scheme. In a polling scheme, the priority is determined by the order in which the devices are polled, while in a daisy chain scheme, the interrupt-acknowledge line is connected through the devices and the device closest to the processor has the highest priority.

Controlling I/O Devices: To control which devices are allowed to generate interrupt requests, each I/O device has an interrupt-enable bit in its interface circuit. If this bit is set to 1, the device is allowed to generate an interrupt-request. Additionally, the interrupt-enable bit in the processor status register or the priority structure of the interrupts determines whether a given interrupt will be accepted.

Are Nested Interrupts Needed?Most NuttX architectures do not support nested interrupts: Interrupts are disabled when the interrupt is entered and restored when the interrupt returns. Being able to handle nested interrupt is critical in simple architectures where a lot of interrupt level processing is performed: In this case, you can prioritize interrupts and assure that the highest priority interrupt processing is not delayed by lower level interrupt processing.In an RTOS model, however, all interrupt processing should be as brief as possible; any extended processing should be deferred to a user task and not performed in the interrupt handler. However, you may find a need to have nested interrupt handling in NuttX too. The lack of support of nested interrupts is not inherently an issue with NuttX and need not be the case; it should be a simple matter to modify the interrupt handling so that interrupts are nested.Layered Interrupt Handling ArchitectureInterrupt handling occurs in several files. In most implementations, there are several layers of interrupt handling logic:Some low-level logic, usually in assembly language, that catches the interrupt and determines the IRQ number. Consider arch/arm/src/armv7-m/up_exception.S as an example for the Cortex-M family.That low-level logic than calls some MCU-specific, intermediate level function usually called up_doirq(). An example is arch/arm/src/armv7-m/up_doirq.c.That MCU-specific function then calls the NuttX common interrupt dispatching logic irq_dispatch() that can be found at sched/irq_dispatch.cHow to Implement Nested Interrupts in the Layered Interrupt Handling ArchitectureThe logic in these first two levels that would have to change to support nested interrupt handling. Here is one technical approach to do that:Add an global variable, say g_nestlevel, that counts the interrupt nesting level. It would have an initial value of zero; it would be incremented on each interrupt entry and decremented on interrupt exit (making sure that interrupts are disabled in each case because incrementing and decrementing are not usually atomic operations).At the lowest level, there is usually some assembly language logic that will switch from the user's stack to a special interrupt level stack. This behavior is controlled CONFIG_ARCH_INTERRUPTSTACK. The logic here would have to change in the following way: If g_nestlevel is zero then behave as normal, switching from the user to the interrupt stack; if g_nestlevel is greater than zero, then do not switch stacks. In this latter case, we are already using the interrupt stack.In the middle-level, MCU-specific is where the g_nestlevel would be increment. And here some additional decision must be made based on the state of g_nestlevel. If g_nestlevel is zero, then we have interrupted user code and we need to handle the context information specially and handle interrupt level context switches. If g_nestlevel is greater than zero, then the interrupt handler was interrupt by an interrupt. In this case, the interrupt handling must always return to the interrupt handler. No context switch can occur here. No context switch can occur until the outermost, nested interrupt handler returns to the user task.You would also need to support some kind of critical section within interrupt handlers to prevent nested interrupts. For example, within the logic of functions like up_block_task(). Such logic must be atomic in any case.NOTE 1: The ARMv7-M could also be configured to use separate MSP and PSP stacks with the interupt processing using the MSP stack and the tasks all using the PSP stacks. This is not compatible with certain parts of the existing design and would be more effort, but could result in a better solution.NOTE 2: SMP has this same issue as 2 but it is addressed differently: With SMP there is an array of stacks indexed by the CPU number so that all CPUs get to have an interrupt stack. See for example, LC823450 or i.MX6 SMP logic.A generic up_doirq()

cwiki.apache.org

The interrupt is a signal emitted by hardware or software when a process or an event needs immediate attention. It alerts the processor to a high-priority process requiring interruption of the current working process. In I/O devices one of the bus control lines is dedicated for this purpose and is called the Interrupt Service Routine (ISR). When a device raises an interrupt at lets say process i, the processor first completes the execution of instruction i. Then it loads the Program Counter (PC) with the address of the first instruction of the ISR. Before loading the Program Counter with the address, the address of the interrupted instruction is moved to a temporary location. Therefore, after handling the interrupt the processor can continue with process i+1. While the processor is handling the interrupts, it must inform the device that its request has been recognized so that it stops sending the interrupt request signal. Also, saving the registers so that the interrupted process can be restored in the future, increases the delay between the time an interrupt is received and the start of the execution of the ISR. This is called Interrupt Latency. Software Interrupts: A sort of interrupt called a software interrupt is one that is produced by software or a system as opposed to hardware. Traps and exceptions are other names for software interruptions. They serve as a signal for the operating system or a system service to carry out a certain function or respond to an error condition. A particular instruction known as a interrupt instruction is used to create software interrupts. When the interrupt instruction is used, the processor stops what it is doing and switches over to a particular interrupt handler code. The interrupt handler routine completes the required work or handles any errors before handing back control to the interrupted application. Hardware Interrupts: In a hardware interrupt, all the devices are connected to the Interrupt Request Line. A single request line is used for all the n devices. To request an interrupt, a device closes its associated switch. When a device requests an interrupt, the value of INTR is the logical OR of the requests from individual devices. The sequence of events involved in handling an IRQ: Devices raise an IRQ. The processor interrupts the program currently being executed. The device is informed that its request has been recognized and the device deactivates the request signal. The requested action is performed. An interrupt is enabled and the interrupted program is resumed. Handling Multiple Devices: When more than one device raises an interrupt request signal, then additional information is needed to decide which device to be considered first. The following methods are used to decide which device to select: Polling, Vectored Interrupts, and Interrupt Nesting. These are explained as following below. Polling: In polling, the first device encountered with the IRQ bit set is the device that is to be serviced first. Appropriate ISR is called to service the same. It is easy to implement but a lot of time is wasted by interrogating the IRQ bit of all devices. Vectored Interrupts:In vectored interrupts, a device requesting an interrupt identifies itself directly by sending a special code to the processor over the bus. This enables the processor to identify the device that generated the interrupt. The special code can be the starting address of the ISR or where the ISR is located in memory and is called the interrupt vector. Interrupt Nesting:In this method, the I/O device is organized in a priority structure. Therefore, an interrupt request from a higher priority device is recognized whereas a request from a lower priority device is not. The processor accepts interrupts only from devices/processes having priority. Processors priority is encoded in a few bits of PS (Process Status register). It can be changed by program instructions that write into the PS. The processor is in supervised mode onl

geeksforgeeks.org

Nested Execution of Exception and Interrupt Handlers When handling an interrupt or an exception, the kernel begins a new kernel control path , or separate sequence of instructions. When a process issues a system call request, for instance, the first instructions of the corresponding kernel control path are those that save the content of the registers in the Kernel Mode stack, while the last instructions are those that restore the content of the registers and put the CPU back into User Mode. Linux design does not allow process switching while the CPU is executing a kernel control path associated with an interrupt. However, such kernel control paths may be arbitrarily nested; an interrupt handler may be interrupted by another interrupt handler, thus giving raise to a nested execution of kernel threads. We emphasize that the current process doesnt change while the kernel is handling a nested set of kernel control paths. Assuming that the kernel is bug free, most exceptions can occur only while the CPU is in User Mode. Indeed, they are either caused by programming errors or triggered by debuggers. However, the Page Fault exception may occur in Kernel Mode. This happens when the process attempts to address a page that belongs to its address space but is not currently in RAM. While handling such an exception, the kernel may suspend the current process and replace it with another one until the requested page is available. The kernel control path that handles the Page fault exception resumes execution as soon as the process gets the processor again. Since the Page Fault exception handler never gives rise to further exceptions, at most two kernel control paths associated with exceptions (the first one caused by a system call invocation, the second one caused by a Page Fault) may be stacked, one on top of the other. In contrast to exceptions, interrupts issued by I/O devices do not refer to data structures specific to the current process, although the kernel control paths that handle them run on behalf of that process. As a matter of fact, it is impossible to predict which process will be running when a given interrupt occurs. An interrupt handler may preempt both other interrupt handlers and exception handlers. Conversely, an exception handler never preempts an interrupt handler. The only exception that can be triggered in Kernel Mode is Page Fault, which we just described. But interrupt handlers never perform operations that can induce Page Faults, and thus, potentially, process switch. Linux interleaves kernel control paths for two major reasons: To improve the throughput of programmable interrupt controllers and device controllers. Assume that a device controller issues a signal on an IRQ line: the PIC transforms it into an external interrupt, and then both the PIC and the device controller remain blocked until the PIC receives an acknowledgment from the CPU. Thanks to kernel control path interleaving, the kernel is able to send the acknowledgment even when it is handling a previous interrupt. To implement an interrupt model without priority levels. Since each interrupt handler may be deferred by another one, there is no need to establish predefined priorities among hardware devices. This simplifies the kernel code and improves its portability. On multiprocessor systems, several kernel control paths may execute concurrently. Moreover, a kernel control path associated with an exception may start executing on a CPU and, due to a process switch, migrate on another CPU.

oreilly.com