Laboratory 2: Timed Game (Simon)

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 (see: Simon). 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

  • TI-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.

The main game loop consists of the player repeatedly attempting to match a color pattern generated by the RSLK, where the color pattern increases in length after each correct pattern match. The RGB LED on the Launchpad Board, LED2, is used to generate one of six different colors for each element in the color pattern. The player will use the six bumper buttons to repeat the color pattern back to the RSLK. A pushbutton is used to start and restart the game and allow the player to “cancel” or ingore bumper presses in case of error.

Gameplay

The game loop starts with the program generating a 10 element color pattern, consisting of the colors red, green, blue, purple (magenta), cyan (light blue), or yellow. The program then lights the RGB LED with the first color in the pattern for 0.5 s. The player is then expected to press the corresponding bumper button for this color. 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 and checked against the solution. Assuming the answer is correct, the program then displays the first two elements of the color pattern, each displayed for 0.5 s with the RGB LED off for 0.5 s in between the colors. Likewise, the player then enters two bumper presses corresponding to the shown pattern. This process repeats with the pattern length increasing by one each time until either the player enters an incorrect sequence, the player runs out of time, or the player successfully matches the 10 element color pattern.

The BiColor LED should be lit RED when the program is displaying the correct color pattern and GREEN when the player is responding. The RGB LED should also be lit with the color that the corresponding bumper button is associated with while the button is pressed; turning on when the bumper is pressed and turning off when the bumper is released.

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. When the game loop completes (either incorrect sequence is entered or the player succeeds in matching the full 10 element pattern), the terminal should print a corresponding message (e.g., “You Win!”) and then continuously toggle the BiColor LED on and off every 0.25 s; it should be blinking GREEN if the player won and RED if the player failed. The program should also print out the player’s score, which is simply the length of the last correctly entered pattern.

If an incorrect sequence is input, the game should stop immediately after the incorrect portion of the answer is entered (bumper is released without the pushbutton pressed), the terminal should display “INCORRECT!” 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 the BiColor LED blinking red. The 3 s counter should be reset after each successful bumper press. If the player successfully enters the full 10 element sequence, the program should print a congratulations/you win 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 pattern with length 1
Check user answer for pattern with length 1

Display pattern with length 2
Check user answer for pattern with length 2

...

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:

for(len=0;len<10;len++){
    // Display pattern with length *len*
    // Check user answer for pattern with length *len*
}

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

for(len=0;len<10;len++){
    for(disp=0;disp<len;disp++){
        ...
    }
}

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

Import a new Template Project and name it appropriately.

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 a /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 10 element array without cycling through different lengths.

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 pin map: RSLK_MAX_pin_map.pdf, specifies all default connections. Do not use any pins that have an entry in the “TI_RSLK Connections” column. 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:

  • P2.0: Red Channel

  • P2.1: Green Channel

  • P2.2: Blue 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:

../_images/lab2_rgb-mixing.svg

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.

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, check it off, and submit your code to the Gradescope assignment. 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 will not be considered complete if this information is lacking.