ELEC-4601: Microprocessor Systems Lab 2: 80x86 Interrupts The Point Writing software to properly respond to a hardware interrupt is fussy. There is a hardware path from the incoming interrupt signal all the way to the microprocessor that needs to be correctly laid out and ‘enabled’ using specific bits within specific registers that are located at specific addresses in the I/O mapped memory space of the microprocessor. In this lab, the microprocessor is a member of the 80x86 family but the process or laying out and enabling this path is fundamentally the same for all microprocessors and microcontrollers. There are typically three places where interrupts can be enabled or disabled i.e. allowed to proceed or blocked from proceeding. The microprocessor itself usually has a global ‘Interrupt enable’ bit or bits as part of a CPU flags register e.g. IF bit in the FLAGS register in the 80x86. If there is a subsystem that is responsible for arbitrating incoming interrupts (in this case, the 8259 Programmable Interrupt Controller or PIC) then it will have registers and bits that need configuring to accept an interrupt and forward it on to the CPU. Finally, the interface subsystem that actually connects to the interrupt source will have some set of registers and bits that need to be configured in order to let the interrupt proceed on its way to the interrupt arbitrator (e.g. the PIC). Once the hardware path has been properly enabled and interrupts can actually reach the CPU, the software has to be written to recognize the interrupt, service it, and gracefully restore the system back to its normal ‘waiting for an interrupt’ state. The frustrating part of this process arises from the fact that unless everything is working and configured properly then the system will fail, usually in a fatal fashion. If all the hardware isn’t configured properly you will not see the interrupt. Once you can see the interrupt, incorrect software will fail (totally) and you will have to reset the hardware and try again. Debugging a hardware interrupt in real time is a notoriously difficult thing but once you have done it for a system such as this one you will know what to look for in any microprocessor system and you will be able to anticipate the amount of time to allocate to this part of the design process. This is something worth knowing. Introduction Interrupts offer an alternate way of responding to external events in a microprocessor system. The microprocessor can ‘poll’ for changes in the environment by constantly looking for those changes or it can wait until a device signals a change and ‘handle the interrupt’ caused by the change. For real time events, such as keyboard presses, internal time-of- day clock changes, printer-out-of-paper etc., an actual hardware digital signal, referred to as an IRQ (Interrupt ReQuest) can be generated. They are usually numbered according to their priority, with IRQ0 having the highest priority (the system time-of-day) and IRQ7 the lowest (the LPT1 printer port). For typical simple microprocessor systems, the following flowchart applies:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ELEC-4601: Microprocessor Systems
Lab 2: 80x86 Interrupts The Point Writing software to properly respond to a hardware interrupt is fussy. There is a hardware path from the
incoming interrupt signal all the way to the microprocessor that needs to be correctly laid out and ‘enabled’ using
specific bits within specific registers that are located at specific addresses in the I/O mapped memory space of the
microprocessor. In this lab, the microprocessor is a member of the 80x86 family but the process or laying out and
enabling this path is fundamentally the same for all microprocessors and microcontrollers.
There are typically three places where interrupts can be enabled or disabled i.e. allowed to proceed or blocked
from proceeding. The microprocessor itself usually has a global ‘Interrupt enable’ bit or bits as part of a CPU flags
register e.g. IF bit in the FLAGS register in the 80x86. If there is a subsystem that is responsible for arbitrating incoming
interrupts (in this case, the 8259 Programmable Interrupt Controller or PIC) then it will have registers and bits that need
configuring to accept an interrupt and forward it on to the CPU. Finally, the interface subsystem that actually connects
to the interrupt source will have some set of registers and bits that need to be configured in order to let the interrupt
proceed on its way to the interrupt arbitrator (e.g. the PIC).
Once the hardware path has been properly enabled and interrupts can actually reach the CPU, the software has to be
written to recognize the interrupt, service it, and gracefully restore the system back to its normal ‘waiting for an interrupt’
state.
The frustrating part of this process arises from the fact that unless everything is working and configured properly
then the system will fail, usually in a fatal fashion. If all the hardware isn’t configured properly you will not see the
interrupt. Once you can see the interrupt, incorrect software will fail (totally) and you will have to reset the hardware
and try again. Debugging a hardware interrupt in real time is a notoriously difficult thing but once you have done it for a
system such as this one you will know what to look for in any microprocessor system and you will be able to anticipate
the amount of time to allocate to this part of the design process. This is something worth knowing.
Introduction
Interrupts offer an alternate way of responding to external events in a microprocessor system. The microprocessor
can ‘poll’ for changes in the environment by constantly looking for those changes or it can wait until a device signals a
change and ‘handle the interrupt’ caused by the change. For real time events, such as keyboard presses, internal time-of-
day clock changes, printer-out-of-paper etc., an actual hardware digital signal, referred to as an IRQ (Interrupt ReQuest)
can be generated. They are usually numbered according to their priority, with IRQ0 having the highest priority (the system
time-of-day) and IRQ7 the lowest (the LPT1 printer port). For typical simple microprocessor systems, the following
flowchart applies:
The software procedure, usually small and fast, that runs in response to an interrupt is referred to as an Interrupt
Service Routine (ISR). 80X86 processors operating in real-mode (the simple microprocessor mode used in the lab) make
use of an Interrupt Descriptor Table (IDT) which consists of 256 entries (numbered 0 through 255), each of which holds
the address of an ISR. The IDT starts at memory location 0000:0000. Most of these entries are for the 255 ‘software’
interrupts and processor exceptions that the processor supports. Some of the entries in this table have been set aside for
‘hardware’ interrupts, with IRQ0 to IRQ7 using up the IDT slots at positions 8 to 15, and IRQ8 to IRQ15 using up the IDT
slots at positions 0x70 to 0x77. In response to an interrupt, the processor will finish executing the current instruction,
immediately jump to the address stored in the IDT at the appropriate location, and continue executing instructions from
this new address.
Purpose
This lab will investigate a number of things in software:
- the steps necessary to get a typical microprocessor system to actually recognize that an external hardware
interrupt has occurred
- the steps necessary to service this interrupt and to clear the interrupting condition
This lab will look at a number of things related to hardware:
How to debug interrupts using the logic analyzer
How to measure the speed of interrupt handlers
Execute software instruction
Save state, jump to service
Service the interrupt
Restore state as before interrupt
Interrupt received?
YES
No
Equipment required
HP 16702B Logic Analyzer
PC/104 or ISA bus PC
HP33120A Function Generator for Part A
Windows PC with a serial port and running a terminal (TeraTerm Pro) program
Part A : Simple Squarewave Interrupts
This portion of the lab concerns setting up a simple square wave generator to input a TTL signal at a variable frequency
through the IRQ7 hardware interrupt of a conventional 80x86 PC. In addition, the lab involves writing software to allow
this interrupt to be recognized by the 80x86 processor and to display a count of the interrupts that have been recognized.
The student is expected to have tried to fill in the steps of the LAB2A.PAS text file that has been posted to the course
website. The steps are laid out in the source file with the actual setting/clearing of register bits, as required, left to the
student. All registers of interest for the purposes of this lab are I/O mapped i.e. the bits within each register can be
accessed through the standard instructions
MOV DX,<register address>
IN AL,DX ; read an 8-bit device register value whose I/O address is <register address>
OR AL,<some value> ; set one or more bits in the register
AND AL,<some value> ; clear one or more bits in the register OUT
DX,AL ; write an 8-bit value back to the device register
The registers of interest are documented in Appendix C at the end of this lab.
Procedure
1 . Fill in the necessary code in the LAB2A.PAS file that has been supplied. This is most of the work.
2. Create an executable (.EXE) file from this code using the supplied tools (MAKE.BAT, TPC.EXE, TURBO.TPL) e.g.
C>make lab2a.pas
3. Run the LAB2A.EXE file
4. Turn on the HP33120 function generator and set it for a squarewave at about 100Hz. Connect the SYNC output of this
function generator, using a supplied BNC cable, to the little black parallel port unit with the LED lights on it (there
should be a BNC connector on the end of this unit).
4. Observe the results, which should be the following
- the 8 bit LED display should show an incrementing binary count
- the LED display should count faster or slower as the frequency of the squarewave generator is increased or
decreased
5. Measure the response time of the software. The response time will be defined as the time difference between the
rising edge of the IRQ7 interrupt signal (the squarewave) and the final execution of the code that is in the Interrupt
Service Routine. The logic analyzer will be required in order to make this measurement.
Performing time measurements on an interrupt driven system is sometimes tricky and you generally have to include your
own ‘markers’ (unique events that simplify triggering o f the logic analyzer) into the code. This code is removed after you
have done the tests that you want to do. A recommended event, immediately after you enter the ISR and save your
registers (notice that saving the DX register is now required because of this code) is the following : MOV DX,0379h ; read
the parallel port status, something unique
IN AL,DX
It is pretty much a certainty for this lab that you have the following code inside your ISR in some fashion, just before you
exit the ISR (hint here)
OUT 020h,020h ; send EOI to PIC and enable further interrupt processing
Unfortunately, this particular instruction is being executed all the time in a normal, simple PC system when other
interrupts, such as the system timer that keeps track of the time of day, are being handled. So a more unique condition
for our test would be to trigger on the two instructions: an I/O read from address 0379h followed by an I/O write to
address 020h. If you trigger on this event, a display on the logic analyzer of the IRQ7 rising edge, followed by the I/O read
and write, will give you a single picture from which you can make a timing measurement.
Measure the time from the IRQ7 rising edge to the execution of the ‘marker’ instruction above. This is the ‘interrupt
response time’ to get to the first part of your ISR. Knowing that the processor that we are using is a 40MHz 80386sx, and
knowing how many instructions are executed before executing the ‘marker’ (basically a few PUSH instructions), calculate
a more accurate value for the response time i.e. what you measured minus the time it takes to save some things on the
stack.
Now measure the time it takes to actually service the interrupt i.e. the time from the very first instruction of the ISR to the
very last. This is just the time that elapses between the ‘marker’ command and the ‘write EOI to PIC’ command. Now adjust
this time to account for the code that occurs just before the marker (the PUSH commands) and the code that occurs just
after the EOI write (the POP commands and the IRET).
6. Show the TA that you have made the measurements (two screen shots of the logic analyzer should be taken) and that
the little LEDs on the parallel port actually operate as expected.
Note:
Load your LAB1 configuration file for the Logic Analyzer. This time, you will need to add the IRQ, IOR and IOW pins to
your configuration. Refer back to Lab 1’s setup procedure, if you need more help. Refer to Appendix B for the pin layout.
**Note: IOR and IOW are located on the clock inputs. **
Part B : Serial Port Interrupts
This portion of the lab involves generating an interrupt by sending one or more serial characters over a connection
between the Windows PC at the lab station and the 80x86 microprocessor that we are testing. For the setup that we are
using, the hardware interrupt of interest is IRQ4 (serial port COM1 in a PC).
In addition, this lab involves writing software to handle this interrupt and to echo the received characters back to the
Windows PC over the serial connection. The software for this part of the lab is almost exactly the same as the previous
code, except for some setup of the serial communications chip and the use of a different IRQ signal.
Procedure 1
Make sure that you have TeraTerm Pro running on the Windows machine at your workstation and that is is setup as
shown in Appendix D. Run the ‘mode’ command on the 80x86 system as described in the appendix.
First, a quick check of the connection between the two machines. Run ‘debug; on the 80x86 machine as you did in Lab 1.
C>debug
-
Now press the ‘A’ key on the Windows machine keyboard while the TeraTerm Pro app has the focus. Then look at the
contents of the register at i/o address 0x3F8
- i 3F8
61
Hex 61 is the ASCII (a standard for encoding serial data) code for the lowercase letter ‘a’. Repeat this process (press key,
read port 0x3F8) for the letters ‘b’,’c’ and’d’ and note the codes.
Now look at the contents of the registers at 0x3F9 (IMR) and 0x3FA (IIR)
- i 3F9
00
- i 3FA
01
From the register information, this shows that no interrupts are enabled and no interrupts are pending. Now enable the
interrupt that occurs when a character is available from the serial port:
- o 3F9 01
Now press the ‘a’ key on the Windows keyboard and then read the register at 0x3FA
- i 3FA
04
This indicates that an interrupt has been generated and that the interrupt is related to the ‘Received Data Available
Interrupt’. Read the value of port 0x3FA several times to show that the interrupt is still pending (the value doesn’t
change).
Now read the value at port 0x3F8 and then the value at port 0x3FA
- i 3F8
61
- i 3FA
01
This indicates that the act of reading the serial buffer register automatically clears the interrupt condition i.e. you have
‘handled the interrupt’
Procedure 2
Now make and run the LAB2B.PAS code that you have written for the lab.
Proper operation is indicated by a simple echoing of the character pressed at the Windows keyboard i.e. if you press the
‘a’ key, you will see an ‘a’ appear in the window.
Hopefully we will have a little demonstration station setup so that you can actually see the serial communication
waveforms on an oscilloscope and see how they change with the data and with changes to the communication
parameters.
Write up and Deliverables: 1. Parallel Port Interrupt
a. Print and submit well commented code for both of the interrupts.
b. Have a TA check and verify that your parallel port interrupt counter works from the 1 to 100Hz range.
c. Using your logic analyzer, monitor the IRQ, IOR, IOW and the ADDR lines. Track the changes in the
address lines. How long does it take from receiving the interrupt to the code jump? Print out a screenshot
and hand it in.
d. Speed up the incoming clock, and see if you can make the ISR fail. How might it fail?
Appendix C (also available as a separate document) Links : http://retired.beyondlogic.org/serial/serial.htm http://retired.beyondlogic.org/spp/parallel.htm
Dir = direction, R=read, W=write, R/W=read and write
Register offset : add this to the base I/O address to access the register itself