C++ Depth

Policy-based design — assembling behaviour at compile time

Mon, 02 Sep 2024 00:00:00 +0000

What policy-based design solves

A class often needs several independent axes of customisation: how it allocates memory, how it logs, whether it is thread-safe, what synchronisation primitive it uses. The naive approaches are:

Template parameter for each axis — proliferates specialisations.
Runtime flags and switch statements — overhead on every call.
Virtual base classes — vtable cost, forced heap allocation.

Policy-based design (popularised by Andrei Alexandrescu in Modern C++ Design) replaces all three with policy classes as template parameters. Each policy encapsulates one axis of behaviour. The host class composes them with zero runtime overhead.

Template metaprogramming and C++20 Concepts

Mon, 26 Aug 2024 00:00:00 +0000

What template metaprogramming is for

Template metaprogramming (TMP) lets you write code that is parameterised on types — and constrain which types are valid. The goal is to catch type errors at compile time rather than at runtime, and to generate specialised code per type without writing it by hand.

Practical uses:

Accept std::span<uint8_t> and std::vector<uint8_t> in one function
Restrict a container to trivially copyable types (safe for DMA transfer)
Enable different code paths depending on whether a type is signed or floating-point
Zero-cost abstractions via if constexpr

Type traits — querying types at compile time

<type_traits> provides predicates about types:

Type erasure without virtual — std::function internals and hand-rolled

Mon, 19 Aug 2024 00:00:00 +0000

What type erasure solves

Templates give you type safety and zero overhead — but they replicate code for every type, and they can’t be stored in heterogeneous containers.

Virtual dispatch gives you runtime polymorphism — but it requires inheriting from a base class, which you don’t always control.

Type erasure gives you both: store objects of any type behind a single interface, without requiring the stored types to inherit from anything.

Qt for embedded HMI — signal-slot patterns and threading

Mon, 12 Aug 2024 00:00:00 +0000

Qt for embedded systems

Qt runs on Linux-based embedded systems (i.MX6, i.CORE, Pi) via Qt for Device Creation and the eglfs or linuxfb backends — no X11 required. It also supports bare-metal MCUs (STM32, NXP) via Qt for MCUs (QUL), though QUL uses a subset of the API.

This article focuses on Qt for Linux-based embedded HMIs: an industrial panel, a touchscreen controller, or an embedded PC. The signal-slot architecture and threading patterns are the same as desktop Qt.

State machines for firmware — from enum/switch to state objects

Mon, 05 Aug 2024 00:00:00 +0000

Why firmware needs state machines

Firmware is fundamentally reactive: external events (button press, timer tick, DMA complete) drive transitions between operating modes. Without explicit state machine structure, this logic ends up as deeply nested if-else chains scattered across ISRs and task loops — correct at first, unmaintainable at scale.

This article builds up three FSM implementations for the same device: a battery-powered sensor that needs to manage its power states.

CRTP mixin examples

Mon, 29 Jul 2024 00:00:00 +0000

What a CRTP mixin is

A CRTP mixin adds behaviour to a class by making it inherit from a template base that gets the concrete class as its type parameter:

1template <typename Derived>
2class Mixin {
3    // can call Derived methods via static_cast<Derived*>(this)
4};
5
6class MyClass : public Mixin<MyClass> {
7    // MyClass now has everything Mixin provides
8};

No virtual dispatch. No vtable. The mixin is inlined at compile time.

Mixin 1: Loggable

Adds a log(msg) method that prefixes the class name:

Command pattern — undo/redo and deferred execution

Mon, 22 Jul 2024 00:00:00 +0000

Operations as objects

The command pattern encapsulates an operation as an object. Instead of calling a function directly, the caller creates a command object and passes it to an executor. The executor decides when (and whether) to run it.

This enables:

Undo/redo — each command knows how to reverse itself
Macro recording — collect commands for replay
Deferred execution — queue commands for later
Logging — log commands as they execute
Transaction rollback — execute a list; on failure, reverse all

Basic command interface

1class ICommand {
2public:
3    virtual void execute() = 0;
4    virtual void undo()    = 0;
5    virtual ~ICommand()    = default;
6};

A concrete command captures its receiver (the object it operates on) and any parameters in its constructor:

Profiling with perf and valgrind — reading the output

Mon, 15 Jul 2024 00:00:00 +0000

Measure before you optimise

Every performance optimisation should start with a measurement. Optimising by intuition produces faster-looking code that runs slower, or fast code in paths that aren’t on the hot path.

The profiler tells you:

Where time is actually spent — often not where you think
Why it’s slow — cache misses, branch mispredictions, lock contention
Whether your fix helped — before/after comparison

Two tools cover most C++ performance work on Linux: perf for hardware performance counters and CPU-level analysis; valgrind and its tools for memory errors, cache simulation, and call graph profiling.

Object pool allocator

Mon, 08 Jul 2024 00:00:00 +0000

When you need an object pool

The heap is general-purpose but problematic in real-time systems:

Non-deterministic allocation time
Fragmentation over long runtimes
Failure mode is a runtime crash, not a compile-time error

A pool allocates all memory up front in a fixed-size array. Each slot holds one object. Allocation is a pointer pop; deallocation is a pointer push. Both are O(1) and deterministic.

Use a pool when:

Objects have the same type (or same max size)
Lifetime is arbitrary (unlike arena allocators)
Allocation rate is bounded and known at compile time

Implementation

 1// object_pool.h
 2#pragma once
 3#include <array>
 4#include <cassert>
 5#include <cstddef>
 6#include <memory>
 7#include <new>
 8
 9template <typename T, size_t Capacity>
10class ObjectPool {
11public:
12    ObjectPool() noexcept {
13        // Build the intrusive free list through the storage
14        for (size_t i = 0; i < Capacity - 1; ++i)
15            slots_[i].next = &slots_[i + 1];
16        slots_[Capacity - 1].next = nullptr;
17        head_ = &slots_[0];
18    }
19
20    // Allocate raw storage — caller must placement-new the object
21    T* allocate() noexcept {
22        if (!head_) return nullptr;
23        Slot* s = head_;
24        head_   = s->next;
25        --free_;
26        return reinterpret_cast<T*>(s->storage);
27    }
28
29    // Deallocate — caller must have already destroyed the object
30    void deallocate(T* ptr) noexcept {
31        Slot* s = reinterpret_cast<Slot*>(ptr);
32        s->next = head_;
33        head_   = s;
34        ++free_;
35    }
36
37    size_t capacity() const noexcept { return Capacity; }
38    size_t available() const noexcept { return free_; }
39    bool   full()  const noexcept { return free_ == 0; }
40    bool   empty() const noexcept { return free_ == Capacity; }
41
42private:
43    union Slot {
44        alignas(T) char storage[sizeof(T)];
45        Slot* next;
46    };
47
48    std::array<Slot, Capacity> slots_;
49    Slot*  head_ = nullptr;
50    size_t free_ = Capacity;
51};

Usage — manual acquire/release

 1static ObjectPool<SensorSample, 32> pool;
 2
 3// Allocate + construct
 4SensorSample* s = pool.allocate();
 5if (s) {
 6    new (s) SensorSample{HAL_GetTick(), readVoltage()};
 7    processQueue.push(s);
 8}
 9
10// After processing — destroy + deallocate
11SensorSample* s = processQueue.pop();
12if (s) {
13    s->~SensorSample();       // explicit destructor
14    pool.deallocate(s);
15}

Usage — with unique_ptr (RAII)

unique_ptr with a custom deleter automates the destroy + deallocate step:

Layered firmware architecture — HAL to application

Mon, 01 Jul 2024 00:00:00 +0000

The monolith problem

Firmware that starts as a proof of concept ends up like this:

 1// main.cpp — 1200 lines
 2int main() {
 3    HAL_Init();
 4    MX_GPIO_Init();
 5    MX_I2C1_Init();
 6
 7    // BMP280 register access mixed with display logic
 8    uint8_t id;
 9    HAL_I2C_Mem_Read(&hi2c1, 0x76<<1, 0xD0, 1, &id, 1, 10);
10
11    // SSD1306 command bytes mixed with sensor math
12    HAL_I2C_Mem_Write(&hi2c1, 0x3C<<1, 0x00, 1, initCmds, sizeof(initCmds), 10);
13
14    float temp = (id == 0x60) ? readBmp() : 25.0f;
15    char buf[32];
16    sprintf(buf, "T: %.1fC", temp);
17    drawString(0, 0, buf);  // drawString calls HAL internally
18}

Hardware details (register addresses, I2C handles, command byte sequences) are woven through business logic. Changing from BMP280 to SHT31 means hunting through 1200 lines. Writing a unit test for the alarm logic requires a real MCU.

Event-driven architecture — event bus, pub-sub, decoupled modules

Mon, 24 Jun 2024 00:00:00 +0000

The coupling problem

Direct-call architecture — the default:

1void SensorTask::onReading(float value) {
2    display_.update(value);     // SensorTask knows about DisplayTask
3    logger_.log(value);         // SensorTask knows about Logger
4    alarmCheck_.check(value);   // SensorTask knows about AlarmCheck
5}

Adding a new consumer (say, DataRecorder) requires editing SensorTask. Removing a consumer requires finding and removing its call. Testing SensorTask in isolation requires stubs for all three dependencies.

Event-driven architecture inverts this: SensorTask publishes a TemperatureEvent; consumers register interest and receive it. SensorTask doesn’t know who’s listening.

Active object pattern — thread + queue as one class

Mon, 17 Jun 2024 00:00:00 +0000

The shared-state problem

The typical approach to multi-threading: shared data protected by mutexes.

 1class SensorManager {
 2    std::mutex   mtx_;
 3    SensorData   latest_;       // shared — both threads touch it
 4    bool         updated_ = false;
 5public:
 6    void updateFromSensor() {   // called from sensor thread
 7        std::lock_guard lk(mtx_);
 8        latest_ = readSensor();
 9        updated_ = true;
10    }
11
12    SensorData getLatest() {    // called from display thread
13        std::lock_guard lk(mtx_);
14        updated_ = false;
15        return latest_;
16    }
17};

This works for two threads, but as the number of callers grows, lock contention increases, and the reasoning about which thread owns which state becomes harder. Every method is a potential deadlock site.

Cache-friendly data structures: AoS vs SoA in practice

Mon, 10 Jun 2024 00:00:00 +0000

Why data layout matters

Modern CPUs are fast; memory is slow. A cache miss on a modern CPU costs 100–300 ns — hundreds of cycles during which the CPU stalls. Getting your data layout right can matter more than any algorithmic optimisation.

The cache line is the unit of transfer between RAM and CPU cache. On x86 and ARM Cortex-A, a cache line is 64 bytes. Accessing one byte loads 64 bytes. If the next byte you need is in the same cache line — free. If it’s 65 bytes away — another cache miss.

Factory and builder patterns

Mon, 03 Jun 2024 00:00:00 +0000

Why centralise object creation

When a subsystem creates its dependencies directly, it’s coupled to their concrete types. Changing the implementation means changing the subsystem code:

1// Sensor task creates its own dependencies — coupled to Bmp280 and UartLogger
2class SensorTask {
3    Bmp280     sensor_;   // concrete type
4    UartLogger logger_;   // concrete type
5public:
6    SensorTask() : sensor_(hi2c1), logger_(huart2) {}
7};

Testing this in isolation means having real hardware available. Swapping Bmp280 for a mock requires editing SensorTask. The factory pattern moves the creation decision outside the class that uses the object.

std::variant and std::optional — type-safe alternatives to void*

Mon, 27 May 2024 00:00:00 +0000

The void* problem

C code passes values of unknown type through void* and a tag integer:

1typedef struct {
2    int type;    // 0=int, 1=float, 2=string
3    void* data;
4} Value;
5
6// Cast based on tag — undefined behaviour if wrong
7float f = *(float*)val.data;

Nothing prevents passing the wrong type. The tag can drift out of sync with the data. The void* needs explicit memory management.

C++ improves this with union + enum, but unions are still manually managed — you can forget to set the discriminant, forget to destroy the active member, or read the wrong member.

CRTP — static polymorphism and mixins

Mon, 20 May 2024 00:00:00 +0000

The problem with virtual dispatch

Virtual functions are the standard C++ mechanism for runtime polymorphism — but they carry a cost:

Vtable pointer per object — every instance of a polymorphic class stores a hidden pointer (8 bytes on 64-bit) to its vtable
Indirect call — each virtual call loads the vtable pointer, loads the function pointer from the table, then calls through it — 2 pointer dereferences before the first instruction of your function
No inlining — the compiler can’t inline through a virtual call in the general case; it can’t see which override will be called

On a Cortex-M4 at 168 MHz, an indirect call costs 3–5 ns — negligible for most code. But for a DSP inner loop calling a processing function at 1 MHz sample rate, 3 ns per call is 0.5% of your CPU budget on that one dispatch.

Container selection guide: vector, deque, list, array

Mon, 13 May 2024 00:00:00 +0000

The default answer

Use std::vector. It’s the right container for the vast majority of use cases. Pick something else only when you have a specific reason.

This is not a cop-out — it’s the result of how CPU caches work. A vector stores elements contiguously in memory. Iterating a vector of N elements touches N cache lines in order. Every other standard container scatters elements in memory, increasing cache misses.

Thread-safe singleton — C++11 and beyond

Mon, 06 May 2024 00:00:00 +0000

The right implementation

 1class Config {
 2public:
 3    static Config& instance() {
 4        static Config inst;   // C++11 §6.7: initialisation is thread-safe
 5        return inst;
 6    }
 7
 8    void set(std::string_view key, std::string value) { /* ... */ }
 9    std::string get(std::string_view key) const { /* ... */ }
10
11private:
12    Config() = default;                          // prevent construction
13    Config(const Config&) = delete;
14    Config& operator=(const Config&) = delete;
15};
16
17Config::instance().set("baud", "115200");

That’s the entire implementation. No mutex, no std::call_once, no atomic flags.

Why it’s correct: the C++11 standard guarantees that initialisation of a block-scope static is performed exactly once, even if multiple threads reach the declaration simultaneously. The compiler inserts a thread-safe guard around the first-time initialisation.

Memory allocators: pool, arena, and avoiding heap fragmentation

Mon, 29 Apr 2024 00:00:00 +0000

The heap problem

malloc / new are designed for general-purpose allocation: arbitrary sizes, arbitrary lifetimes, arbitrary order. That generality has costs:

Fragmentation — allocating and freeing blocks of different sizes creates gaps in the heap that can’t be filled by future requests. A system that has 10 kB free can still fail a 1 kB allocation if the free space is scattered in 500-byte islands. Long-running systems (servers, embedded devices, media players) degrade over time.

Strategy pattern — policy objects vs templates

Mon, 22 Apr 2024 00:00:00 +0000

The if-else chain smell

Firmware and desktop C++ both accumulate this pattern:

1float filter(float sample, FilterType type) {
2    if      (type == FilterType::None)     return sample;
3    else if (type == FilterType::LowPass)  return lowPass(sample);
4    else if (type == FilterType::Median)   return median(sample);
5    else if (type == FilterType::Kalman)   return kalman(sample);
6    return sample;
7}

Adding a new filter means editing this function — touching tested code, risking regressions, bloating a function that had nothing to do with filter math. The same chain appears in serialisers, compression algorithms, communication protocols, and display backends.

The Strategy pattern replaces the chain with a swappable behaviour object. The caller picks which strategy to use; the algorithm is encapsulated inside it.

Move semantics and zero-copy data transfer

Mon, 15 Apr 2024 00:00:00 +0000

The copy problem

Before C++11, returning an object from a function meant copying it:

1std::vector<float> getReadings() {
2    std::vector<float> v(1000);
3    fill(v);
4    return v;  // copy — 1000 floats allocated and memcpy'd
5}
6
7auto readings = getReadings();  // another copy

Compilers applied Return Value Optimisation (RVO) in simple cases, but complex code, containers of containers, or non-trivial return paths all fell back to copies. Large data structures were passed by pointer or reference to avoid the cost.

Move semantics give C++ a type-system mechanism for transferring ownership of resources without copying them.

HAL vs bare-metal register access on STM32

Mon, 08 Apr 2024 00:00:00 +0000

The false dichotomy

The embedded community often frames HAL vs registers as a religious debate. HAL advocates point to portability and maintenance; register-access advocates point to code size and speed. Both are right in different contexts.

The useful question is not “which is better?” but “which layer of my firmware should each one live in?”

What HAL gives you

STM32 HAL (Hardware Abstraction Layer) wraps the peripheral registers in C functions with error handling, timeout logic, and DMA plumbing:

std::span and std::string_view — avoiding unnecessary copies

Mon, 01 Apr 2024 00:00:00 +0000

The problem: functions that take too much ownership

A function that processes a buffer often looks like this:

1void process(const std::vector<float>& data);

This works — but it’s over-constrained. The caller must have a std::vector. An array, a ring buffer’s internal storage, a DMA buffer on the stack — none of these can be passed without a copy or a reinterpret.

Or the raw-pointer alternative:

1void process(const float* data, size_t len);

This works with any contiguous storage — but now you’re back to raw pointers with no bounds information baked into the type, and nothing stops the caller from passing a wrong len.

Ring buffer — embedded-safe, templated

Mon, 25 Mar 2024 00:00:00 +0000

Why a ring buffer

A ring buffer (circular buffer) is the standard tool for passing data between a producer and a consumer when:

The producer and consumer run at different rates
You want no dynamic allocation
You need ISR → task communication without a mutex

It’s the hardware primitive in disguise: UARTs, SPI DMAs, and audio codecs all use ring buffers internally. Your firmware should too.

Requirements for an embedded ring buffer

No heap — fixed capacity, known at compile time
No blocking — push and pop return immediately
ISR-safe — safe when one side is a producer ISR and the other a consumer task on a single-core MCU
Power-of-two capacity — enables fast modulo via bitwise AND

Implementation

 1// ring_buffer.h
 2#pragma once
 3#include <array>
 4#include <cstddef>
 5#include <optional>
 6
 7template <typename T, size_t Capacity>
 8class RingBuffer {
 9    static_assert((Capacity & (Capacity - 1)) == 0,
10                  "Capacity must be a power of two");
11    static constexpr size_t MASK = Capacity - 1;
12
13public:
14    // Push an item. Returns false if full.
15    bool push(const T& item) {
16        const size_t w = write_;
17        const size_t next = (w + 1) & MASK;
18        if (next == read_) return false;   // full
19        buf_[w] = item;
20        write_ = next;
21        return true;
22    }
23
24    // Pop an item. Returns empty optional if empty.
25    std::optional<T> pop() {
26        const size_t r = read_;
27        if (r == write_) return std::nullopt;  // empty
28        T item = buf_[r];
29        read_ = (r + 1) & MASK;
30        return item;
31    }
32
33    bool empty() const { return read_ == write_; }
34    bool full()  const { return ((write_ + 1) & MASK) == read_; }
35
36    size_t size() const {
37        return (write_ - read_) & MASK;
38    }
39
40    size_t capacity() const { return Capacity - 1; }  // one slot reserved as sentinel
41
42private:
43    std::array<T, Capacity> buf_{};
44    volatile size_t write_ = 0;
45    volatile size_t read_  = 0;
46};

Key design choices

volatile on indices — prevents the compiler from caching the read or write index in a register. On a single-core Cortex-M where one side is an ISR, volatile is sufficient. On multi-core or with optimising compilers that reorder stores, use std::atomic<size_t> with memory_order_relaxed instead (see below).

Observer pattern — minimal C++ implementation

Mon, 18 Mar 2024 00:00:00 +0000

The pattern in one paragraph

Observer lets an object (subject) notify a list of dependents (observers) when its state changes — without knowing who they are or what they do. The subject holds a list of callbacks; observers register themselves; the subject calls each callback on change. That’s it.

Version 1 — std::function, heap-allocated list

The simplest modern C++ implementation. No inheritance required on the observer side — any callable works.

FreeRTOS task and queue design

Mon, 11 Mar 2024 00:00:00 +0000

The wrong way to start with FreeRTOS

The most common mistake when adding FreeRTOS to a project is recreating the bare-metal structure with tasks:

 1// Task 1 — reads sensor
 2void sensorTask(void*) {
 3    while (true) {
 4        g_sensorValue = readAdc();    // writes global
 5        vTaskDelay(pdMS_TO_TICKS(10));
 6    }
 7}
 8
 9// Task 2 — processes data
10void processTask(void*) {
11    while (true) {
12        float v = g_sensorValue;      // reads global — data race
13        process(v);
14        vTaskDelay(pdMS_TO_TICKS(10));
15    }
16}

This has a data race on g_sensorValue. It works on Cortex-M because 32-bit aligned reads and writes are atomic on ARMv7-M — but it’s undefined behaviour in C++, it won’t work for multi-byte types, and it’s not portable across MCU families.

Smart pointers and ownership models in C++

Mon, 04 Mar 2024 00:00:00 +0000

Ownership is the concept; smart pointers are the tool

Before unique_ptr and shared_ptr, ownership was implicit — a convention written in comments and enforced only by discipline. “Whoever calls create() must call destroy().” This worked until it didn’t: exceptions, early returns, and multiple exit paths caused leaks.

Smart pointers make ownership explicit and enforced by the type system. A unique_ptr<T> doesn’t just hold a pointer — it says “I am the sole owner of this object. When I go out of scope, the object is destroyed.”

Finite state machines — three approaches

Mon, 26 Feb 2024 00:00:00 +0000

Why state machines matter in firmware

Most firmware is a state machine whether it was designed as one or not. A device that boots, configures peripherals, waits for data, processes it, and handles errors has at least five states. When that logic lives in a tangle of flags, nested if statements, and global variables, it becomes impossible to reason about — and impossible to test.

An explicit FSM forces you to enumerate all states and all transitions. This article compares three implementation approaches using a connection manager as a running example: Idle → Connecting → Connected → Disconnecting → Idle.

Interface-based design in C++

Mon, 19 Feb 2024 00:00:00 +0000

What an interface is

In C++ there is no interface keyword. An interface is a convention: a class with only pure virtual methods and a virtual destructor. No data members, no implementation.

1struct ISensor {
2    virtual float read()  = 0;
3    virtual bool  ready() = 0;
4    virtual ~ISensor()    = default;
5};

That’s it. Any class that inherits from ISensor and implements both methods is a sensor, from the perspective of any code that depends on ISensor.

The purpose is to decouple the what from the how. Code that depends on ISensor doesn’t know — and shouldn’t care — whether it’s talking to a BMP280 over I2C, an NTC thermistor on ADC channel 3, or a sine wave generator in a unit test.

Dependency injection without a framework

Mon, 12 Feb 2024 00:00:00 +0000

What dependency injection actually is

Dependency injection (DI) is not a framework, a pattern library, or a design philosophy. It is a single, concrete technique:

Give objects what they need; don’t let them build it themselves.

That’s it. If a class constructs its own dependencies, it owns those dependencies and you can’t swap them. If a class receives its dependencies at construction, the caller decides what it gets.

 1// NOT dependency injection
 2class DataLogger {
 3    Stm32SpiFlash flash_;   // constructed here — you own it forever
 4public:
 5    DataLogger() : flash_(SPI1, GPIOA, GPIO_PIN_4) {}
 6};
 7
 8// Dependency injection
 9class DataLogger {
10    IStorage& storage_;     // injected by caller
11public:
12    explicit DataLogger(IStorage& s) : storage_(s) {}
13};

The difference is one line of code in the class and one line of code at the call site. The payoff is testability, portability, and the ability to change implementations without touching business logic.

Lock-free queues — SPSC, MPSC, and when to use each

Mon, 05 Feb 2024 00:00:00 +0000

Why lock-free

A mutex is a valid synchronisation tool. But it has a hard cost: if one thread is preempted while holding a lock, every other thread blocks until the scheduler wakes it back up. On a latency-sensitive pipeline — audio, network packet processing, game engine tick — this jitter is unacceptable.

Lock-free queues avoid this by using atomic operations that always make progress without a kernel lock. The tradeoff: correctness requires careful memory ordering, and implementation mistakes are silent, rare, and catastrophic.

Layered project structure with CMake

Mon, 29 Jan 2024 00:00:00 +0000

The problem with flat projects

Most C++ projects start with everything in one directory:

project/
├── main.cpp
├── sensor.cpp
├── sensor.h
├── logger.cpp
├── logger.h
├── uart.cpp
...
CMakeLists.txt   ← one file, 300 lines

It works until the project grows. Then you get:

a monolithic CMakeLists.txt that nobody wants to touch
headers with #include "../../../sensor.h" relative paths
no way to reuse modules in another project
tests that include half the codebase to test one function

The fix is a layered directory layout with one CMakeLists.txt per module.

ADC + DMA on STM32 — interrupt-driven pipeline architecture

Mon, 22 Jan 2024 00:00:00 +0000

The problem with polling ADC

The naive approach to reading an ADC on STM32 looks like this:

1while (true) {
2    HAL_ADC_Start(&hadc1);
3    HAL_ADC_PollForConversion(&hadc1, 10);
4    uint32_t val = HAL_ADC_GetValue(&hadc1);
5    process(val);
6}

It works for a single channel at low sample rates. It falls apart the moment you need:

multiple channels at precise intervals
CPU to do anything else while sampling
consistent timing (polling introduces jitter)

The right tool is ADC continuous conversion mode driven by DMA, with double-buffering via the half-transfer / transfer-complete interrupt pair. This article builds up that pipeline from scratch.

SOLID in practice — embedded C++ edition

Mon, 15 Jan 2024 00:00:00 +0000

Why SOLID matters on a microcontroller

A 50k-line STM32 project is exactly where SOLID hurts most when ignored. Untestable ISR handlers, 800-line main.cpp, recompiling the HAL to swap a sensor — these are the symptoms of a codebase that grew without architectural discipline.

This article walks through each principle with concrete before/after C++ examples drawn from a sensor → filter → display pipeline on STM32. Every principle gets:

a one-line definition
a violation pulled from real firmware code
a fix
a callout on why it matters on a microcontroller specifically

S — Single responsibility principle

A class should have one reason to change.