The goal of this lab is to extend lab 3 to interface to a computer using SPI and USB. We will also use the accelerometer to make a mouse. In this lab you will learn the following:
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’s of acceleration, enough to damage the accelerometer.
5. Do not run the PC-side applications we give you from your Z drive. The .NET applications must be run from a local drive (C) or you will get JIT compilation errors.
1) Take this lab step by step and test along the way to make sure you understand your code and verify that it is working as you expected. Coding the entire project then trying to debug a problem can be challenging. Make sure to test pieces of the assignment one at a time and convince yourself that they are working before moving on to another piece.
2) Utilize the tri-color LED and JTAG for debugging. WARNING: If you update the tri-color LED each time through your main loop you might not be able to see individual color changes because they will be changing too rapidly.
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.
Brief introduction to AVR Programming
avr-gcc manual - located at: C:\WinAVR\doc\avr-libc\avr-libc-user-manual\index.html
Application notes section for the AVR 8-bit RISC family
Accelerometer(ADXL202) Datasheet
Accelerometer Application Note on using the Duty Cycle Output
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 course pak 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 SPI-USB.cpp for Part 1. 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.
Download connection-check.hex and load it onto your Atmega chip. Run it in conjunction with the SPI/USB code provided. Remember you need to run the exe file on the C drive for it to run properly. For every byte sent to the Atmega chip, a byte is recieved, which starts at 0 and is incremented by 1 for each transmission. Change the PC side byte values and the returned values will change as well. Once you have verified that you wired up the connection between the PC and your board, continue on to the next steps.
Question
1: How many ATmega16 cycles theoretically should occur between received SPI
bytes? Assume the SPI is sending bytes continuously.
Question
2: What command byte would you use to only send information on the negative
clock edge (not receive anything at the same time)? What command byte would you
use to only receive information on the negative clock edge (not send anything
at the same time)? (Hint: refer to the FT2232C Application Note AN2232C-01)
4.
Now that you have the hardware wired up correctly, you can
implement SPI slave functionality for your ATmega16, refer to the
datasheet. Test your code using the provided sample SPI/USB code. Verify your
SPI slave code is working by displaying the low 3 bits of the last
byte sent by the PC in binary on your tri-color LED (e.g. if red=high bit,
green=middle bit, blue=low bit then 0 = off, 1 = blue, 2 = green,
etc) and by sending bytes back to the PC over the SPI.
NOTE:
The datasheet states: "The
Slave may continue to place new data to be sent into the SPDR before reading the
incoming data" It also states: "
The system is single buffered in the transmit direction and double buffered in
the receive direction" This single buffer can cause a problem if the master is
constantly sending bytes and your program does not update the SPDR in time
before the next shift sends (while the send is occurring you cannot update the
buffer). Some groups will not experience this problem because they designed
their program so that they are updating SPDR fast enough. Others will have a
problem because their protocol does not cause them to send a byte in the middle
of packet. You will need to be able to consistently update the value to the SPDR
at the right time to send the data.
PART 2:
1. Now that you have a properly configured SPI slave, it is time to use the PC-Atmega USB connection to transmit some useful information. Download the ColorSelectorCpp PC Starter Code here. Although this app is GUI-based, the same FTDI466API driver will be used. Note: since this driver is written in unmanaged C++ code and the GUI uses managed C++, you must utilize a wrapper class to enable communication between the two languages. The SerialCtrl class performs the basics of this functionality but you will need to add additional functionality to enable the communications you will need.
2. Modify your lab 3 code (save a copy first) to transmit the accelerometer duty-cycle values(both X & Y) to the PC via SPI. In this lab you will be sending multiple bytes in multiple directions so you will need to develop and implement a protocol. Your protocol will need to operate under a polling model initiated by the PC master.
3. Modify SPITransaction and DecodeInput in the SerialCtrl class so that it takes the accelerometer duty cycle values and causes the mouse to move in the corresponding x and y directions. Utilize the existing methods in MouseCtrl to perform the actual mouse movement. You should have 3 speeds (stopped, slow, and fast) in all directions (X, Y and diagonals) for moving the mouse. A halfway tilt (+/-7%) should cause the mouse to move “slow” and a full tilt (+/-12.5%) should cause the mouse to move “fast”. You will be graded on creating a reasonable user interface. This means you should focus on making it easy for a person to hold the accelerometer at rest and not have the mouse move. Depending on the level of tilt the system should be at one of two speeds (slow or fast).
4. Modify the timerPoller_Tick method in Form1.h to send the RGB color information from the PC app to the Atmega chip. You may need to go back and modify SPITransaction in SerialCtrl.
5. Further modify your microcontroller code so that the LED color is generated by an RGB value received from the PC via SPI. Remember to use a protocol when sending information back and forth.
6. Extend your microcontroller and SerialCtrl class code to enable mouse-click functionality from the accelerometer button. Remember, you should focus on creating a reasonable user interface.
Question
3: Describe your protocol for sending bytes back and forth on the SPI
interface.
For all files turned in, the comments at the top of the file should contain: