Updates

Week 6 (2/6-2/14)

I wrote out the project proposal and ordered some parts.

Week 7 (2/15-2/21)

I ordered parts last week, but shipping has been delayed due to all of the winter storms. I am expecting them to arrive on Monday, and then I can begin properly working on the project. I took this week to finish Lab 5 and study for the quiz.

Week 8 (2/22-2/28)

I began working on writing code for the microphone. I will use SPI pins to emulate I2S (SCK for the clock, MISO to read data from the microphone, and ground for LRCK). In addition, my character LCD should be arriving today, so I'm going to work on programming it to work with SPI over the weekend.

Week 9 (3/1-3/6)

This week, I tried many approaches to making my project work.

LCD

I spent last weekend attempting to make my LCD character display work. First I looked up schematics of my LCD in order to understand what each of the 16 pins was responsible for. I purchased an LCD backpack, which would allow me to use SPI to send data to the LCD and reduce the number of pins I need. I spent some time soldering the LCD to header pins so that I could use it with the backpack and with a breadboard. However, at this point I became a bit stuck. None of the tutorials or examples I found online programmed the LCD from scratch. Most tutorials used Cube or a pre-existing library specifically for LCD's. I attempted to download some of these files and libraries, just to see how they work and hopefully modify them for my own project, but I was unable to make them compile or reproduce them on my own. At this point, I decided to focus on my microphone, since it was the more important component of the project. If I ran out of time to work on the LCD, I decided that I would use UART and Termite instead.

Microphone

After failing to make the LCD work, I poured all of my energy into making the microphone work. I used SPI1 to emulate the I2S protocol and read data from the microphone. Along the way, I realized that I would not be able to connect LRCLK to ground as I originally thought: that information came from a document about interfacing PDM microphones with an STM32 microcontroller. Instead, I found a different document that explained how to use TIM2 for the LRCLK signal. I used TIM2CH3 to actually send the signal to the LRCLK pin of the microphone, and I selected PSC and ARR values to match the accepted frequencies given on the data sheet for the microphone. I used TIM2CH2 for synchronization with the BCLK (SPI SCK), setting it in slave trigger mode. In spite of my best efforts, I was unable to read any data from the microphone. The SPI data register stayed at zero, and I was unable to figure out what exactly was wrong. It is possible that my SPI read function needed to be modified in some way to accept continuous data from the microphone. Another possible problem is that the microphone transmitted 24-bit data, while SPI has a maximum data size of 16 bits. I was unable to figure out what exactly the problem was.

I then attempted to use Cube to correctly initialize all registers and get I2S working. Unfortunately, this did not end up working out. The issue is that I2S is available on the Discovery Board through the Serial Audio Interface (SAI), but there are no external SAI pins available for users. Although I could have used Cube to properly set SAI to receive data in the I2S protocol, I had no way to connect my microphone to the correct pins. I then tried to use Cube to make the SPI emulation work properly, but I had trouble working with the project and making everything compile successfully.

At this point, I have decided to switch projects and focus on making a game controlled by a Wii Nunchuk. Given that I haven't made any progress with I2S so far, I am not confident that I would be able to finish this project by the deadline. I am disappointed that I wasn't able to make my project work, but I still learned a lot about I2S and how audio data is transmitted and received. Now that I have switched to a more feasible project, I am more confident that I will be able to progress further over the next week and create a finished product by the deadline. I have updated this website with information on my new project, but my old site is available here.

Week 10 (3/7-3/13)

As of today, I have a working prototype of the game!

Nunchuk

The Nunchuk was the only part I was uncertain about working with, since we never worked with one during class. However, there was a lot of documentation online on how to use it, which was very helpful. The only real issue I ran into was with sending data. For some reason, there was a timing problem with the I2C_transmit function I was using to initialize and send commands to the Nunchuk. This caused the data transmission to get "stuck" if I tried to transmit or read multiple bytes sequentially. I was able to get around this by adding a for loop as a delay in the transmission function. Although that doesn't solve the root of the problem, the implementation does work now, which I am more concerned about at this point.

Game

I was able to work out a basic game design on Termite. I created multiple helper functions and eventually wrote a gameplay function. I ran into an issue with running out of stack memory - all of the ASCII strings I was storing were too large to fit in the stack of the CPU. However, I got around this by making those strings static, which stores them in a different memory location.

Next Steps

Right now, the game is pretty choppy and difficult to look at. I am planning to experiment with the UART Baud rate to see if I can get it to look better. In addition, I am going to add welcome and game over screens, as well as a scoring system.

Final Update (3/16/21)

My game is officially finished! Check out the demo video on my home page!

Over the weekend, I added welcome and game over screens and made the player score one point per person caught. My original plan for the software was to have interrupts that allowed the user to stop the game in the middle. However, I decided that a better use of interrupts would be the use of the SysTick timer. I realized that I needed an easily controllable delay after each frame of the game in order to let the user see the frame properly, as well as a delay between the welcome screen and the beginning of gameplay. SysTick interrupts allow me to add these precise delays. I ended up using a 3 second delay between the welcome screen and the beginning of gameplay, as well as a 0.4 second delay between each frame.

The default Baud rate of the HC-05 Bluetooth module is 9600, which was very low for this game. With such a low Baud rate, each frame printed onto Termite so slowly that you could see the lines being printed, one by one. This resulted in an effect that made it look like the plane and the obstacles were traveling upwards across the screen, rather than the plane moving side to side while the obstacles fell. Using the embedded UART communication on the Discovery board, I determined that increasing the Baud rate did improve the quality of the game. However, increasing the Baud rate of the Bluetooth module was slightly more complex than simply configuring the UART BRR register, due to the default Baud rate of the module. I had to put the module in AT mode in order to change its Baud rate, then use the UART_Write() function to send the necessary AT command to modify the Baud rate. With some experimentation, I was able to do this and modify the Baud rate to 230400. This has improved the quality of the game.

Other than these minor changes, my project has turned out pretty much the way I planned it in my project proposal. I would like to thank the staff of ECE 153B for their help!