One of the most important themes of the project became understanding why apparently simple firmware implementations stop scaling.

A blocking peripheral call is easy to reason about: start a transfer and wait until it finishes. But while the processor waits, it cannot perform useful work elsewhere.

I explored progressively more asynchronous approaches to peripheral communication.

For SPI, I implemented data transfers using DMA, allowing the peripheral and DMA controller to move data without requiring the CPU to manually service every byte of the transaction. This gave me practical experience with configuring DMA-backed peripherals and reasoning about completion events rather than sequential blocking calls.

For UART, I implemented non-blocking communication using interrupts. Instead of stopping execution while an entire transmission completes, the firmware initiates the transfer and reacts as the peripheral becomes ready for additional data.

That distinction—between writing code that merely works and designing firmware that remains responsive while multiple things happen concurrently—is one of the most useful lessons I took from the project.

Ring buffers and data movement

Embedded firmware often has producers and consumers operating at different rates. Incoming UART bytes, sensor samples, and outgoing telemetry cannot always be processed immediately when they arrive.

To explore this problem directly, I implemented a circular ring buffer in C.

The buffer maintains independent read and write positions over a fixed-size memory region, allowing data to be inserted and consumed without repeatedly moving the contents of the underlying array. Wraparound occurs when either index reaches the end of the allocated storage.

Implementing the structure myself forced me to reason about pointer arithmetic, memory ownership, full-versus-empty conditions, and the interaction between asynchronous producers and consumers.

More importantly, it gave me a reusable primitive that appears throughout real firmware systems.

Interrupts, timers, and event-driven execution

Another major part of EmbeddedSprint was moving away from firmware whose behavior is defined entirely by the main loop.

Using STM32 external interrupts and hardware timers, I built firmware where hardware events determine when work occurs.

This introduced practical questions that do not appear when everything runs sequentially: What work belongs inside an interrupt service routine? What state is shared between an ISR and the main execution context? When should a hardware timer replace software delays? What happens when multiple asynchronous events occur close together? How do you keep time-sensitive code short enough that it does not interfere with the rest of the system?

Working through those problems made interrupts feel less like an isolated microcontroller feature and more like one part of a larger concurrency model.

Build and debug workflow

The project was also an exercise in making embedded development reproducible outside of a single IDE configuration.

STM32CubeMX provides peripheral configuration and initialization code, while the firmware is compiled using the ARM GCC toolchain through CMake. ST-LINK and OpenOCD provide the interface between the development machine and the microcontroller, while GDB provides source-level and register-level debugging.

The repository is structured so individual exercises can remain isolated while sharing the same general development workflow.

A typical iteration became: configure → compile → flash → observe → debug → modify → repeat

That loop sounds simple, but making it reliable was itself part of the project. Problems can originate from application code, peripheral configuration, clock configuration, the build system, the debugger, or the physical hardware. Learning to separate those layers dramatically improved how I approach embedded debugging.