Because interrupts are asynchronous events, there must be a way for the processor to determine which interrupt to deal with first should multiple interrupts happen simultaneously. The processor defines an interrupt priority for all of the interrupts and exceptions it supports. The interrupt priorities are found in the processor’s documentation.

For example, the ARM processor supports six types of interrupts and exceptions. ^[1] The priorities of these interrupts and exceptions are shown in Table 8-2. This table is contained in the XScale Microarchitecture User’s Manual.

Typically, when an interrupt occurs, a processor disables all interrupts at the same- or lower-priority levels. If multiple interrupts are waiting to be processed or are pending, the priority associated with the interrupts determines the order in which they are executed.

The method for handling interrupts at different priorities is very processor-specific. The following text describes some scenarios for handling interrupts at different priorities.

When a higher-priority interrupt occurs while a lower-priority interrupt is being processed, the processing of the lower-priority interrupt is suspended and the higher-priority interrupt is handled. Once the higher-priority interrupt completes, the processing of the lower-priority interrupt continues. This is called interrupt nesting.

If a lower-priority interrupt occurs while the processor is handling a higher-priority interrupt, the lower-priority interrupt is left pending until the higher-priority interrupt finishes executing.

When an interrupt occurs at the same priority as the interrupt currently being processed, the interrupt currently being processed is allowed to finish. Then the processing of the next interrupt starts. In this case, interrupt nesting can also occur if the currently executing interrupt reenables interrupts at its own priority level. In other words, an interrupt can allow itself to be interrupted by other interrupts that are at the same priority level.

The interrupt priority is set by hardware design, by software, or, in some cases, by a combination of the two. If we look back at the wiring diagram in Figure 8-1(a), we see that the processor has four interrupt pins (INT0 through INT3). For this example, we’ll assume the processor gives INT0 the highest priority, followed by INT1, INT2, and INT3. The hardware designer must wire the interrupt pins so that the correct interrupt priorities are assigned to the various peripheral interrupts. In this case, the interrupt from Peripheral A has the highest priority.

Some interrupt controllers allow the priorities of interrupts to be set in software. In this case, the interrupt controller typically has registers that set the priorities of the various interrupts.

Level-sensitive interrupts cause the processor to respond as long as the interrupt signal is at the specified level. These interrupts are either high- or low-level-sensitive. Edge-sensitive interrupts cause the processor to respond when the interrupt signal goes through a transition. These interrupts are specified as rising or falling edge-sensitive. Figure 8-2 shows signals for a level-sensitive and edge-sensitive interrupt.

Figure 8-2. Level- and edge-sensitive interrupt signals

In Figure 8-2, the level-sensitive interrupt is active high. The time when the interrupt is active is shown in the signal diagram, which is the time when the signal is at the higher voltage. The interrupt signal on the bottom of Figure 8-2 is a rising edge-sensitive interrupt. It is active when the signal transitions from low to high, is held high for a certain minimum time (typically two or three processor clocks), and then it returns to low again.

There are issues related to both types of interrupts. For example, an edge-sensitive interrupt can be missed if a subsequent interrupt occurs before the initial interrupt is serviced. Conversely, a level-sensitive interrupt constantly interrupts the processor as long as the interrupt signal is asserted.

Most peripherals assert their interrupt until it is acknowledged. Some processors, such as the Intel386 EX, contain registers that can be programmed to support either level-sensitive or edge-sensitive interrupts on individual interrupts. Thus the sensitivity selection affects detection of new interrupts on that signal.

Acknowledging an interrupt tells the interrupting device that the processor has received the interrupt and queued it for processing. The method of acknowledging an interrupt can vary from reading an interrupt controller register to clearing an interrupt pending bit. Once the interrupt is acknowledged, the peripheral will deassert the interrupt signal. Some processors have an interrupt acknowledge signal that takes care of this automatically in hardware.

Maskable interrupts can be disabled and enabled either individually or globally. Nonmaskable interrupts, as the name implies, cannot be disabled. In the PXA255 processor, individual interrupts are masked in the Interrupt Controller Mask Register (ICMR). This register is shown in Figure 8-3.

Figure 8-3. PXA255 Interrupt Controller Mask Register

The ICMR is located at address 0x40D00004. Figure 8-3 shows the Interrupt Mask (IM) for each of the interrupts supported in the PXA255. Setting the corresponding bit to 1 in the ICMR allows that particular source to generate interrupts; setting the corresponding bit to 0 masks that interrupt source.

For example, imagine that the interrupt pin from a peripheral is connected to GPIO pin 0 on the PXA255 processor. Table 8-1 shows that the GPIO pin 0 interrupt source is assigned to interrupt number 8. Therefore, to enable the GPIO pin 0 interrupt, bit 8 of the ICMR is set to 1. If an interrupt occurs when the GPIO pin 0 interrupt is enabled, it is routed to the interrupt controller for processing. To mask the GPIO pin 0 interrupt source, set bit 8 of the ICMR to 0. If an interrupt occurs while the source is disabled, the interrupt is ignored.

Each processor typically has a global interrupt enable/disable bit in one of its registers. The PXA255 has two bits in the Current Program Status Register (CPSR) that globally disable all interrupts.

You generally cannot access the global interrupt flags directly using the C language. In this case, you need to write assembly code to enable and disable global interrupts. Some compiler libraries, such as those for the x86 family of processors, contain functions to handle global interrupt enabling (with the enable function) and global interrupt disabling (with the disable function).

A common issue when designing software that uses interrupts is how to share data between the ISR and the main program. A race condition is a situation where the outcome varies depending on the precise order in which the instructions of the main code and the ISR are executed; this should be strenuously avoided.

It can be extremely difficult to find race condition bugs because interrupts are asynchronous events and, to make matters worse, the race condition doesn’t occur every time the code executes. Your software can run for days and pass all production tests without exhibiting this bug—but then, once the unit is shipped to the customer, it is certain to show up.

The following code example will give you a better understanding of race conditions. Imagine that the serial port ISR serialReceiveIsr is invoked when an incoming character arrives. As characters are received, gIndex is incremented to keep track of the number of characters stored in the memory buffer.

The main function also uses gIndex, by decrementing it when it processes the received characters in the memory buffer. Here is the example code:

int gIndex = 0;

interrupt void serialReceiveIsr(void)
{
    /* Store receive character in memory buffer. */

    gIndex++;
}

int main(void)
{
    while (1)
    {
        if (gIndex)
        {
            /* Process receive character in memory buffer. */

            gIndex--;
        }
    }
}

Can you spot the problem with this code?

Let’s assume the variable gIndex has a value of 3 when the line of code that decrements this variable executes:

            gIndex--;

This line of code results in assembly-language instructions that do something like this:

            LOAD gIndex into a register;
            DECREMENT the register value;
            STORE the register value back into gIndex;

The first step is to read the value of gIndex, 3, from its location in RAM into a processor register. Next, the register value is decremented, resulting in a value of 2.

Now suppose a serial port receive interrupt occurs before the new value of gIndex is stored in the memory. The processor stops executing main and executes the serial port ISR, serialReceiveIsr. The ISR increments gIndex to a value of 4.

The processor resumes execution of main after the ISR exits. At this point, main executes the line of code that stores the register value, 2, back into the variable gIndex. Now gIndex has a value of 2, as if the latest interrupt never occurred to increment gIndex.

This race condition can cause the program to lose incoming characters. Figure 8-5 shows the race condition for this example code.

Figure 8-5. Example race condition

The decrement code in the main program is called a critical section. A critical section is a part of a program that must be executed in order and atomically, or without interruption. A line of C code (even as trivial as increment or decrement) is not necessarily atomic, as we’ve seen in this example.

So, how is this problem corrected? Because an interrupt can occur at any time, the only way to make such a guarantee is to disable interrupts during the critical section. In order to protect the critical section in the previous example code, interrupts are disabled before the critical section executes and then enabled after, as shown here:

int main(void)
{
    while (1)
    {
        interruptDisable();

        if (gIndex)
        {
            /* Process receive character in memory buffer. */

            gIndex--;
        }

        interruptEnable();
    }
}

In embedded systems, and especially real-time systems, it is important to keep interrupts enabled as much as possible to avoid hindering the responsiveness of the system. Try to minimize the number of critical sections and the length of critical section code.

Race conditions can also occur when the resource shared between an ISR and the main program is a peripheral or one of the peripheral’s registers. For example, suppose a main program and an ISR use the same peripheral register. The main program reads a register and stores the value. At this point, an ISR executes and modifies the value in that same register. When the main program resumes and updates the peripheral register, the ISR’s value is overwritten and lost.

Critical sections are also an issue when using a real-time operating system (RTOS), because the tasks may then also share resources such as global variables or peripheral registers. We will look at this in Chapter 10.

A timer is a peripheral that measures elapsed time, typically by counting down processor cycles or clocks. A counter, by contrast, measures elapsed time using external events. A timer is set up by programming an interval register in the timer peripheral, with a specific value calculated by the software engineer to determine the timer interrupt interval. The timer peripheral then uses a clock to keep count of the number of ticks that have elapsed since the timer has been started. The number of clock ticks is compared to the value in the timer interval register. Once they are equal, a timer interrupt is generated (if enabled).

The timer counts cycles either from the processor’s main clock signal or from a separate clock fed into the timer peripheral from an external processor pin. In some processors, the clock used for the timer can be selected by programming the timer’s configuration registers. Many processors today also include multiple internal clock sources that can be used to drive the timers.

On some processors, the calculated time interval is programmed into a timer register that is itself decremented at each clock tick. Once the value in that register hits zero, a timer interrupt is generated. The timer peripheral then reloads the timer register with the calculated interval value (stored in a separate register) and once again begins decrementing this value at each clock tick. Other processors, such as the PXA255, have timers that count up. Be sure to check your processor’s documentation to understand how your timer functions.

The PXA255 processor has four timers. For this example, timer 0 is used; the 32-bit PXA255 timer registers for timer 0 are shown in Figure 8-6.

Figure 8-6. PXA255 processor timer 0 registers

On the PXA255, the timer count register (OSCR) contains a count that is incremented on rising edges of the timer clock, which operates at 3.6864 MHz. In other words, each time the clock signal goes from low to high, the OSCR is incremented by one.

The timer match register (OSMRn, where n is the timer number) contains the timer values for the four different timers. After every rising edge of the timer clock, the processor compares the value in the OSMRn to the OSCR. If there is a match, an interrupt is generated and the corresponding bit is set in the timer status register (OSSR). The timer interrupt enable register (OIER) determines which interrupts are enabled for the four different timers.

The main routine for the Blinking LED implementation that uses a timer instead of a delay loop is very similar to the main routine discussed in Chapter 3. This part of the code is hardware-independent. The main function starts with initialization of the LED control port with the ledInit function. An initialization routine for the timer device driver, timerInit, is called to initialize and start the timer hardware.

The infinite loop in main is empty in this case because there is no other processing needed for this version of the Blinking LED program. All of the processing happens in the background with the timer interrupt, but the infinite loop is still needed in order to keep the program running. Notice here that the delay_ms function has been removed:

#include "led.h"
#include "timer.h"

/**********************************************************************
 *
 * Function:    main
 *
 * Description: Blink the green LED once a second.
 * 
 * Notes:       
 *
 * Returns:     This routine contains an infinite loop.
 *
 **********************************************************************/
int main(void)
{
    /* Configure the green LED control pin. */
    ledInit();

    /* Configure and start the timer. */
    timerInit();

    while (1)
        ;

    return 0;
}

The timerInit routine initializes the registers needed for the timer device driver and then enables the timer interrupt. The global state variable bInitialized is used to ensure the timer registers are only configured once.

The first step to configure the timer is to clear any pending interrupts. This is done by writing bit 0 (defined by the bitmask TIMER_0_MATCH) to the timer status (OSSR) register (defined by the macro TIMER_STATUS_REG).

For the next step, we need to calculate the interrupt interval. The PXA255 Processor Developer’s Manual states that the timers are incremented by a 3.6864 MHz clock. To toggle the LED every 500 ms, the following equation is used to determine the value for the timer match register:

For our example, the calculation is:

The macro TIMER_INTERVAL_500MS is set to the interval value 0x001C2000. The PXA255 Processor Developer’s Manual describes the algorithm for setting up a timer as follows:

To set the timer interval, the OSMR0 register (defined by the macro TIMER_0_MATCH_REG) is programmed with the current value of the timer count plus the TIMER_INTERVAL_500MS timer interval.

Next, the timer interrupt is enabled in two places: the timer peripheral and the interrupt controller. In the timer peripheral, the timer interrupt enable is controlled by bit 0 (defined by the bitmask TIMER_O_INTEN) in the 32-bit OIER (defined by the macro TIMER_INT_ENABLE_REG).

Then the interrupt controller is configured to allow interrupts from the timer peripheral. As shown in Table 8-4, the timer 0 interrupt is mapped to interrupt number 26. Therefore, the program sets bit number 26 (defined by the macro TIMER_0_ENABLE) in the Interrupt Controller Mask Register (ICMR) (defined by the macro INTERRUPT_ENABLE_REG).

For the final step, initializing the timer, set the initialization state variable to TRUE, as shown here:

#define TIMER_INTERVAL_500MS        (0x001C2000)

/**********************************************************************
 *
 * Function:    timerInit
 *
 * Description: Initialize and start the timer.
 * 
 * Notes:       This function is specific to the Arcom board.
 *              Ensure an ISR has been installed for the timer prior
 *              to calling this routine.
 *
 * Returns:     None.
 *
 **********************************************************************/
void timerInit(void)
{
    static int bInitialized = FALSE;

    /* Initialize the timer only once. */
    if (bInitialized == FALSE)
    {
        /* Acknowledge any outstanding timer interrupts. */
        TIMER_STATUS_REG = TIMER_0_MATCH;

        /* Initialize the timer interval. */
        TIMER_0_MATCH_REG = (TIMER_COUNT_REG + TIMER_INTERVAL_500MS);

        /* Enable the timer interrupt in the timer peripheral. */
        TIMER_INT_ENABLE_REG |= TIMER_0_INTEN;

        /* Enable the timer interrupt in the interrupt controller. */
        INTERRUPT_ENABLE_REG |= TIMER_0_ENABLE;

        bInitialized = TRUE;
    }
}

Prior to entering the ISR, the processor context is saved. Use the following function declaration so that the GNU compiler includes the code for the context save (and restore at the end of the ISR):

void timerInterrupt() __attribute__ ((interrupt ("IRQ")));

Next, the ISR acknowledges the timer 0 interrupt. The processor documentation states that acknowledging a timer interrupt is accomplished by writing a 1 to the timer 0 bit (defined by the bitmask TIMER_0_MATCH) of the 32-bit OSSR (defined by the macro TIMER_STATUS). See Figure 8-6 for details of the OSSR and timer 0 match status bit 0 (T0MS).

Next, the LED state changes with a call to the function ledToggle. Then the timer match value is updated for the next timer interrupt interval. To update the timer 0 match register, first read the current timer count, add the timer interval, and then write this result into the timer match register (TIMER_0_MATCH_REG).

Finally, the processor context is restored and the ISR returns:

#include "led.h"

/**********************************************************************
 *
 * Function:    timerInterrupt
 *
 * Description: Timer 0 interrupt service routine.
 * 
 * Notes:       This function is specific to the Arcom board.
 *
 * Returns:     None.
 *
 **********************************************************************/
void timerInterrupt(void)
{
    /* Acknowledge the timer 0 interrupt. */
    TIMER_STATUS = TIMER_0_MATCH;

    /* Change the state of the green LED. */
    ledToggle();

    /* Set the new timer interval. */
    TIMER_0_MATCH_REG = (TIMER_COUNT_REG + TIMER_INTERVAL_500MS);
}

You can now build this code and run it on the target Arcom board. If successfully built, this version of the Blinking LED program should operate the same way as the one shown in Chapter 3.

timer1Count++;
timer2Count++;
timer3Count++;

/* Set the flag to read the temperature sensor every 5 ms
   and then reset the counter. */
if (timer1Count >= 5)
{
    gbReadTemperatureSensor = TRUE;
    timer1Count = 0;
}

/* Set the flag to write the character out the serial port
   every 12 ms and then reset the counter. */
if (timer2Count >= 12)
{
    gbWriteSerialCharacter = TRUE;
    timer2Count = 0;
}

/* Set the flag to toggle the I/O pin every 100 ms and
   then reset the counter. */
if (timer3Count >= 100)
{
    gbTogglePin = TRUE;
    timer3Count = 0;
}