Lab 2: AVR programming: buttons, lights, beeps, timing.

Assigned: Wednesday, January 12
Due date: Wednesday, January 19 (before the start of Lab 3).

You will do a lab writeup for this and all future labs. It should be a text file in which you keep notes about what you did (other than simply following these instructions), what you learned, what things didn't work and how you fixed them. It should also contain the answers to the questions posed in this writeup. You must turn in a copy of your writeup to receive credit for this lab (put it in an email or send a pointer).

0. Do the background reading

• About Microcontrollers
• C programming for the AVR

1. Complete the set-up of your ccrma environment.

• Also create a 250a directory in your home directory.

2. Microcontroller Output:

• Make yourself a copy of the FLASH demo from avrlib-demos:
  ~> cp -r avrlib-demos/flash 250a/lab2-2
  ~> cd 250a/lab2-2
• Connect the PORTD and PB/LED headers on the Atmel.
• Compile and load the FLASH program:
• Attach the serial cable to the right connector.
• Power-up the AVRmini.
• On the AVRmini, press the RESET button and within 3 seconds type:
  ~/250a/lab2-2> make load
• If it transferred, then press RESET again.
• You should see a flashing LED. Now open the code in an editor. We recommend "nedit":
  ~/250a/lab2-2> nedit flash.c
• How would you change the rate at which the light flashes?
• How would you change how long the light stays on?
• How would you flash a different LED?
• Make a program that flashes LED2 for 100 milliseconds four times per second.
• (optional) Using jumper wires, flash an LED on your protoboard with your modified program.
• Show your modified program (and circuit) to a TA for credit.

3. Microcontroller Input / Output:

a. Momentary pushbutton

• Compile and load BUTTON from the avrlib-demos:
  ~> cd
  ~> cp -r avrlib-demos/button 250a/lab2-3a
  ~> cd 250a/lab2-3a
  ~/250a/lab2-3a> make load
• When you press SW4, LED0 should light
• Notice that this requires using PORT B instead of D
• Look at the code in an editor:
  ~/250a/lab2-3a> nedit button.c
• (optional) As in #2, repeat this with a button and an LED on your protoboard.
• Show your working circuit to a TA for credit.

b. EXTRA CREDIT: Toggle pushbutton using debounce.

• Compile and load TOGGLE from the avrlib-demos:
  ~> cd
  ~> cp -r avrlib-demos/toggle 250a/lab2-3b
  ~> cd 250a/lab2-3b
  ~/250a/lab2-3b> make load
• Look at the code in an editor.
  ~/250a/lab2-3b> nedit toggle.c
• Compare button.c and toggle.c. Why is there a debounce mechanism in toggle.c but not in button.c? How does the debounce mechanism work?
• What happens if you change the debounce threshold to 1? (hint - try toggling the LED 10 times)
• What happens if you change the debounce threshold to 30000?
• Can you change it to 100000? (hint - you need to change something else, too)
• Look at button.ss - these are the instructions that are actually written to the microprocessor.
• Look in the two sections <checkButton> and <main>. Each line corresponds to one instruction of the microprocessor. What debounce threshold value would give approximately 1 second of delay between the button press and the LED lighting up? (Hint: you will need to look at the Atmel Instruction Set documentation.)
• Why is this a bad way to implement a 1 second delay? (There are at least three good reasons.)
• The right way to implement a 1 second delay is with the timer library in avrlib. Put the debounce threshold back to a reasonable value for debouncing and reintroduce the 1 second delay properly:
  • Add #include "timer.h" at the top of toggle.c
  • Add timerInit(); to the beginning of your main() procedure.
  • Add a call to the timerPause() procedure in the right place in your program.
  • In your makefile, add $(AVRLIB)/timer.c to the list of files in the definition of SRC
• Find the maximum delay time before you can notice a pause between the button press and the LED illuminating.
• Show your modified program to a TA for credit.

4. Four buttons:

• Write a program to control 4 LEDs with 4 buttons. It's up to you to do some "interaction design": think of your own way for actions with the four buttons to control the states of the LEDs. Feel free to write this program from scratch, but we recommend that you start with the FOURTOGGLE demo.
• Show your program to a TA for credit.

5. Beep:

• Load BUTTONBEEP as you did BUTTON and FLASH above.
• Make sure the blue wire from your speaker is connected to pin D5 and the black wire from the speaker to ground.
• You should hear a beep when you press SW4.
• Try inserting a pause between turning on the LED and playing the beep. In case you didn't do part 3b, here are the step-by-step instructions for using the avrlib's timer facilities:
  • Add #include "timer.h" at the top of buttonbeep.c
  • Add timerInit(); to the beginning of your main() procedure.
  • Add a call to the timerPause() procedure in the right place in your program.
  • In your makefile, add $(AVRLIB)/timer.c to the list of files in the definition of SRC
• At what point does the delay become noticeable? What if the beep comes before the light?
• Try finding the largest unnoticeable delay time as in #3 using the beep as feedback. Is it different?
• Show your modified program to a TA for credit.

6. Compile, Run and Play the AVRsimon:

• Compile the code and program the AVR:
  ~> cp -r avrlib-demos/avrsimon 250a/lab2-6
  ~> cd 250a/lab2-6
  ~/250a/lab2-6> make load
• You should now be able to play the Simon game provided. Pay attention to things you like and dislike about the flow of the game and the interaction.
• Improve the game to make it more interesting and engaging. Here are some suggestions, but feel free to come up with others:
  • Keep stats - this is an easy addition involving adding two counters for correct and incorrect performance, and adding a way to start a new game without the reset button.
  • Add levels of play - make it get progressively more difficult (e.g., longer patterns, increasing tempo)
  • Make it more interactive - give the user more choices on the style of the game (e.g., select a level)
  • Add timing - Try to evaluate the user's rhythmic accuracy
  • Change the nature of the game somehow
• Show your modified program to a TA for credit.