1
E 332L Microprocessors Lab (Fall 2007)
– Lab 6 (Week 8)–
Interruptions happen… Virtually all computer systems must deal with interruptions. Larger systems have
sophisticated software that deals with interrupts with all of the details hidden from the developer.
We’ll be dealing with the issue of interrupts for both this week’s and next week’s labs. This week we’ll
be using the Altera Debug Client and assembler in order to get a better understanding of the low level
details of interrupts. Next week we’ll return to the NIOS IDE and the C programming language to see
how to deal with interrupts in that environment. Lastly, we’ll look at Altera’s implementation of these
concepts and how to utilize the software interrupt facilities that they’ve provided.
Though generally you should utilize the facilities provided by a platform vendor, it’s useful to dig into the
implementation provided to get a better understanding of how a particular platform works. The interrupt
process is not the same on all platforms, so remember that we’ll be working with a specific architecture
and other platforms will vary in how they implement interrupts. This means that for each platform you
deal with, you need to search for, read, filter out and understand documentation on the implementation
details specific to that particular platform.
To get an idea of the general concept of interrupts, read Section 6.4 from your text book. Note that the
example in Figure 6.10 is for illustration purposes only; the practice shown in Step 4(a) of the example -
doing I/O for a separate device not related to the device associated with the current ISR - causes a delay
and therefore should be evaluated very carefully. The amount of time spent servicing an interrupt should
be kept to an absolute minimum to avoid missing any other interrupts that may happen during the
servicing time. Introducing any delays, either intentional or incidental, is the major cause of problems
associated with interrupt service routines. As you recall, writing to the LCD device in Lab05 required the
introduction of delays. Such delays should not be put into ISRs, as they can lead to hard-to-detect
problems.
Interrupts can be divided into several general steps:
1. Activating the interrupt process in the processor.
2. Enabling the processor to recognize a particular interrupt (masking).
3. Enabling a particular device to produce interrupts.
4. Once an interrupt happens, identifying (Interrupt Handler) which one it is and dispatching the
interrupt to code that produces (ISR) the appropriate action for that interrupt.
5. Finally, returning control to the process that was running when the interrupt happened.
Review the following documentation, paying special attention to Interrupt behavior, Register Map and
any other information dealing with ISRs. (Ignore any issues that discuss HAL usage, as HAL utilization
will be discussed at a later time.)
1. General NIOS II theory of operation: Nios II Processor Reference Handbook NII5V1-7.1
a. Section 1. Nios II Processor
• Chapter 2 – Processor Architecture:
Exception and Interrupt Controller (pp. 2-6, 2-7)
• Chapter 3 – Programming Model:
Control Registers (pp. 3-2 thru 3-5)
Exception Processing (pp. 3-5 thru 3-10)
b. Section 2. Appendices
• Instruction Set Reference, Chapter 8:
