Introduction

Do you remember these classic games - Bop It or Simon? Well, they are all memory based games. Our project aims to recreate these games. In this fun, little mini-game we have a series of LEDs and buttons. Press the start button to begin the game, wait for the sequence of lights to flash, and input the correct sequence. If you get it right, keep playing! Each level gets longer and longer. See how high your score can get before you lose!

We learned a lot this project and were able to successfully implement our idea. The game works as intended and demonstrates an understanding of an embedded system. We learned that it's hard enough to work with hardware and software, let alone trying to get both to function together properly. We had many obstacles and roadblocks with the LED/button pin connections, concurrency issues, and operations with respect to the microcontroller's clock. However, we tackled each challenge one at a time and at the end of this exerience learned a lot about embedded systems.

System Overview and Diagram

We are in the process of creating a game that tests users' reaction time and memory. The game will use 4 LEDs and 4 Buttons. At the start of the game, all buttons will be ON for 3 seconds, then they will turn off for a brief period of time. We will generate a sequence of flashing LEDs that correspond to the buttons, and there will be a wait timer for button inputs. Each LED corresponds to one of the buttons that the user needs to press. The game will continue until the user fails. If the user fails, the highest score they achieved will be displayed on the LCD. Initially, the user will have a sequence of 4 LEDs to remember. If the user gets the sequence correct, they'll get a new sequence of 4 LEDs. In order to progress and pass a level, the user must remember the prior LEDs and the four additional LEDs. The user's score will be the number of LEDs they can remember.

Hardware

The memory game system is centralized with an FRDM-KL46Z microcontroller. We soldered header pins onto the GPIO ports. We then connected 5 LEDs and 4 buttons to a 30 pin breadboard using jumper wires and resistors. We connected each LED and button to its own individual circuit. In the technical section, you can see the schematics and pin assignments.

Software

We wrote the majority of our code in the MCUExpresso IDE and Visual Studio Code. We used Git version control to maintain our code. Below you can see our file structure and what each file represented.

  1. game.c - the main file where the game logic is developed
  2. LED.c - and its corresponding LED.h file handles the LED pin connections and functionality
  3. LCD.c - and its corresponding LCD.h file handles the LCD control
  4. helper.c - and its corresponding helper.h file abstracts several helper functions that we would need in the game logic
  5. buttons.c - and its corresponding buttons.h handles initializing the switches and implements polling

Video

Technical description

The game operates in the following manner: When the reset button is pressed, the game initiates. The Clear LED illuminates, and a random pattern is generated. Following the pattern display, the Clear LED blinks three times, indicating the start of the countdown and the input phase. During this phase, the player interacts by pressing buttons. If an incorrect input is provided or the countdown reaches zero, the input phase concludes, and both the Clear LED and red LED light up. To restart the game, the reset button can be pressed. However, if the player provides the correct input before the countdown ends, the input phase stops, and the Clear LED and green LED illuminate for three seconds before turning off. At this stage, an additional pattern is introduced, and both the countdown timer and the player's score increase. This sequence repeats for each subsequent round.

In terms of logistics, the Clear LED blinks for one second, each pattern consists of four LED combinations, the countdown timer starts at three seconds and increases by four seconds per round. The Clear LED indicates that the player should not be actively participating, while the simultaneous flashing of the Clear LED and red LED signifies the player's loss, and the flashing of the Clear LED and green LED indicates the player's victory in the round.

Figure 1: Wiring Schematic

Pin Definitions:

Board

  • Reset/Start - PTC12

GPIO (Output)

  • Clear LED - PTA7
  • Red LED - PTA6
  • Green LED - PTA14
  • Blue LED - PTA15
  • Yellow LED - PTA16

GPIO (Input)

  • Btn 1 [Red] - PTE3
  • Btn 2 [Green] - PTE2
  • Btn 3 [Blue] - PTE0
  • Btn 4 [Yellow] - PTE1

Testing

Throughout the development of our project, we followed the principle of test-driven development. We created tests to validate the functionality of different elements, including the LEDs and LCD. This allowed us to have a clear understanding of the changes being made and the behavior that was expected at each stage. By following this approach, we were able to maintain a structured process and ensure that all modifications were thoroughly tested before being implemented. The use of test-driven development gave us confidence in the stability of our code and the reliability of our project.

During our development process, the practice of test-driven development played a vital role in identifying and resolving various issues in our project. Initially, we encountered confusion regarding the LEDs' active high and active low states, resulting in the incorrect functioning of PCOR and PSOR. However, we successfully resolved this problem by flipping the PCOR and PSOR, allowing the LED function to work as intended. Another challenge we faced was the inability of the LCD and LED to operate simultaneously when the LED was connected to the ground. Because we had two devices using portC and portD, and as a result, both the LCD and LED were glitching because there was no clear priority defined. To overcome this issue, we made the decision to switch from portD to portA.

Additionally, we discovered that clicking on the buttons caused an unintended reset of the LCD. To address this issue, we modified the portA (same as the LED) to portE, resulting in the desired behavior. As a result, all components, including the LCD, LED, and buttons, were functioning correctly on different ports. However, we did observe that pressing multiple buttons simultaneously would trigger a reset.

Figure 2: This is an example of one of our test cases. Here we are testing the functionality of the FSM logic. We start with a sequence of 4 LEDs. The player correctly matches the pattern, which triggers a new sequence of 4 additional LEDs. Now, the player incorrectly matches the pattern, for testing purposes and the game ends. Notice that if the player passes the level, the green LED flashes and if they lose, the red LED flashes.

Progress Update 5/5

After our project proposal was approved, we began setting up the material for our project. We obtained the necessary material including a breadboard, header pins, LED diodes, buttons, resistors, and jumper wires. We learned how to solder the header pins onto the board and test for any shorts. In order, to start with the project, we wanted to verify that the header pins were soldered correctly by building a simple LED diode circuit.

We have finished building the circuit with 5 external LEDs (clear, red, green, blue, yellow) and 4 external push buttons. When we were creating this circuit, we ran into some minor problems, such as the LEDs being burnt out. We know that our LEDs and buttons are connected to the correct GPIO ports because the LEDs all turn on and off as intended, and the LEDs toggle when a button is pressed. Now that we have the circuit ready, we can continue implementing the game logic into our code. In addition, we started planning the pins and connections for our board and GPIO devices. We reused our Lab 2, `led.c` file and extended it for multiple LED diodes and buttons.

Our timeline for the remainder of this project is to:

  1. Saturday, May 6 - Finish configuring GPIO buttons and begin writing code for logic; Learn how to use LCD screen
  2. Tuesday, May 9 - Finish writing the logic code and write some test cases
  3. Friday, May 12 - Draw schematics for hardware connections
  4. Saturday, May 13 - Record our video demo
  5. Sunday, May 14 - Clean up the webpage and fill in the report
  6. Monday, May 15 (12 pm) - Submit this final project

Work Distribution

As a three-person team, we utilized in-person meetups to finalize the project idea and communicated our progress throughout the entire process. To manage the workload especially during finals week, we distributed the work equally. Vanessa designed the logic of the game and built the circuit to ensure all the GPIO pins were working as intended. Kevin wrote several helper functions to perform the tasks in the game. Dylan wrote the website and implemented the game functionality. We always updated each other with our progress and debugged any issue through office hours.