Conway's Game of Life Sandbox on PIC32

GUI

The basic structure of the UI main page is simple, having a series of 5 interactable features which directly influence the PIC32 itself, in addition to a simple Exit button. The basic layout on this window was constructed using the PySimpleGui library which uses window events to track what is occurring on the window at any given moment. This means whenever a button, slider, or dropdown menu is pressed, that press is tracked via “ID” given to the element on creation, and through these different IDs different logic can be executed. The button functionality exists as follows:

• LED: toggles the onboard LED of the PIC32 using a simple on/off press. Press it once and a “pushbut01” event is captured telling the logic to send the code “bt011” over serial. The main C code then interprets this as turning on the onboard LED. Turning off the LED functions the same, this time sending a “bt010” signal.
• Grid: opens up a grid selection menu for editing the initial/current state of the Game of Life on the PIC32. More detail will be gone over later, however a summary of what occurs is that a “w0” signal is sent over serial to the PIC32 which pauses the current state of the Game of Life. Immediately after, the PIC32 responds by sending over a list of all currently alive cells in a predictable string which is then read by the GUI and displayed.
• Grid Size: resizes the grid for both the GUI and onboard the PIC32 from a dropdown selection featured on the left. The “combo” dropdown window has predetermined sizes as follows - '4 x 3', '8 x 6', '16 x 12', '32 x 24', '64 x 48', and '80 x 60' - and pressing the “grid_send” button the local grid size variables are updated to the currently selected values as well as “g *width* *height*” being sent over serial as a follow up. That serial signal is interpreted by the PIC32 and the onboard grid is both wiped and resized to accommodate this new setting. Setting the new dimensions to be equal to the preexisting ones still wipes both the GUI grid and PIC32 grid.
• Wrap: a toggleable button which enables or disables the Game of Life to wrap on the PIC32. Wrapping means that once a cell or cell structure is at the edge of the grid, the cells on the opposing side, both vertical and horizontal, will act as their neighbors. This button to enable or disable the feature behaves the same as the LED button, defaulting to enable wrapping. If wrapping is off, pressing “wrap_but” will light up the button and send a “b031” signal, whereas “b030” will be sent over the serial instead. These “b03x” values are interpreted by the core game logic as either detecting neighbors on the other side of the screen or not.

Grid Window

The grid window is a separate window from the main GUI. It uses a separate GUI library, namely PySimpleGuiQT, as that library has more button sizing parameters which would be needed for displaying the larger grid dimensions. The page itself is almost entirely taken up with a grid composed of cells, the number of which is designated by width and height. Below these cells exists a row of buttons which, when pressed, enable the placement of preset structures onto the grid. Pressing any given cell on the grid without having any preset structures enabled flips said cell's value, either alive or dead. A dead cell will appear blue while a living one appears as white. Using the presets flipps all affected cells to alive, regardless of their previous state. Cells, as with other buttons inside the GUI, have unique identifiers taking the form of “cell(x, y)”. This id is generated during their initial creation process.

The grid window is accessed by pressing the “Grid” button sending a “grid_but” event signal to the internal GUI logic. This freezes the main GUI page, in addition to freezing the PIC32 Game of Life using the “w0” signal addressed earlier. When that flag is detected by the PIC32, the animation thread is stopped from proceeding to its next iteration. Once this occurs, the PIC32 sends over serial an elongated string of each living cell taken directly from the onboard logic thread. Separating each cell is a “\n”, and separating each x/y value is a “ “. Using these identifiers, a 2D list is created and then iterated over setting the GUI’s cell grid to be equal that of the PIC32’s.

Each button press or structure usage automatically updates the respective value on the PIC32 as shown in the demo. This is accomplished sending a string over serial describing the cell, its coordinates, and its updated state: “c,*x*,*y*,1/0” with the 1/0 value depending on the state being represented on the grid interface. Once the window is closed, a “w1” signal is sent via serial which is processed on the PIC32 to resume the Game of Life logic with the current cell layout.

Seen above is the “Glider Gun” premade pattern, and below represent the “Kok’s Galaxy”, in addition to the remaining four in order from right to left. Each of these patterns does something unique when the time is resumed in the Game of Life which is why they were designated as presets. Presets are made in the GUI by hardcoding where each cell will be generated after the initial one (always the bottom left) is placed. This involves taking the x and y coordinates of the initial cell and adding or subtracting indices based on where following cells should be placed. Like the standard method of selecting a single cell, these are sent over serial to the PIC32 as well.

Firstly, the locations of all cells to be set are gathered using the addition/subtraction method described above. Next each cell is tested to see whether they are inbounds or not, and if any of the cells to be generated are out of bounds the entire structure is cancelled. This is done in a bruteforce manner through try and except statements, in addition to an if statement checking if the topmost cell x value is negative as negative list indices loop around in python. Finally the serial message for each cell is sent over, and locally each button has its highlighted color and internal alive/dead value updated.

Shown above and below are the maximum and minimum dimensions of the Game of Life, 80x60 and 4x3. These cells and their sizes are initialized when the Grid Interface window is created, and each corresponds to an internal height x width y 2d array with the color of each cell equating the alive/dead state of the cell.

The grid window also displays the current state of the board if it is reopened while the game is progessing on the board. The board writes back the state of the game over serial to the GUI, which updates the grid cells to match the board's cells. The following images show the board when it is paused at a random point while running and the GUI which changed to reflect the new state.

C Code

The C Code is where we implemented the rules, calculations for, and animation of Conway’s Game of Life. We used threading in this implementation with separate threads for the animation, timer,and each of the serial connections. To set these different threads up we needed to create a number of parameters that can be preset but changed live using the GUI and hardware.These variables include: update_time (the time between updates in seconds) , num_rows, num_cols, and want_wraps. We also allocated memory for two 80x60 arrays to store both the current and past states of each of the cells, which was vital for the calculations done in the animation thread.

In the timer thread we initialize and maintain everything that the timer needs as well as the TFT and update_time calculations. The first time that the timer thread runs it hardcodes the initial state of the array onto the TFT. In this case you can change the values of the 80x60 array from 0 to 1 and this step will color those spots red to signal that they are alive. Then for every time that the thread runs it manages the timer that is displayed on the TFT and increments it every second. While it does this it uses the adc_9 to read the value of the angle sensor that we are using to determine our speed. This angle value is square rooted and divided by 15 before being added to a half. This new value is what we set update_time to. We played around with this formula a fair amount and found that this was a fairly intuitive feeling sensor.

In the animation thread the majority of the calculations for the system are done. Before the start of the calculations we make sure to set the prev_status array equal to the status array for reasons that will become clear later. The thread then loops through every cell in the display and calculates and updates to its next state. The first step in this calculation is to check each of the surrounding cells and determine the number of them that are “alive” or “dead.” This step has slight differences in calculations depending on the state of want_wraps, however, they only differ on whether or not the second points on the edge check the points on the opposite side of the TFT, otherwise, all places past the edge where there would have been cells is considered dead. This calculation is tricky due to the need to check for the row above the current cell (or the top row if wrapping is enabled) due to the fact that that row has already been updated. This is the key reason that we have the two state arrays instead of only one. All of our alive_around calculations are therefore determined by prev_status rather than the constantly updating status. Once alive_around is determined we next use the rules to determine if the cell’s state changes. If the cell is currently alive and alive_around is not 2 or 3 status for that cell becomes 0 and if the cell is dead and alive_around is 3 then the status for the cell becomes one. These are the only cases where the cell’s state changes, therefore the only time that the lights need to be updated. Drawing to the TFT is a slow process and we want to avoid it as often as possible to ensure that we can keep the update_time that we desire, therefore we decided to look at our calculations from an “every time there is a change” perspective. To finish off the thread we update the cells lights for the cells that changed and do nothing to those that do not.

Each of the serial communication threads was made to handle the changes to the global variables and arrays based on the inputs from the serial. When the GUI is used it sends strings through the serial connection and our C Code is designed to interpret and execute on this. The serial thread that we have is used for this sorting and based on what the first letter of the string is, it sends this data to the cells, buttons, grid, window, and sliders threads. Each of these threads then reads what was sent over and is able to change the global variables and either change the status array or change the way that the animation thread executes upon the cells. When wrapping is turned off in the GUI, the buttons thread would get a string that tells it to change want_wrap to 0. Our GUI is able to interact with the C Code using the serial and these threads both quickly and accurately thanks to their decoding and the sorting done by the serial thread.

Our C Code is also able to interact with the GUI across the same serial connection using the Window thread. While I mentioned before that the window thread does take an input from the GUI to start its process, it actually writes the location of every living cell back to the GUI so that it may maintain its “live” display when opening up the grid. The C Code sends this data back as a string, however, the python GUI is able to interpret these to be able to properly identify the right coordinates quickly. We did have issues with the speed of this transmission of data, increasing the delay and lowering the user utility, however, by increasing the baud rate we are now able to open the grid accurately with minimal delay.

Hardware

Although there exists no necessity for outside circuit components aside from a serial connection to be connected to a game of life simulator, it was deemed more interesting if there was some external component which gave direct control to the parameters of the game. The seemingly most intuitive would be to have an external speed controller for the iterations of game of life every second. Accomplishing this task was done with an angle sensing circuit. The angle sensing unit was attached to a wooden block to provide stability while the rest of the circuit was connected through standard breadboards.

The serial USB connection. Similar to previous labs, there were three pins connecting the PIC32 to serial, these being: RA1 the receive pin, RB10 the transmit pin, and GND. This serial communication directly interfaced with a python GUI which controlled certain parameters regarding fine motor control. The transmit pin, RB10, was used heavily in this lab to communicate the current state of the game of life back to the GUI using simple sentences. The receive pin, RA1, did the heavy lifting by collecting simple sentences from the serial input sent over by the python GUI. Those simple sentences were then stored onto a PT_term_buffer.

The angle sensing circuit connected to the PIC32 with 3 pins, the 3.3V supply, RB13, and GND. Rather than have direct connection between the angle sensor and the PIC32, it was necessary to build a low pass filter between the two in order to remove noise above a frequency of 1KHz which would be present within direct readings from the angle sensor. In order to achieve a sampling frequency of 1KHz, resistance of 100K Ohms and capacitance of 1nF were chosen giving a cutoff frequency of 1.59KHz, above the desired range but from our testing within acceptable parameters. The output from the angle sensor, that being the wire not connected to either the power supply nor GND, was then fed through said filter which also used a MCP6242 op-amp. The output from the filter is then directly connected to pin RB13.