Interruptions aren’t just a staple of our daily lives. They’re also crucial for making computer systems work as well as they do, as they allow for a system to immediately respond to an event. While on desktop computers these interrupts are less prominent than back when we still had to manually set the IRQ for a new piece of hardware using toggle switches on an ISA card, IRQs along with DMA (direct memory access) transfers are still what makes a system appear zippy to a user if used properly.
On microcontroller systems like the STM32, interrupts are even more important, as this is what allows an MCU to respond in hard real-time to an (external) event. Especially in something like an industrial process or in a modern car, there are many events that simply cannot be processed whenever the processor gets around to polling a register. Beyond this, interrupts along with interrupt handlers provide for a convenient way to respond to both external and internal events.
In this article we will take a look at what it takes to set up interrupt handlers on GPIO inputs, using a practical example involving a rotary incremental encoder.
Continue reading “Bare-Metal STM32: Please Mind The Interrupt Event” →
One of the most basic and also most versatile communication interfaces on an MCU is the UART, or Universal Asynchronous Receiver/Transmitter. Usually found in the form of either a UART or USART, the former allows for pure asynchronous serial communication, whereas the latter adds flow control. When working with MCUs, they’re also one of the most common ways to output debug information.
While somewhat trickier to set up and use than a GPIO peripheral, the U(S)ART of ST’s STM32 families is fairly uncomplicated to use, and immediately provides one with an easy way to communicate in a bi-directional fashion with a device. In this article we’ll see what it takes to get started with basic UART communication on STM32 microcontrollers.
Continue reading “Bare-Metal STM32: Universal, Asynchronous Communication With UARTs” →
In the first installment of this series we had a brief look at the steps needed to get a bare-metal application running on an STM32 microcontroller. While this allowed us to quickly get to the juicy stuff, there are two essential elements which make an MCU so easy to use. One is found on the hardware side, in the form of so-called memory-mapped I/O (input/output), the other is the information contained in the files that are passed to the linker when we build a firmware image.
Memory-mapping of hardware peripheral registers is a straightforward way to make them accessible to the processor core, as each register is accessible as a memory address. This is both convenient when writing the firmware code, as well as for testing, as we can use a memory mapping specific for unit or integration testing.
We will take an in-depth look at this way of testing, as well as how these linker script files are connected to the memory layout. Continue reading “Bare-Metal STM32: Exploring Memory-Mapped I/O And Linker Scripts” →
One of the very first examples for an MCU or SoC usually involves the famous ‘Blinky‘ example, where an LED is pulsed on and off with a fixed delay. This is actually a lot more complicated than the ‘Pushy‘ example which we looked at in the first installment of this series. The reason for this is that there’s actually quite a story behind a simple call to
delay() or its equivalent.
The reason for this is that there are many ways to implement a delay function on a microcontroller (MCU), each of which comes with their own advantages and disadvantages. On an STM32 MCU, we get to choose between essentially an active delay (
while loop), one implemented using the SysTick timer and using one of the peripheral timers. In the latter two cases we also have to use interrupts.
In this article we’ll take a look at all three approaches, along with their advantages and disadvantages.
Continue reading “Bare-Metal STM32: Blinky And The Secret Of Delay Functions” →
Some may ask why you’d want to program a Cortex-M microcontroller like the STM32 series using nothing but the ARM toolchain and the ST Microelectronics-provided datasheet and reference manual. If your first response to that question wasn’t a panicked dive towards the nearest emergency exit, then it might be that that question has piqued your interest. Why, indeed?
Definitely, one could use any of the existing frameworks to program an STM32 MCU, whether the ST HAL framework, plain CMSIS, or even something more Arduino-flavored. Yet where is the fun in that, when at the end of the day one is still fully dependent on that framework’s documentation and its developers? More succinctly, if the contents of the STM32 reference manuals still look like so much gibberish, does one really understand the platform?
Let’s take a look at how bare-metal STM32 programming works, and make the most basic example run, shall we? Continue reading “Bare-Metal STM32: From Power-Up To Hello World” →