This is the third post in my FreeRTOS series. Part 1 and part 2 were high-level blog entries detailing how FreeRTOS operates, now it is time to roll up our sleeves and start implementing FreeRTOS in an actual application, turning this series into FreeRTOS on Cortex-M7 without hardware. I have already explained my “cortex-m7-common” library on part 8 of Cortex-M7 without hardware, so if you need a refresher check it out. 1 ...
This is the second post in my FreeRTOS series. In part 1, I covered tasks and basic signaling. A deeper dive into FreeRTOS now continues with concepts such as buffers, time and memory. Finally I’ll be taking a look at how to configure FreeRTOS itself. This is the final high-level blog entry before the series moves into actual implementation. ...
This is the first post in my FreeRTOS series, which aims to expand upon my previous series Cortex-M7 without hardware by implementing a Real-Time Operating System on top of the bare-metal project. Before going directly to the FreeRTOS implementation details, this part goes through basics of operating systems in general. ...
This is the first post in my C tips for C++ developers series. I spend most of my time in C++, but lately I’ve been working on an embedded project where part of the codebase is pure C. Along the way I stumbled into a feature that made me pause and think “wait, you can do that in C?” I was writing a function to validate BLE advertising parameters and realized I could return a fully initialized struct in a single expression, almost exactly the way I would in C++. That caused me to gather more C features I had either forgotten or never learned properly into this series. ...
This is Part 8 of my Cortex-M7 without hardware series. Part 7 was supposed to be the last post. The infrastructure was complete with identical outputs, and there was nothing left to build. However, an obvious problem remained: most of the code was duplicated. Each of the projects, Renode and the QEMU, carried their own copy of the startup code, the linker script, the syscall stubs, and the C++ runtime shims. ...
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 ...
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. ...
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”. ...