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.
game.c
- the main file where the game logic is developedLED.c
- and its correspondingLED.h
file handles the LED pin connections and functionalityLCD.c
- and its correspondingLCD.h
file handles the LCD controlhelper.c
- and its correspondinghelper.h
file abstracts several helper functions that we would need in the game logicbuttons.c
- and its correspondingbuttons.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:
- Saturday, May 6 - Finish configuring GPIO buttons and begin writing code for logic; Learn how to use LCD screen
- Tuesday, May 9 - Finish writing the logic code and write some test cases
- Friday, May 12 - Draw schematics for hardware connections
- Saturday, May 13 - Record our video demo
- Sunday, May 14 - Clean up the webpage and fill in the report
- Monday, May 15 (12 pm) - Submit this final project