Hannupekka Sormunen
writes about software development, tooling and experiments.
Latest Bit
Compile-time flags without runtime cost
Wrap a preprocessor check in a explicit static constexpr inline bool (or implicit static constexpr bool which get converted to same type) and you get a clean, type-safe flag that the compiler can optimize away entirely — no #ifdef spaghetti scattered across codebases:
struct S // or class
{
static constexpr inline bool is_my_build =
#ifdef MY_BUILD
true;
#else
false;
#endif // #ifdef MY_BUILD
};
Now you can use if constexpr (is_my_build) or regular if (is_my_build) anywhere inside the class / struct — the dead branch gets eliminated at compile time either way. One #ifdef, one place, zero overhead.
Latest Posts
Cortex‑M7 without hardware part 7: loose ends
This is Part 7 — and the final part — of my Cortex‑M7 without hardware series. Parts 1 through 6 built minimal bare-metal projects that would boot on Renode and QEMU. Minimal was the key word: the linker script had no alignment or symbol exports, the startup code skipped .data copying and .bss zeroing, and main.cpp had to talk to the host through hand-rolled inline assembly. Those shortcuts were fine for proving the concept, but they left the project in a state where most of the C, and especially C++, language was technically broken. This post ties up all the loose ends. By the end, both projects have: Working initialized globals — .data is copied from flash to RAM at startup Guaranteed zero-initialized globals — .bss is zeroed before main() C++ global constructors — .init_array is iterated so static objects are constructed Standard library I/O — printf and exit work without hand-rolled assembly ...
Cortex‑M7 without hardware part 6: QEMU
This is Part 6 of my Cortex‑M7 without hardware series. Parts 1–5 used Renode to emulate an STM32F746 and GDB to poke around the running firmware. Renode is excellent — full peripheral models, scripted test benches, a rich ecosystem — but it is not small. The installer pulls in Mono, a pile of .NET assemblies, and a handful of native libraries. If all you want is “does my firmware boot and produce the right output?”, that is a lot to install. ...
Cortex‑M7 without hardware part 5: execute
This is Part 5 of my Cortex‑M7 without hardware series. We already have an ELF (Parts 1-3) and understand what it holds (Part 4). Now we finally execute it (what we all came here for) in simulator known as Renode and attach GDB to see that the ELF is running while also demonstrating a couple of classic GDB debugging tricks (printing the loop variable, watchpoints, register/memory inspection). ...
Cortex‑M7 without hardware part 4: map
Part 1 explained the linker script. Part 2 explained the startup and the vector table. Part 3 built the ELF. Now we look at the artifact that quietly ties all of those together: the linker map file. If you ever wonder “did my vector table really end up at the flash base?” or “why is my .data empty?” or “what did –gc-sections remove?” — the map file is where the answers live. 1 ...
Cortex‑M7 without hardware part 3: build
This is the third post in my Cortex‑M7 without hardware series. Parts 1 and 2 already explained the two pieces that differs from standard C/C++ -projects: the linker script and startup. So this part is building for embedded target also known as “get an ELF”. ...
Cortex‑M7 without hardware part 2: startup
This is the second post of my Cortex‑M7 without hardware series. In the first part I nailed down the linker script and memory map. Now it is time to take a look at the other half of “boot”: the vector table and the Reset_Handler. ...
Cortex‑M7 without hardware part 1: linker script
This is the first post in my Cortex‑M7 without hardware series, which aims to build an Executable and Linkable Format executable (ELF) and run it without hardware (using emulated / simulated STM32F746 microcontroller unit. 1). ...
Naming Conventions for Embedded C++
When working with embedded systems, naming might seem like a small detail, however it is not. Good naming conventions make code readable, maintainable, and portable. Poor naming, like Uart1 or Uart2, ties logic to hardware details, making future changes painful. Semantic names such as UartDebug or UartModem tell you what the peripheral in question does, not where it sits on the MCU. In this post, I’ll explore why semantic naming matters, provide a naming table for all layers, one of which I will be using in upcoming examples when writing more about embedded C++, and present sample scenarios that clarify the benefits. These recommendations are based on my experience and general best practices in embedded C++ development. ...
Empty policies: [[no_unique_address]] and EBO
On my previous post about C++ Policies, a policy-based design was used for comparators and loggers, which are stateless function objects (they only call a single function). These types are empty, but as members they still occupy space because C++ guarantees distinct addresses for distinct subobjects. With C++20’s [[no_unique_address]] or Empty Base Optimization (EBO), programmers can make these truly zero-cost, which is huge for small, hot objects like iterators or adapters.1 ...
Policies
I’ve been reading about templates a lot lately and kept seeing the word policy. Which made me realized I wanted a single post that answers the question: What is a policy? Why do C++ sources keep mentioning them? How do compile-time policies (templates) compare to runtime strategies (virtuals/std::function)? And when should which be used? ...