CSEP567 Lab 7: “SPI/USB Interface”

Objectives

The goal of this lab is to extend the lab 6 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:

• how to use the SPI protocol to transfer data from your microcontroller;
• how to use a controller chip for USB and use it to connect your microcontroller to a PC;
• how to transfer data from an application on the PC to your microcontroller and back; and
• use an accelerometer to create a mouse.

Important Warnings

Do NOT do any of these four 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’s 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 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 display and LCD 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

• The following sections of the ATmega16 datasheet might be helpful for this lab:
• SPI
• Interrupts
• 8-bit Timer 2
• 16-bit Timer 1
• DLP Design - DLB-2232M Module Datasheet
• FTDI Chip – FT2232C Application Note – reference for control instructions
• Accelerometer(ADXL202) Datasheet
• Accelerometer Application Note on using the Duty Cycle Output

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 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:

• DLP-2232M                           ATmega16
• TCK/SK                                  SCK
• TDI/DU/DO                             MOSI
• TDO/DI                                   MISO
• TMS/CS                                  \SS

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 SPI-USB code for the PC (files needed). The SPI-USB application contains simple code to test that you are sending and receiving bytes over USB.  You will not need to modify SPI-USB code 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 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.      In this lab you will be sending multiple bytes in both directions so you will need a protocol.  The communication protocol we will use to exchange mouse and color information between the PC and the ATmega16 is as follows:

 

 

            Bit 7: 0

            Bit 6: H/L nibble select bit

                        0: low

                        1: high

            Bits 5-4: Color select bits

                        00: reserved/unused

                        01: red

                        10: green

                        11: blue

            Bits 3-0: Color Data for selected color nibble

 

            Color data coming from the PC-side applications is always sent in the order: red high, red low, green high, green low, blue high, blue low.

 

 

            Bit 7: 1

            Bit 6: Button press bit

                        0: not pressed

                        1: pressed

            Bit 5: X-direction bit

                        0: positive

                        1: negative

            Bits 4-3: X-speed bits

                        00: stopped

                        01: slow

                        10: fast

                        11: reserved/unused

            Bit 2: Y-direction bit

                        0: positive

                        1: negative

            Bits 1-0: Y-speed bits

                        00: stopped

                        01: slow

                        10: fast

                        11: reserved/unused

 

  Timer/Poller:

The ColorSelectorCpp app for part 3 uses a timer/poller to retrieve mouse data values.  You should be sending out mouse data values on every SPI transmission, however the app will only read mouse values sent on a timer/poller SPI transmission.  The byte sent by the timer/poller is 0xFF, which is specified as reserved in our protocol.  Your program should be able to receive this byte without interfering with other program operations.

 

2.      Modify your part1 code (save a copy first) to transmit mouse control values to the PC via SPI.  Mouse control values should be based on the accelerometer x-axis and y-axis duty cycles.  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 these three speeds (stopped, slow or fast).  You should also enable the button on the accelerometer to control the mouse button value transmitted.

3.   Further modify your code to receive color values from the PC via SPI.  When the PC-side applications are sending color information to the ATmega16, color values will be sent in the following order: red high, red low, green high, green low, blue high, blue low.  Your code on the ATmega16 should make sure it has received both the high and low nibbles of a color before updating the color output. 

4.       Open the SPI-USB.cpp file and comment out the call to "spi_communicate_no_protocol" and uncomment the call to "spi_communicate_protocol".  You can assign the red, green, and blue values to different values to test that you are receiving the correct data.  The program should now also print out the results of the mouse data received.  Make sure this data is valid.

  PART 3:

1.      This part of the lab should be fairly 'plug and play'.  Download the ColorSelectorCpp Application Code here. This app is GUI-based, and should allow you to test your implementation of the protocol, as well as help you fine-tune the user interface of your mouse.  If the protocol is functioning correctly, you should be able to control the mouse cursor on the computer with the accelerometer, and be able to click the mouse button.  The Tri-Color LED on your breadboard should also respond to changes of the three color select bars.

Deliverables

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

• Both partners' full name, login and student number.
• The lab number and the part of the lab (e.g. “Lab 7, Part 2”).

1. Demonstrate accelerometer mouse to a TA.
   • Grading will focus on if it works and the reasonableness of the user interface
2. Turn in hardcopy of your commented code.
   • Make sure that the code in your interrupt handler is as minimal as possible. It is fine to update state or do a little bit of work in the interrupt handler. We will grade on how you designed your program to minimize code in the interrupt handler.