Getting Started With The STM32

So this post is part tutorial, and part reminder to myself in the future when I come back to trying to do the same thing again. It describes the process of programming a SM32 L1 discovery board, specifically (for me) an STM32 L100C discovery board, but it should work with most STM32 devices with some changes. This was a free board that a friend got in a goody bag from an ARM conference. Essentially its how to create a project, how to run it in debug mode, and make a couple of LEDs flash. The basic process it the same for most STM32 boards/chips, using the STLink/V2 which most discovery boards have.

The STM32L100C-discovery board used in this tutorial

To start make sure you have the following downloaded and installed:

STM32CubeMX

Go ahead and open STM32CubeMX, and wait for it to load. Once you get to the home screen, go to File->New Project, and a new window will pop up. Now is the time to find the MCU that you are using. In the MCU/MPU Selector tab, use the series/search options to find the MCU that you are using. As I am using the STM32L100C-discovery board, I have to find and select the STM32L100RCT. When you have selected the right part, click on the start project button in the top right.

Page searching for the STM32 MCU you are using

When the project then loads up it should look like this in the pinout view.

The pinout screen when using STM32CubeMX

At this point it is a good idea to save it under File->Save Project. Save it somewhere you will remember. I have a folder specifically for STM32 projects like this.

At this point it is a good idea to get the schematic up of the board you have. If you have chosen the part view the board choice menu instead of the MCU menu, then it should fill in all the pins for you, but this tutorial should show how to assign the pins manually. For this board it has two LEDs and a button that I need to assign to pins. Remember your board may be slightly different. Schematics are often available somewhere for these discovery boards by ST, they are just difficult to find sometimes.

  • USER button: PA0
  • Green LED (LED 3): PA9
  • Blue LED (LED 4): PA8

Firstly, on the left, under System Core, select the SYS configuration, and a widow should pop out. Make sure that the drop down next to debug is set to Serial Wire. Then you can close this window using the little arrows. some of the pins in the chip diagram should have changed to green now which means they have been set.

Next we want to assign what each pin needs to do. This is done by left clicking on the pin in question and choosing its mode. So for me I need to click on PA0 and set it as GPIO_Input (as its a button) and setting PA8 and PA9 as GPIO_Output (as they are LEDs). When they are selected, they should go green.

One thing that may make life easier is naming the pins differently. If you right click on an assigned pin you can “assign user label” which will allow you to assign a label. I have assigned names like LED 3 and User button to make life easier.

An example of what the pin out should look like when you have set the pins

You probably now see how this is very useful for very complex projects where almost all the pins are going to be taken up by being connected to different inputs and outputs. You can also do things like set different clock speeds, set up ADC’s and other peripherals such as USB’s.

Now in the Project manager section, I have made sure the toolchain/IDE is set to STM32CubeIDE, and make sure the rest looks like the locations you have set and the names as well.

Now click the “Generate Code” button at the top.

STM32CubeIDE

It will generate the code and open the STM32CubeIDE. I use the recommended workspace when it prompts for it. Then the window should open. On the left hand side, go to your project name->Src->main.c and double click on main.c.

If you have a look in this main.c it will look like a lot to start with, but we just need to find the while(1) loop, for me it is line 98. The rest of the file is doing useful things for us, like setting up the pins we designated before in MX, and also setting up all the required HAL libraries.

For this next part we are going to use the HAL libraries to toggle the GPIO pins for the LED’s, and lighting them up. in the while loop between the comments USER CODE BEGIN WHILE and USER CODE END WHILE I have put:

HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_8);
HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_9);
HAL_Delay(100);

which will toggle each pin on and off every 100ms.

What my code looks like

To upload this to the board, first we build it by going to Project->Build project, and wait for the build, hopefully there should be no errors. Then, making sure the board you are uploading to is connected, go to Run->Debug. It may ask you to save the file, and go ahead and do so. Also it may ask you to switch to a new view, go ahead. Go to Run->Resume, and the LED’s on board should then flash fast!

When you wish to stop, go to Run->Stop and you should return to main.c to do some more editing.

Well done on getting this far, and if you didn’t through some parts then remember Google is your friend, but also the comments section below is open to ask questions. Equally get in touch on Twitter and share this if you found it useful. I may even be able to do more like this, for instance more on the HAL libraries.

Locating Where a Sound is Coming From

For my masters year, half the marks came from one module, the masters project. Being a team effort, we were in a group of three. Putting our heads together, and taking ideas from lecturers, we made a list of potential projects. We knew for one that I wanted to be making hardware, and the other two wanted to use/learn machine learning and maybe FPGA’s. After much deliberation we decided to make a project that listened for a sound, and using time difference of arrival worked out where the sound came from. This post is mostly about the hardware and circuitry designed for the project.

The final board for our masters project. Contains four amplifier sections for the microphones and a micro controller with USB interface.

With a world with a big focus on safety in public places, we thought it would be a good product for the security industry, potentially with links to smart cities. Imagine a shopping center, somewhere with lots of security already. They tend to have lots of security cameras, alarm systems and a dedicated guard. This isn’t uncommon in big public places/attractions, especially in the UK. Sports stadiums, train stations and museums are always looking for new ways to protect themselves and isolate problems. The example that inspired us was the horrendous shooting in Las Vegas at a concert in October 2017, just as we were picking projects. The main problem was that the security services did not know where the shooter was, meaning it took longer to get to him. If they had a system like we envisaged, the microphones would pick up the sound and triangulate it. The location could then be sent to relevant authorities to use.

The front page of the New York times just days after the Las Vegas shooting

To start with we needed microphones. We didn’t need to reinvent the wheel, and microphones can be easily bought off the shelf. For ease we used standard stage microphones, that had 3-pin XLR outputs. Although we had been warned that they would not work they had a good omnidirectional pattern, and had lots of good documentation. One issue with them is the output is balanced, which means it needs to go through a pre-amp. To get an idea of what a balanced signal is, imagine a ground connection and two signals. The two signals are the same, but one is inverted. This means when it travels down the cable it is much less susceptible to interference. This is part of the reason we liked using stage rated equipment, as sound engineers have already worked out issues with transporting sound signals long distances through noisy situations. We concluded from research that the signals could reach over 100m, which was the number we were aiming for.

One of the pre-amplifier sections used on the board, using four operational amplifiers.

Once the signal got to the box it needed to be converted to a signal that could be read by an ADC. To do this we used an INA217, a pre-amp designed for basically this purpose. An instrument amplifier, it measures the difference between the signals and amplifies them, outputting a voltage with reference to ground. The signal from the microphone is tiny, in the tens of milivolts range, so it needed some dramatic amplification to get it near the 5V ADC. The INA217 did a good job but we put a second stage amplifier to give it the extra push, as very large gains can sometimes be bad for a number of reasons. We used an OP07D but if we were to do it again we would get a rail-to-rail to get better results. This amp had a pot as one of the gain resistors so that we could easily trim the gain depending on test. Finally, the signal at this point sat between -2.5V and +2.5V so we needed to shift it up so it was between 0 and 5V. This was done with a simple shift circuit and an amplifier. We used another OP07D to make buying easier.

Me manufacturing the PCB, at this point I was inspecting to see how well it had been soldered.

From here the signal gets read by the 12 bit ADC in an STM32 microcontroller. It then streams the data via the USB to a PC where MATLAB picks it up. This is where my knowledge is a bit lacking as I did not make it. In essence MATLAB uses a machine learning algorithm that had listened to over 1000 gunshots, screams and explosions. It has categorized them, and used a number of features to notice the difference. Then when playing a new sound of one of these things (not heard by it before) it categorizes it and outputs it to the user. It also used a selection of sounds from the background to know when there is not one of these events happening, else there will false negatives.

One of our set ups to get a useful output and test the amplifiers were working properly.

All in all the project did actually work. It detected gunshots and screams being played into the microphone, and the triangulation algorithm worked, just not in real time. We managed to win the best masters project, mainly because we had good quality hardware, a partially working system and a good business case behind it. There is a lot of scope of where this project could go, and many things that could be improved, but we were happy with how it came out. I may be able to use some of the circuitry on other projects, who knows. If you are interested in more of the project, maybe some more detail about the hardware or manufacture, comment or message on Twitter. Thanks for reading.

A good example of how much difference there is between the microphones when a big sound was made. Minute distances made a big time difference.