I have been developing and designing embedded devices for quite a few years now. I started out using C exclusively, then started mixing in assembly (which I still love!). For quite a long time, I was one of those grumblers complaining about object oriented stuff not belonging on embedded hardware. (I still have yet to be convinced that CircuitPython or Rust on microcontrollers is a good idea, but that's another story altogether).
But then a friend of mine wrote and published a book targeted pretty much directly at developers like me -- Hands-On Embedded Programming with C++17. I started reading it, and decided what the heck, I'll give it a try. (Maya is a great writer, by the way!) So I created a new folder in my ~/workspace folder (which is a big commitment) and created a simple C++ program for the AVR ATmega328p. I chose that processor because I have about a thousand random Arduino clones laying around, and about a hundred AVR programmer clones also, making it very easy to use a quick and dirty dev platform.
I created a (gasp) class for the peripheral I was using! I even made a (shock and horror) constructor function for that class! Typedef structs full of function pointers, this is not. Though I still struggle with understanding some of the more advanced OOP concepts, and though I still fall back to C and/or assembly when I need to get something done fast, I've been forcing myself to use C++ more and more for my personal hacking projects.
I must say, from an organizational point of view, having abstraction for peripherals in a microcontroller is very appealing to me. The classic C way of doing the same task is to create a separate .c and .h file for each peripheral, and then create a struct type with the important functions and variables that the peripheral needs. This has some obvious downsides -- primarily the fact that people seem to panic whenever function pointers are mentioned, but also that managing multiple instances of that struct type can be costly and complex, especially if it's implemented as an API for others to use.
I'm still working my way into things like inheritance and operator overloading, which seem very neat as well. What I am worried about, however, is my ability to quickly prototype new things. I find that it takes me longer to write the equivalent C++ code, though this is likely just due to being less familiar with the language features, and may disappear over time. But to get to that level of familiarity, I need to force myself to use C++ in my personal projects, which again can be difficult if I just want to get something done.
I would love to hear about other embedded developers who have transitioned to using C++ from C, and whether their initial attempts looked like C++ code that got in a trainwreck with a C codebase.
Top comments (1)
Abstractions for peripherals on micro controllers is wonderful! I work somewhere that we have to target multiple micros and desktops with the same code-base and we leverage C++ for this constantly. While there are times that this bites us in a way that C wouldn't, we really gain a lot. One thing I find particularly useful is using inheritance and leveraging virtual functions for interfaces to abstract different types of IO. For instance, you could create a 'Writeable' or a 'Readable' interface that abstracts something for the application that will change depending on the target. On a micro you might be getting a discrete signal to trigger behavior, while in the desktop build it might be over a socket, or from a button.
There are other ways to handle the example I mentioned, but I think it it shows how useful C++ can be.