Weekly updates
2/10/2019 - Finished proposal
2/17/2019 - Purchased all parts
2/25/2019 - Figured out LCD connections - SPI. Began looking at previous labs to determine connections using SPI. Also downloaded color libraries to go with the LCD to display content on the screen.
3/3/2020 - We've made all the connections and are researching the documentation of LittlevGL as the LCD control. We plan to use CubeMX and its hardware abstraction layer to work with the LCD. Furthermore, we've downloaded the driver .h and .c files for the LCD, and are working on converting it from the HAL (hardware abstraction layer) form to our regular form. We've also purchased the nunchuck, but still we're currently figuring out what wire to interface it with.
-LS
3/13/20
As of now, we have changed how some of the project works. We are no longer using an external LCD as the drivers for the LCD don't seem to work properly with our STM32. Moreover, they require CubeMX and hardware abstraction layers, so we are hesitant to continue using it. Also the LCD did not have enough of a refresh rate to meet up with a proper real time game.
In order to stay within the project guidelines, We are instead going to add the distance sensor as a controller for one of the players and switch the LCD to the one on the board. Also, we shall use UART to communicate with termite on a PC in order to keep the score and commentate over the game. Here is the current setup below:
Nunchucky
As you can see, we have a player on each side of the board, with one using the distance sensor, and one using the nunchuck. For the distance sensor player, once the hand is within a certain distance, we will count that as hitting a button. The nunchuck buttons will take care of this directly. In order to communicate with the nunchuck, we have purchased a simple wire splitter for it.
In order to progress the game, we are going to use the timer that is used for the distance sensor. Every time it triggers, we will increment a variable, and once enough increments have been done, we progress the game state.
The game itself is a struct and is controlled through state machines, as described below:
Game logic class
The class itself is a collection of different things that are necessary to the game.
Tennisfield - The actual field that will be sent to the LCD.
Score - The score to be sent to Termite.
ScorePlayer1 - player 1 score
ScorePlayer 2 - player 2 score
StateMachine - The current iteration of the state machine.
Direction - used by the state machine to determine the next state.
We wanted to post the game actually running, however because of the old LCD, we ran into a problem where cubeMX deleted all data on the chip and now the STM32 cannot be stopped for reset or deletion though the stm Link utility or directly through keil. Basically the core cannot be stopped for reset as the reset itself has been overwritten. So we have ordered a new board using next day delivery to get a new board. Once that is complete, the code can be loaded onto it.