CSE466 Lab 4: “SPI/USB Interface”

Objectives

The goal of this lab is to extend the “Ball Lightning” project to interface to a computer using SPI and USB. In the second part of the will expand the use of the accelerometer to make a virtual phone keypad. In this lab you will learn the following:

Important Warnings

Do NOT do any of these three things:

1.      Do not plug more than one DLP2232M into a computer. To make sure the drivers worked properly on the lab image all of the DLP2232M have been setup with the same serial number. This ensures that windows will recognize the device and will automatically load the correct drivers. However this causes a problem as windows seems to have problems with two active USB devices that have the same serial number.

2.      DO NOT CONNECT POWER directly to the DLP2232M.  It will get its power from its USB connection.

3.      The ADXL202EB (the accelerometer evaluation board used in the lab) is not reverse polarity protected. Reversing the +5V and ground terminals will damage the ADXL202EB and make the part unusable.

4.      Dropping the ADXL202EB on a hard surface may generate several thousand g of acceleration, enough to damage the accelerometer.

Hints

1)      Take this lab step by step and test along the way to make sure you understand your code and it is working as you expected. Coding the entire project then trying to debug a problem can be challenging without the usual forms of debugging.  Make sure to test pieces one at a time and convincing yourself that they are working before moving on to another piece.

2)      Utilize the 7-segment LED displays for debugging. WARNING: If you update the 7-segment LED displays each time through your main loop you might not be able to read the numbers because it will be changing the number too quickly.

3)      Focus on making your system have a reasonable interface. Do not get stuck trying to make timing calculations work out perfectly. The accelerometer is inherently noisy.  The important thing is to create an interface that “feels” right to a human.  People will not notice timing errors of microseconds (maybe not even a few milliseconds depending on where it is in the code).

4)      We are using 2g accelerometers – that means they detect accelerations up to two times the force of gravity.  The parts should not be subjected to too much more than this – being dropped or banged on a hard surface. Your calculations can assume that you are only using gravity to determine how far a user has turned the accelerometer to the left or right. By using this assumption your calculations will be incorrect because they will not take into account the force you yourself apply in starting and/or stopping the accelerometer. Treat this as noise as it is difficult to account for this systematically in your calculations.

5)      Make sure to think carefully about what data needs to be exchanged over the SPI bus between your microcontroller and the FTDI chip.  Since data moves in both directions, deciding on a data packet format for each direction can ensure you get all the data you need on both sides in one transaction.

Suggested Reading

Resources

Brief introduction to AVR Programming

avr-gcc manual

Application notes section for the AVR 8-bit RISC family

Accelerometer(ADXL202) Datasheet

Accelerometer Application Note on using the Duty Cycle Output

Suggested Steps

PART 1:

 

1.      Add the USB interface to your breadboard. IMPORTANT: The USB board is preconfigured to gets it power from the USB port so DO NOT attach the USB interface to the 5V power supply of your breadboard. Refer to Figure 8a on page 14 of the DLP Design DLP-2232M datasheet in your coursepak to see how to wire up your USB Bus Powered device.

2.      Disconnect the 7-segment LED attached to Port B. Attach your USB interface board as follows:

Refer to page 2 of the ATmega16 datasheet and page 10 of the DLP Design DLP-2232M datasheet to determine the pin numbers.

3.      Download the sample SPI/USB code for the PC (files needed). You should only need to modify main.cpp for this project. FTDI466API was created to abstract away setup and DLL details. The sample code will configure the USB device to act as an SPI master and send bytes using SPI protocol. The clock rate of the transmission is initially set to 200kHz and with a latency timer of 5ms (not exposed outside of FTDI466API) that will cause the USB chip to flush information to the buffers. The latency timer bounds the amount of time your code has to wait to receive information back from the USB chip. Refer to the FTDI Chip Application Note AN2232C-01 for information about the byte commands being issued in the sample SPI/USB program. NOTE: The command byte 0x35 sends and receives bytes. It clocks data bytes out on the falling edge of the clock and clocks data bytes in on the falling edge of the clock.

 

Question 1: How many ATmega16 cycles theoretically should occur between received SPI bytes? Assume the SPI is sending bytes continuously.

 

Question 2: How many bytes will theoretically be sent/received before the latency timer forces the bytes to be flushed to the receive queue of the FTDI chip?

 

4.      Implement SPI slave functionality for your ATmega16. Test your code using the provided sample SPI/USB code. Verify your SPI slave code is working by displaying a nibble (4 bits of a byte) of the last received byte on a 7-segment LED and by sending bytes back to the PC over the SPI.

5.      Modify your ball lightning code to transmit the light level to the PC via SPI. You will need to implement your own protocol that should operate under a polling model initiated by the PC master.

6.      Create an application on the PC that displays the value of the light level.  For example, you could show a vertical bar that fills as the light gets brighter and empties as it dims.  Here is a simple figure:

                   

You should augment the capabilities of the dimmer.  Expand the UI to include these capabilities.  For example, you could add limits for how dim or how bright the light can get.  Do this, or something else of your own design.  But do add at least one extra function.

 

PART 2:

 

Part 2 of the assignment is based on a project from UW-CSE called TiltType. A paper about TiltType was published at UIST 2002.

 

1.      For this part of the assignment, you will be using both the X-axis and Y-axis of the accelerometer. Unfortunately, there is only one input capture on an ATmega16. You will need to implement your own input capture by using a timer and external interrupt.

2.      Using both the X-axis and Y-axis outputs you can detect a 2-axis tilt of the accelerometer. You will use rough classifications of tilt to create a virtual phone keypad.  Use the tilt to determine what key (0-9, *, and #) should be typed on to the screen (to an application on the PC receiving the characters from the accelerometer board). Each tilt position shown below represents a number. NOTE: The ‘0’, *, and # are obtained using an extreme tilt that is basically vertical. This means a slight down would be an ‘8’ and extreme down would be a ‘0’.

 

 

 

3.      When the button on the accelerometer board is pressed the process for number selection should begin. The user should be able to continually update the value by tilting the accelerometer. A button up signifies the user wants to select that number. While the button is being held down the user should be able to update and view on the screen what number they are currently selecting. Until the button is released the system should constantly be updating the letter on the screen that is about to be typed. Note: Level means not tilted in that dimension, Negative/Positive mean tilted left/right or down/up, respectively; Extreme means tilted very far down (very negative).  An example:

 

SCREEN: “ “ (Button Up)

SCREEN: “5“ (Button Down/Pressed, Accelerometer: Level X, Level Y)

SCREEN: “1“ (Button Down/Pressed, Accelerometer: Negative X, Positive Y)

SCREEN: “4“ (Button Down/Pressed, Accelerometer: Negative X, Level Y)

SCREEN: “4” (Button Up)

…

SCREEN: “4” (Button Up)

SCREEN: “45“ (Button Down/Pressed, Accelerometer: Level X, Level Y)

SCREEN: “45” (Button Up)

…

SCREEN: “45” (Button Up)

SCREEN: “451“ (Button Down/Pressed, Accelerometer: Negative X, Positive Y)

SCREEN: “45#“ (Button Down/Pressed, Accelerometer: Positive X, Extreme Y)

SCREEN: “453“ (Button Down/Pressed, Accelerometer: Positive X, Positive Y)

SCREEN: “453“ (Button Up)


4.   Decide where to place the functionality of this device.  You have a choice as where to determine the number pressed: on the microcontroller or on the PC.  If on the microcontroller, accelerometer values stay in the microcontroller and only characters are reported to the PC.  If on the PC, then raw accelerometer go to the PC and it does the classification to determine the character.


Question 3: Explain your design choice of where to do the computation and why you made it.

 

 

EXTRA CREDIT: Worth an additional 15% of the grade you receive for this lab.

 

  1. Extend the functionality of the phone keypad to include alphabetic characters as well as numbers.  Use a two step process.  First selecting a number (not really entering it but just entering a letter-entry mode) and then selecting a letter.  For example, if you select an ‘8’ (at a button release), then the next button down will have the user choose from ‘T’, ‘U’, or ‘V’ in the same way as you selected a number previously (you will not type the ‘8’ at this point).  Use the following scheme for 3 and 4 letter keys; examples of ‘8’ and ‘7’:

 

                      

 

  1. As you may have noticed, it is now impossible to enter a number.  Selecting a number puts the device into letter-entry mode for the next button press.  Add the ability to do a quick double-click on the number selection to get the number rather than being put into letter mode.

Deliverables

For all files turned in, the comments at the top of the file should contain:

  1. Demonstrate both Part 1 and Part 2 (and Extra Credit if Applicable) to a TA. You can either do this during this lab, or during the first 1/2 hour of the next lab.
  2. Turn in hardcopy of your commented C code for both Part 1 and Part 2 (and Extra Credit if Applicable).