Laboratory 7 (individual) -- I/O devices

Worth: 40 points
Assigned: 17 February 2012
Due: 24 February 2012

Overview

In this lab, you will gain experience writing assembly-language programs and interacting with I/O devices. This assignment is to be done individually.

Each person will write a device driver and test program for one of the following I/O devices: speaker, microphone, PS/2 keyboard, USB mouse, LCD display, VGA monitor, SD card, camera. Each member of your team should choose a different I/O device. This handout also provides information about other I/O devices (SDRAM, serial port, real-time clock, Fast Fourier Transform co-processor), but these should not be chosen for this lab.

You should develop and debug your device driver and program initially on ase100. You should then run your device driver and program on a hardware E100 processor, which you will create by adding I/O controllers to your E100 processor.

E100 I/O devices and ports

The following table lists the I/O devices available for the E100, along with the ports used to communicate with each device. The links in the right column of the table provide detailed information about the behavior of each device and the test program that you should write for that device.

E100 programs communicate with I/O devices via I/O ports. There are two types of I/O ports.

The following table lists the ports for all I/O devices on the E100.
Port number Port type Definition Use
0in bits 15-0: SW[15:0] binary input
1out bits 15-0: LED_RED[15:0] binary output
2out bits 7-0: LED_GREEN[7:0] binary output
3out bits 15-0: displayed on HEX3-HEX0 hexadecimal output
4out bits 15-0: displayed on HEX7-HEX4 hexadecimal output
5in bits 15-0: real-time clock measure time
10out bit 0: lcd_command LCD display
11in bit 0: lcd_response
12out bits 3-0: lcd_x[3:0]
13out bit 0: lcd_y
14out bits 7-0: lcd_ascii[7:0]
20out bit 0: ps2_command PS/2 keyboard
21in bit 0: ps2_response
22in bit 0: ps2_pressed
23in bits 7-0: ps2_ascii[7:0]
30out bit 0: sdram_command SDRAM memory
31in bit 0: sdram_response
32out bit 0: sdram_write
33out bits 10-0: sdram_x[10:0]
34out bits 10-0: sdram_y[10:0]
35out bits 15-0: sdram_data_write[15:0]
36in bits 15-0: sdram_data_read[15:0]
40out bit 0: speaker_command speaker
41in bit 0: speaker_response
42out bits 15-0: speaker_sample[15:0]
50out bit 0: microphone_command microphone
51in bit 0: microphone_response
52in bits 15-0: microphone_sample[15:0]
60out bit 0: vga_command VGA monitor
61in bit 0: vga_response
62out bit 0: vga_write
63out bits 9-0: vga_x1[9:0]
64out bits 8-0: vga_y1[8:0]
65out bits 9-0: vga_x2[9:0]
66out bits 8-0: vga_y2[8:0]
67out bits 7-0: vga_color_write[7:0]
68in bits 7-0: vga_color_read[7:0]
70out bit 0: mouse_command USB mouse
71in bit 0: mouse_response
72in bits 15-0: mouse_deltax
73in bits 15-0: mouse_deltay
74in bit 0: mouse_button1
75in bit 0: mouse_button2
76in bit 0: mouse_button3
80out bit 0: sd_command SD card
81in bit 0: sd_response
82out bits 14-0: sd_address_low[14:0]
83out bits 14-0: sd_address_high[14:0]
84in bits 15-0: sd_data[15:0]
90out bit 0: serial_receive_command serial port
91in bit 0: serial_receive_response
92in bits 7-0: serial_receive_data[7:0]
100out bit 0: serial_send_command
101in bit 0: serial_send_response
102out bits 7-0: serial_send_data[7:0]
110out bit 0: fft_send_command Fast Fourier Transform
111in bit 0: fft_send_response
112out bits 15-0: fft_send_real[15:0]
113out bits 15-0: fft_send_imaginary[15:0]
114out bits 0: fft_send_inverse
115out bit 0: fft_send_end
120out bit 0: fft_receive_command
121in bit 0: fft_receive_response
122in bits 15-0: fft_receive_real[15:0]
123in bits 15-0: fft_receive_imaginary[15:0]
130out bit 0: camera_command camera
131in bit 0: camera_response
132out bits 9-0: camera_x[9:0]
133out bits 8-0: camera_y[8:0]
134out bits 1-0: camera_scale[1:0]

I/O device protocol

At first glance, it seems easy to send data to/from an I/O device. For example, one could send a sample to the speaker simply by executing an out instruction on port 42 (the speaker_sample port). While this does change the current value of the speaker_sample port, this is not quite enough to send a sequence of values. One problem is that the speaker controller doesn't know when the program has set the speaker_sample port to the next sample. Another problem is that the program doesn't know when the speaker controller has read the last sample and is ready to receive the next sample. These problems are addressed by an I/O device protocol.

A protocol is used to guide the interaction between two parties. In the context of I/O devices, an I/O protocol is used to guide the interaction between an E100 program and an I/O device. A protocol defines the steps involved in the interaction and includes how each party knows when the current step is complete. We will use a protocol to send commands to an I/O device and receive the response from that device.

The part of an E100 program that implements the E100's side of an I/O protocol is called a device driver.

The I/O protocol uses four types of signals to allow an E100 program to send commands to a device and receive the response from that device.

The steps involved in sending data to an output device are:
command response Description
0 0 System is idle.
1 0 E100 program sets the command parameters to describe the desired command, then sets command to 1 to ask the device to execute the command. After setting command to 1, the E100 program waits for device to execute the command.
1 1 After the device executes the command, it sets the response parameters for the command, then sets response to 1 to tell the E100 program that it has executed the command and is sending back the response. After setting response to 1, the device waits for the E100 program to set command to 0.
0 1 E100 program sets command to 0 to tell the device that the program has seen the device's response. After this state, the device sets response back to 0, and the system returns to the Idle state.

Pre-lab assignment

Your pre-lab assignment is to write, test, and debug your device driver and test program. These tasks can be done by running the E100 assembler and simulator, ase100. Debugging on ase100 is much easier than debugging on the DE2 because you can control the execution of your program and view its state as it executes.

Your test program and device drivers should be in separate files. Include the device driver file in your test program by adding a line at the end of your test program, such as:

#include driver.e

Most of your testing and debugging should occur before your lab section. The lab section is meant for running final tests on the DE2 board and for demonstrating your program to a lab instructor.

In-lab demonstration

Demonstrate your test program and device driver on the DE2 to a lab instructor. After you've demonstrated your program, submit the final version of your test program and device driver.