Practical Guide to Bare Metal C++

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.

> Could turn it around as "everything you can do in C++ you can do in C with a lot less language complexity".

No, you can't, C is lacking a lot that C++ brings to the table. C++ has abstraction capabilities with generic programming and, dare I say it, OO that C has no substitute for. C++ has compile-time computation facilities that C has no substitute for.

I find that encapsulation of devices (UART, I2C, etc.) as classes in C++ rather than global functions that take structs, etc. as input arguments in C to be much more manageable. Same for device drivers for individual sensor ICs.

> An interesting perspective. Could turn it around as "everything you can do in C++ you can do in C with a lot less language complexity".

C can't parameterize an optimal layout fixed-length bitset with zero overhead, nor can it pragmatically union error sets at scale.

With anything low level you should choose the language you’re most comfortable and competent in imo. Learning both the platform and the language is just asking for headaches, control what you can

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

I would honestly extend this sentiment out to all code. The benefits C++ has over C are much better served by Rust or Go or Python or Lisp, and if "Simple" is what you want, then C is a much better choice.

Honestly, I can't think of a single job for which C++ is the best tool.

So I use C++ heavily in the kernel. But couldn't you just set your own allocator and a couple other things and achieve the same effect and use the actual C++ STL? In kernel land, at the risk of simplifying, you just implement allocators and deallocators and it "just works", even on c++ 26.

Didn’t watch the video but as opposed to what? Printf is definitely the most efficient way to retrieve the info needed to begin initial triage especially in “hacking” or bring up where a formal process isn’t defined

Surely one of the obvious reasons you'd want tagged dispatch in C++ isn't obviated by either of those features? Or am I missing something?

Suppose Doodads can be constructed from a Foozle either with the Foozle Resigned or with the Foozle Submitted. Using tagged dispatch we make Resigned and Submitted types and the Doodad has two specialised constructors for the two types even though substantively we pass only the Foozle in both cases.

In a language like Rust all the constructors have names, it's obvious what Vec::with_capacity does while you will still see C++ programmers who thought constructing a std::vector with a single integer parameter does the same because it's just a constructor and you'd need to memorize what happens.

Most of the good parts of the STL are implemented as templates. If you are considering C++ from C, then treating it like C with the STL templates is a great first step. Over time you will discover other useful features of C++ that solve specific problems. Virtual functions in a class - better than writing a table of function pointers. Lambda - sometimes much better than a function pointer. Custom templates - better than doing the same thing in macros (at least some times). Exceptions are sometimes really nice for error handling (and contrary to popular belief are not slow) And so on - C++ has a lot of features that can be useful, but most of them are features that can also be abused in places they don't belong creating a real problem.

Templates don’t have to be complicated.

Just very basic type substitution is one of the most useful uses of templates and is useful in pretty much all software

They’re also useful when you can’t use virtual dispatch. Concepts help a lot in making that tolerable.

Sure they can get stupid complicated and ugly as hell, but you don’t have to do that. Even their basic form is very useful

That said, RAII is probably the must useful thing

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.

I like Realtime C++ (Kormanyos) and Making Embedded Systems (White)

The former is probably more what you are looking for.

I'm not a professional embedded engineer, but I do hack around it. Some books I collected:

- Applied Embedded Electronics: Design Essentials for Robust Systems by J. Twomey. It goes over the whole process making a device and what knowledge would be required for each. Making Embedded Systems, 2nd Edition by E. White is a nice complement.

- Embedded System Interfacing by M. Wolf describes the signals and protocols behind everything. It's not necessary as a book, but can help understand the datasheets and standards

- But you want to start with something like Computer Architecture by C. Fox or Write Great Code - Volume 1 - Understanding the Machine, 2nd Edition by R. Hyde. There are better textbooks out there, but those are nice introductions to the binary world.

The gist is that you don't have a lot of memory and CPU power (If you do, adapting Linux is a more practical option unless it's not suited for another reason). So all the nice abstractions provided by an OS is a no go, so you need to take care of the hardware and those are really finicky,

Why is this comment downvoted? I mean, is it downvoted because Rust is bad for embeded systems?

Bare metal firmware tends to be platform specific tho.