For our first year design project, my partner and I decided to get a little ambitious. While the criteria for the project was to create a simple escape room feature(using switches, LEDs, etc.) using the given STM32 Nucleo board, we were also given the option to create any other project we saw fit(within reason) using the board. After some brainstorming, we had the idea to create a standalone device that would be capable of accessing an online API containing an bestiary for the popular game franchise, Pokemon.
Although this project would prove to be rather involved, we were confident we would be able to complete it, using my prior experience with electronics/Arduino and my partner’s experience with REST API calls.
In order to connect our device to the internet, we decided to use the common ESP8266 WiFi module found on Amazon. In order to make use of this, it was necessary to figure out how to initialize a second USART on the STM32, and send and receive strings with the module in order to connect to a WiFi network, and make HTTP requests over the network.
The API returns the requested data in JSON strings, but unfortunately the size of these strings was too large to fit into the memory of our microcontroller. In order to work around this, we ended up writing a simple proxy server in python that would handle the requests from our device, make the REST API call, and then strip out the relevant data and format into a much smaller string that we would be able to handle more easily on the microcontroller side.
Input from the user was read using a simple alphanumerical keypad, which proved to be the easiest option since each Pokemon has its own unique 4-digit ID number.
In order to display the information to the user, we chose to use a 240x320 pixel LCD display, accessible over the SPI bus. We chose this display over a more simple character LCD, as we felt we would be able to display more information, and potentially even some graphics if we had time.
Of course this display would prove to be a challenge to get working, as there were some hardware initialization steps to get the hardware SPI on the STM32 working correctly.
Although there was a library available online for controlling the LCD, we ran into some strange issues causing our image to be extremely garbled.
This is because there was an error in the library that prevented the display from resetting its registers to a known state, causing serious graphical issues. The solution to this problem involved sending a simple soft reset command during the initialization sequence.
Having a lot of previous experience with Arduino, I was able to tackle these challenges pretty effectively. That being said, working with the STM32Cube framework is a lot more involved and requires a bit more advanced skills in order to get things to work correctly.

Overall, we are pleased with the results of the project and it was a great learning experience. Please see the video below for a demonstration.