Discussion

Practical Guide to Bare Metal C++

pjmlp: While tag dispatching used to be a widely used idiom in C++ development, it was a workaround for which nowadays there are much better alternatives with constexpr, and concepts.

myrmidon: > There are multiple articles of how C++ is superior to C, that everything you can do in C you can do in C++ with a lot of extras, and that it should be used even with bare metal developmentAn interesting perspective. Could turn it around as "everything you can do in C++ you can do in C with a lot less language complexity".My personal experience with low-level embedded code is that C++ is rarely all that helpful, tends to bait you into abstractions that don't really help, brings additional linker/compiler/toolchain complexity and often needs significant extra work because you can't really leverage it without building C++ abstractions over provided C-apis/register definitions.Would not generally recommend.

jonathrg: You definitely need discipline to use C++ in embedded. There are exactly 2 features that come to mind, which makes it worth it for me: 1) replacing complex macros or duplicated code with simple templates, and 2) RAII for critical sections or other kinds of locks.

saltmate: This seems very well written, but has a lot of requirements/previous knowledge required by a reader. Are there similar resources that fill these gaps?

birdsongs: I only skimmed the book, but I think this is an artifact of the embedded engineering side. (Something I do professionally.)I've seen a lot of new people come into my team as juniors, or regular C/C++ engineers that convert to embedded systems. There is a real lack of good, concise resources for them, and the best result I've had is just mentoring them and teaching as we go.You could look for an intro to embedded systems resource. Or just get a dev kit for something. Go different than the standard Pi or Arduino. Try and get something like a STM32G0 dev kit working and blinking its lights. It's less polished, but you'll have to touch more things and learn more.If you want, core areas I would suggest to research are the very low level operations of a processor: * How does the stack pointer work? (What happens to this during function calls? * How do parameters get passed to functions by value, by reference? What happens when you pass a C++ class to a function by value? What is a deep vs shallow copy of a C++ object, and how does that work when you don't have an OS or MMU? * Where is heap memory stored? Why do we have a heap and a stack? How do these work in the absence of an OS? * The Program Counter? (PC register). What happens to this as program execution progresses? * What happens when a processor boots, how does it start receiving instructions? (This is vague, you could read the datasheet for something like the STM32G0 microcontroller, or the general Arm Cortex M0 core.) * How are data/instructions loaded from disk to memory to cache to register? What are these divisions and why do we have them? * Basic assembly language, you should know how loads and stores work, basic arithmetic, checks/tests/comparisons, jump operations. * How do interrupts work, what's an ISR, IRQ, IVT? How do peripherals like UART, I2C (also what are these?), handle incoming data when you have a main execution thread already running on a single core processor?Some of this may be stuff you already know, or seem rudimentary and not exactly relevant, but they are things that have to be rock solid before you start thinking about how compilers for differently languages, like C++, create machine code that runs on a processor without an OS.Assembly is often overlooked, but a critical skill here. It's really not that bad. Often when working with C++ (or Rust) on embedded systems, if I'm unsure of something, my first step is to decompile and dump the assembly to investigate, or step through the assembly with GDB via a JTAG probe on the target processor if the target was too small to hold all the debug symbols (very common).Anyways, this may have been more than you were asking for. Just me typing out thoughts over my afternoon coffee.

g947o: Mind if I ask whether you speak of that from a professional embedded system engineer's perspective?

myrmidon: I do. But talking about low-level embedded stuff here.Generally, the more you deviate from your vendors "happy path", the more busy work/unexpected difficulties you will run into, and a solid grasp of how exactly architecture and toolchain work might become necessary (while staying on the "happy path" allows you to stay blissfully unaware).