



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Material Type: Lab; Class: Des Microproc Syst; Subject: Electrical Engineering And Computer Science; University: University of Michigan - Ann Arbor; Term: Fall 1998;
Typology: Lab Reports
1 / 5
This page cannot be seen from the preview
Don't miss anything!




(revised Oct. 15 1:30 PM)
Introduction:
In this lab, you will modify your code from Lab 3 to use external interrupts from the UART device to notify the CPU when characters can be transmitted or received. The use of interrupts eliminates the need to poll the UART in the main program, freeing the CPU for other tasks. You will have the CPU run your LED-flashing program from Lab 2 while it uses interrupts to handle the communications tasks from Lab 3. As in Lab 3 you will use a device-driver interface to make your program independent of UART details; you will write the device-driver functions for the simulated UART and we will supply the functions for the target board UART.
Goals:
Prelab questions:
Program specification:
The functional program specification from Lab 3 is unchanged. You are to modify your program from Lab 3 to be completely interrupt-driven. This means that all processing (other than initialization) will occur as part of an interrupt service routine. In addition, your interrupt service routine should never block (wait) for the UART. (That is, you should not use the blocking ser_getchar and ser_putchar functions from Lab 3.) In any situation where you are waiting for the UART to be ready to transmit or receive, your ISR should resume the main program. Of course, you must make sure that an interrupt will occur (re-invoking the ISR) when the UART becomes ready.
Interrupt-driven I/O allows the CPU to perform other tasks instead of busy-waiting for the I/O device. Use your Lab 2 LED-flashing program as the main program. Other than adding some initialization code to the beginning, you should not have to change your Lab 2 code at all.
The simulated UART (like most UARTs) is capable of interrupting the CPU under two conditions: when the receiver data buffer is full and/or when the transmitter data buffer is empty. Note that these are the exact conditions under which the UART sets the RF bit of the RSTAT register and the TE bit of the TSTAT register, respectively (see the Lab 3 handout). Whether or not the interrupt line is actually asserted under these conditions is controlled by the IR (interrupt on receiver full) and IT (interrupt on transmitter empty) bits of the IRQCTRL UART control register (see the Details section below). In C notation, the UART will assert the CPU’s external interrupt signal if:
(RSTAT[RF] && IRQCTRL[IR]) || (TSTAT[TE] && IRQCTRL[IT])
Of course, asserting the external interrupt signal will interrupt the CPU only if the CPU’s MSR[EE] bit is set. Since both receiver-full and transmitter-empty conditions assert the same external interrupt signal, your ISR will have to determine which condition caused the interrupt.
The additional device-driver functions that you need to write for the simulated UART are as follows:
Function Name Parameters Return Value Function
ser_enable_tx_int none none enable transmitter-empty interrupts
ser_disable_tx_int none none disable transmitter-empty interrupts
Procedure (in the lab):
transmitted character to the first edge of the echoed character? Repeat this measurement for several characters.
Lab report: (due at the beginning of your next lab section)