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). ...
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 ...
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”. ...
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. ...
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). ...
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. ...
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 ...
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? ...
Introduction C++20 shipped with Concepts — a long‑awaited way to express constraints on template parameters right where they live. Concepts turn the old “SFINAE and traits soup” into clear, readable predicates that the compiler can check for you. If you’ve ever stared at a 20‑line enable_if just to say “this needs to be integral,” this feature is for you. ...
If you’ve ever stared at a blank folder wondering where do I even start?, you’re not alone. I’ve been there—more than once. ...