Embedded

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. ...