What are interrupts?

interrupts
An interrupt is the automatic transfer of software execution in response to hardware that is
asynchronous with the current software execution. The hardware can either be an external I/O device (like a
keyboard or printer) or an internal event (like an op code fault, or a periodic timer.) When the hardware
needs service (busy to done state transition) it will request an interrupt. A thread is defined as the path of
action of software as it executes. The execution of the interrupt service routine is called a background
thread. This thread is created by the hardware interrupt request and is killed when the interrupt service
routine executes the iret instruction. A new thread is created for each interrupt request. It is important to
consider each individual request as a separate thread because local variables and registers used in the
interrupt service routine are unique and separate from one interrupt event to the next. In a multithreaded
system we consider the threads as cooperating to perform an overall task. Consequently we will develop
ways for the threads to communicate (see the section on FIFO in this chapter) and synchronize (see the
discussion of semaphores in Chapter 7) with each other. Most embedded systems have a single common
overall goal. On the other hand general-purpose computers can have multiple unrelated functions to
perform. A process is also defined as the action of software as it executes. The difference is processes do
not necessarily cooperate towards a common shared goal.
The software has dynamic control over aspects of the interrupt request sequence. First, each
potential interrupt source has a separate arm bit that the software can activate or deactivate. The software
will set the arm bits for those devices it wishes to accept interrupts from, and will deactivate the arm bits
within those devices from which interrupts are not to be allowed. In other words it uses the arm bits to
individually select which devices will and which devices will not request interrupts. The second aspect that
the software controls is the interrupt enable bit, I, which is in the status register (SR). The software can
enable all armed interrupts by setting I=1 (sti), or it can disable all interrupts by setting I=0 (cli). The
disabled interrupt state (I=0) does not dismiss the interrupt requests, rather it postpones them until a later
time, when the software deems it convenient to handle the requests. We will pay special attention to these
enable/disable software actions. In particular we will need to disable interrupts when executing
nonreentrant code but disabling interrupts will have the effect of increasing the response time of software.
There are two general methods with which we configure external hardware so that it can request
an interrupt. The first method is a shared negative logic level-active request like IRQ . All the devices
that need to request interrupts have an open collector negative logic interrupt request line. The hardware
requests service by pulling the interrupt request IRQ line low. The line over the IRQ signifies negative
logic. In other words, an interrupt is requested when IRQ is zero. Because the request lines are open
collector, a pull up resistor is needed to make IRQ high when no devices need service.
Normally these interrupt requests share the same interrupt vector. This means whichever device requests an
interrupt, the same interrupt service routine is executed. Therefore the interrupt service routine must first
determine which device requested the interrupt.
The second method uses multiple dedicated edge-triggered requests. In this method, each device has
its own interrupt request line that is usually connected to a status signal in the I/O device. In this way, an
interrupt is requested on the busy to done state transition. Edge-triggered means the interrupt is requested
on the rise, the fall or both rise&fall of the Status signal. Normally these individual requests will have a
unique interrupt vector. This means there can be a separate interrupt service routine for each device. In this
way the microcomputer will automatically execute the appropriate software interrupt handler when an
interrupt is requested. Therefore the interrupt service routine does not need to determine which device
requested the interrupt.
often use shared negative logic
level-active interrupts for their external I/O devices.
Observation: Microcomputer systems running in single chip mode often use dedicated edgetriggered
interrupts for their I/O devices.
Observation: The number of interrupting devices on a system using dedicated edge-triggered
interrupts is limited when compared to a system using shared negative logic level-active
interrupts.
Observation: Most Motorola microcomputers support both shared negative logic and dedicated
edge-triggered interrupts.
The advantages of a wire-or negative logic interrupt request are: 1) additional I/O devices can be added
without redesigning the hardware, 2) there is no fundamental limit to the number of interrupting I/O
devices you can have, and 3) the microcomputer hardware is simple. The advantages of the dedicated edgetriggered
interrupt request are: 1) the software is simpler, therefore it will be easier to debug and it will run
faster, 2) there will be less coupling in between software modules, making it easier to debug and to reuse
code, and 3) it will be easier to implement priority such that higher priority requests are handled quickly,
while lower priority interrupt requests can be postponed. Because the Motorola microcomputers support
both types of interrupt, the designer can and must address these considerations.