Laboratory 2: Timed Game

Laboratory Description

In this lab, a simple game is built consisting of switches and pushbuttons to control the color of an RGB LED in order to match a pattern. A timer is used to limit the answer window time and to provide program delays.

Laboratory Goals

This laboratory is designed to further a student’s understanding of:

• Using state diagrams, flow charts, and/or pseudocode to aid in algorithm development,

• The use of timers in producing delays and timed events, and

• The implementation of interrupts.

• Techniques to produce more accurate and efficient code.

Preparation

Students should complete Activities 6, 7, and 8 prior to starting the laboratory.

Hardware and Tools

• RPI-RSLK Robotic Car

• Breadboard

• Components (provided):

  • 1x Pushbutton

  • 1x BiColor LED (BiLED)

  • Various Resistors ( 1x 510Ω, 2x 1kΩ)

• Wire (available in classroom)

Game Description

Important

The description of this lab is done almost entirely through text and video demonstration; as opposed to providing a supplementary flowchart as was done in Lab 1. Future labs will generally have additional figures or pseudocode to aid in understanding and development.

A demonstration of the laboratory functionality is provided in the video below without narration.

The main game loop consists of the player filling in gaps of a color pattern generated by the RSLK, where the color pattern is a random 5 colors in sequence. The RGB LED on the Launchpad Board is used to generate one of six different colors for each element in the color pattern. The player will use the six bumper buttons, corresponding to each of the colors, to fill in the gaps in the displayed pattern. A pushbutton is used to start and restart the game and allow the player to request a “reminder” once per game.

Gameplay

The game loop starts with the program generating a 5 element color pattern, consisting of the colors red, green, blue, purple (magenta), cyan (light blue), or yellow (white is not used). The program then lights the RGB LED with the first color in the pattern for 0.5 s, then off for 0.5 s, then lights the second color in the pattern for 0.5 s, then off for 0.5 s, and so on until the whole pattern has been displayed. After a 2 s delay, this process repeats; however, the last element is not displayed and must be entered by the player by pressing the corresponding button. While the bumper button is pressed, the RGB LED should be lit with the color associated with the bumper button and turned off when the bumper is released. The player’s answer is recorded after release of the button(s) and checked against the solution. Assuming the answer is correct, the program delays for another ~1 s and displays the pattern again, this time not showing the last two elements in the sequence; requiring the player to provide these two colors. This process repeats until either the player successfully enters the whole five color sequence, the player incorrectly enters a partial sequence, or the player runs out of time.

The BiColor LED should be lit RED when the program is displaying elements in the color sequence, GREEN when the player is supposed to be responding, and off otherwise.

During answer entry, if a player presses a second bumper while the first is pressed, it is ignored.

The player is allowed one “reminder” request per game, which when activated will re-display the entire pattern and then continue with the current round. For example, if the player requested a do-over when needing to enter the last three colors, the game will display the full sequence, pause for 2 s, then display the first two colors of the sequence, leaving the last three colors for the player to enter. To request the “reminder”, the player will press the pushbutton during color entry.

Starting/Ending

Upon boot, the program prints playing instructions to the terminal and then waits for the pushbutton to be pressed. The game loop then starts after a 1 second delay. While waiting for the pushbutton to be pressed to start the game, the program should check to see if the bumper buttons are pressed and if so light the corresponding color associated with the bumper until it is released. This functionality is added to allow the user to determine the color/bumper associations prior to playing the game.

If an incorrect sequence is input, the game should stop immediately after the incorrect portion of the answer is entered, the terminal should display a corresponding mesasge and the BiColor LED should toggle on and off RED every 0.25 s. The player should also lose if they take more than 3 s to enter each successive bumper press when answering; also resulting in a message and the BiColor LED blinking red. The 3 s timeout counter should be reset after each successful bumper press. If the player successfully enters the full 5 element sequence, the program should print a congratulations message and the BiColor LED should toggle on and off GREEN every 0.25 s. The BiColor toggling should continue until the pushbutton is pressed to start a new round.

Part A: (Class 1) Planning and Preparation

The first day of this lab consists of producing a plan for implementing the game. The group should work together to build a comprehensive program design. This design must consist of one or more flow charts thoroughly describing the actions the program must take. The flow charts elements must describe single events or actions taken; they should not be summaries of multiple functionalities. For example:

• Good flow chart items:

  • light RGB LED required color

  • check for bumper 0 press

  • wait 1 second

• Bad flow chart items (without clarification):

  • adjust RGB LED with bumper presses

  • Display next pattern

  • Read user’s sequence

Groups are encouraged to explore the possible use of state diagrams, though they are not required. Likewise, the program may be implemented using either a linear progression type implementation or a finite state machine; as described in the lecture.

Hint

Groups are strongly urged to not design/program the game such that each pattern length is written as independent code, such as:

Start Game:

Display 5 element pattern

Display 4 element pattern
Check user answer for 5th element

Display 3 element pattern
Check user answer for 4th and 10th element

...

It is obvious from the above that the repeated functionality written above would result in a huge amount of code and should instead be written using a loop, and possibly using functions to do each piece. For example:

// Loop through full sequence
    // Display first 5-*len* elements of sequence
    // Check user answer for remaining elements

Further, it may be useful to have nested for loops to do the subcomponents of the game:

// Loop through full sequence
    // Loop through first portion of array
        // Display elements
    ...

With the above being said, we will accept the program however you want to program it as long as it works, but you would be doing yourself a disservice if you don’t consider this hint!

Checkoff: The design produced by the group should be submitted to Gradescope. These designs will not be graded in-person.

Part B: (Class 2) Preliminary Development

Groups are expected to build pieces of the full game. This includes finishing:

• GPIO Initialization

  • Bumpers, pushbutton, and BiColor LED all built and working.

• Timer Initialization

  • Timer configured with 64 divider and a period that easily adds to 250 ms and 500 ms.

• Game Starting Logic

  • Printing of instructions, wait for pushbutton press and monitoring of bumper presses/lighting of RGB LED while waiting.

• RGB Lighting Logic (without timing)

  • A continuous demonstration of the RGB changing colors with respect to bumper presses.

  • Note that this functionality is also included in the previous requirement. It makes sense that this be implemented using a function!

• Initial support for displaying a color pattern with correct timings.

  • This may be simply to display the full 5 element array without requiring player entry.

Important

While Activity 8 introduced the use of interrupts with the GPIO, we highly suggest that GPIO interrupts are not used in this lab as they can be very difficult to implement and debug for this type of program.

Timer interrupts will still be needed, however.

GPIO Selection

Groups may decide which port pins to use for each component but should limit pin selection to those not used by the RSLK. The RPI-RSLK Pin Mapping page specifies all default connections. Do not use any pins that have an entry the table on that page. For the purposes of this lab, groups only need to select pins for the pushbutton and BiColor LED.

As listed in this document, the RGB LED is connected to:

• PB22: Blue Channel

• PB26: Red Channel

• PB27: Green Channel

where each segment of the LED is connected to ground (such that outputting a HIGH signal will turn the channel on). Secondary colors may be generated by turning two channels on at once and white is produced when all channels are on:

RGB Additive Color Combinations

All six of the bumper buttons must be used in this lab.

Wiring of all the external components should be consistent with the wiring required for Laboratory 1. Do not wire directly on the RSLK, please use a separate breadboard.

All inputs should have debouncing added. This may be done with the delay_cycles() function, as opposed to with the Timer; however, using the Timer to provide this functionality is acceptable. A suggested delay for debouncing is 10 ms.

Delays

The timer usage as presented in Activities 7 and 8 show how to measure time but do not show how to produce delays. Delays in code may be done through while loops, waiting for the delay condition to be met. For the case of timers, the code can be configured to wait for a specific number of timer resets to occur. Code may be added within the delay while loop if additional functionality is required, otherwise the loop can be empty, {}, or terminated with a semicolon, ;.

timer_resets = 0;         // assuming this variable is incremented in timer ISR
while(timer_resets < 10); // wait for 10 timer resets.

These delays must be implemented using interrupts and not through the methods presented in Activity 7 or using delay_cycles().

Checkoff

A successful checkoff for this portion of the lab will include a demonstration of the components as listed above.

These components may be demonstrated independently (e.g., commenting/uncommenting code, two separate projects, etc.). The grader will also request to see the associated GPIO and Timer initializations. Be prepared to discuss the implementation.

Part C: (Class 3) Finished Game

Complete the remainder of the game, demonstrate it, and submit your code to the Gradescope assignment. The game will be considered acceptable without the “reminder” request functionality implemented, however, the checkoff will only receive a check and not a check+.

Your code must have your:

• group member names,

• section,

• side, and

• seat number

added within the comment block at the top of the code. The laboratory may not be considered complete if this information is lacking.