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.
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 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.
Brief introduction to AVR Programming
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.
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. 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.
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. Download the ColorSelectorCpp 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 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 in each direction (X and Y) for moving the mouse (stopped, slow, and fast). 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. 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.
5. 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: