Introduction
The project aims to replicate the classic children's toy "Bop It" using a FRDM-KL46Z microcontroller board. The motivation came from the fact that the microcontroller board has several sensors and peripherals that could be used to test different inputs. This naturally fits the needs of a Bop-It game which mainly relies on giving the user different commands to execute. The other game logic simply includes giving smaller and smaller timeframes to complete commands as the game goes on, and then using a GUI and UART to display game state on a computer. The system uses various sensors such as buttons, accelerometers, and a speaker to create a similar gameplay experience to the original toy. The user is prompted with audio instructions to perform a certain action, such as "bop it," "twist it," or "pull it," and must respond within a certain timeframe. The microcontroller detects the user's input and responds with appropriate audio and visual feedback.
The FRDM-KL46Z microcontroller board will be used for the project, with the board's GPIO pins being used to connect various sensors such as buttons and accelerometers. The board's firmware will be programmed using MCUExpresso to read the input from these sensors and process them accordingly. The firmware will be programmed to detect button presses and send a corresponding signal to the board's serial port. Similarly, the accelerometer will be configured to generate a signal whenever it detects movement or changes in orientation. The firmware will be programmed to read these signals and send them to the serial port as well. On the external PC, a Python script will be used to read the serial data from the microcontroller board and parse it accordingly. The script will be configured to display the data in a suitable format on a monitor. The script will then display a visual representation of the game's progress. Overall, the project involves integrating various hardware and software components to create a working system. The microcontroller board serves as the central processing unit that collects input from the sensors and relays it to the external PC, where Python scripts is used to analyze and display the data.
Overall, we were able to accomplish integrating the accelerometer, right and left buttons, LCD, and light sensor peripherals into our game. We were also able to successfully use UART to communicate between the board and a host computer which ran a python script to display game state in a GUI and play sound. Completing this project helped us learn a lot about configuring and using a wide range of on-board peripherals. This in turn helped us achieve a much greater understanding of the FRDM-KL46Z board and its capabilities. Being able to complete this project helped us learn a lot about designing and building an embedded system.
System Overview and Diagram
The system you described consists of a board that serves as the backend of the game. The board is responsible for managing interactions with on-board peripherals, generating game instructions, keeping track of the duration of each round, and maintaining the score.
To communicate with the front-end, which is implemented in Python, the board uses UART (Universal Asynchronous Receiver-Transmitter) protocol. UART enables the transfer of data between the board and the Python-based front-end. The board transfers the relevant data, which in this case is the generated game instruction, to the front-end using UART.
Once the front-end receives the data from the board, it utilizes the Pygame library to display the instruction on the monitor. Pygame is a popular library for creating graphical user interfaces (GUIs) in Python. It provides the necessary tools for rendering graphics and handling user input.
The front-end interprets the data received from the board by converting the transferred bits into the appropriate string instruction. This interpretation process ensures that the game instruction is correctly understood and can be displayed on the GUI using Pygame.
In summary, the system involves a board that manages the game's backend operations, communicates with the front-end using UART, and generates game instructions. The Python-based front-end receives the instructions, displays them on the monitor using Pygame, and interprets the data received from the board to ensure accurate display of the game instructions.
Video
- What would be the most interesting piece of information for your fellow students?
Technical Description
To use all the sensors involed in our project we studied the SDK examples given in MCUXpresso. The examples had code that we utilized to poll the different sensors. We used the code to create functions to poll the perhiperals for each instruction and return true or false based on whether the necessary condition was met. For example, if the current instruction involved in the accelerometer we polled the accelerometer values until a threshold angle was met and returned true. Each pollung function ran a while loop that iterated until a certain deadline had passed, in which case the function returns false indicating the user failed to execute the instruction in time. This in turn ended the game. To make the deadlines work we kept a current time global variable that kept track of the time in milliseconds since the program begun. We incremented current time by one millisecond in an interrupt handler using PIT Channel 0. In the loops that polled the peripherals we then looped until current time passed by the given deadline. As more and more instructions are successfully completed the deadline for each new instructions gets shorter proportional to the current game score. The current game score is also updated on the board and on the GUI. To display the GUI we wrote a Python script that runs on a computer connected to the microcontroller. The script uses a library called PyGame to display the GUI and play background music. The python code also keeps track of the current high score as well which the board does not.Testing
To test our project we followed these general steps:
We made sure to thoroughly understand the project requirements, becoming familiar with the specific functionality needed and identifying the on-board peripherals (e.g., GPIO, UART, ADC, etc.) that were utilized.
To gain the necessary information for working with the on-board peripherals, we carefully reviewed the documentation and datasheet provided for the FRDM-KL46Z. This allowed us to understand the pin assignments, register configurations, and programming interfaces relevant to the peripherals we intended to test.
We proceeded to write the test code, creating a program specifically designed to test the functionality of the on-board peripherals. Depending on our development environment, we used a programming language such as C or C++.
Once the test code was written, we compiled it and generated a binary file. We utilized the flashing tools provided by MCUExpressoto load the binary onto the flash memory of the FRDM-KL46Z board.
We executed the test by powering on the board and running the test program. We carefully monitored the output using the available communication interfaces (e.g., UART, USB) to observe the behavior of the on-board peripherals. For example, we read sensor data from an accelerometer or controlled the LEDs using GPIO.
We validated the results by verifying that the on-board peripherals functioned as expected. We compared the observed behavior with the intended functionality described in the project requirements.
If any issues or discrepancies were found during validation, we entered the debugging phase. This involved reviewing the test code, examining the peripheral configurations, and making necessary adjustments. We repeated this process until we achieved the desired functionality and resolved any issues.
Once we were confident in the functioning of the board, we integrated the board with the GUI. We tested whether the GUI displayed the correct instructions and updated the score accurately.
Work Distribution
Initially, we set up a live share to code the basic functions and structure of the game. Then we all agreed on which on-board peripheral we wanted to work on, assigning one to each team member. Eric implemented button functionality, Charlie implemented the accelerometer functionality, while Marcus implemented the light sensor and LCD. Once this was completed, Charlie and Eric worked on getting the UART to work, and testing the back-end of the code, while Marcus created the GUI and updated the site. All together the work was distributed in a way to minimise the time to create the code, based off of team member strengths.