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”




The idea is pretty simple, place traces very close to one another and it makes it impossible to drill into the case of a device without upsetting the apple cart. There are other uses as well, such as embedding them in adhesives that destroy the traces when pried apart. For [Sebastian’s] experiments he’s sticking with PCBs because of the ease of manufacture. His plugin lays down a footprint that has four pads to begin and end two loops in the mesh. The plugin looks for an outline to fence in the area, then uses a space filling curve to generate the path. This proof of concept works, but it sounds like there are some quirks that can crash KiCad. Consider 

