# C++ in Embedded Electronics - Literature [closed]

Recently, we've been discussing the use of C++ in (small) embedded systems. As all examples from controller vendors I have seen in the past are tailored to the use of C this is basically what we've been using.

I would like to know if there is any literature which would get me started in this area. Basically I know C on Microcontrollers and C++ in "normal" PC environments. Yet, I would like to know more how I correctly map registers to my classes (or the other way round), how to deal with interrupts (or if there is anything special I need to know), which parts of C++ I may use (I will probably want to try to stay away from dynamic memory management, templates or exceptions) and so on. I am NOT looking for a general C++ start.

## closed as primarily opinion-based by PeterJ, Daniel Grillo, Keelan, Ricardo, tcrosleyFeb 25 '15 at 21:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

See Effective C++ in an Embedded Environment by C++ Guru Scott Meyers. It's not a book, but a set of annotated presentation slides that show many C++ specific patterns for using C++ in embedded systems and some wisdom on what not to do.

I also love the paper C++ Hardware Register Access Redux by Ken Smith. It shows how one can use C++ template metaprogramming to provided compile-time enforcement of certain register access policies such as read-only/read-write/write-only.

There was also a great article on embedded.com discussing interrupt handling in C++, but it seems embedded.com is no more. Check the wayback machine for possible cached copy.

The Arduino is also a C++ API, so it's a good, practical example of using C++ for embedded systems.

Another great resource is STM32PLUS - A C++ Library for STM32 Development by Andy Browne. Open Source and lots of great information in his blog.

• Thank you for this great answer. Regardin Embedded.com - it works for me - do you refer to that article: embedded.com/design/prototyping-and-development/4023817/… ? – Tom L. Feb 22 '15 at 7:31
• @TomL., Yes that's the article. I couldn't access embedded.com when I wrote this answer, but it appears to be online now. – Verax Feb 23 '15 at 4:20

Maybe give this a try: Christopher Kormanyos, "Real-Time C++ - Efficient Object-Oriented and Template Microcontroller Programming", Springer Verlag, 2013. I've finished it just a few weeks ago (mostly bedtime reading), and the material was interesting enough that I'll make a second pass - I want to see which of the techniques he describes work for me, in my environment, so I'll probably try to convert a few of my smaller AVR C projects to C++ as I go.

If this got you interested: the book's page at Springer.com has downloadable PDFs for the table of contents, preface and a full sample chapter (Chapter 7, "Accessing Microcotroller Registers" - although that's not my favourite chapter), and the author maintains a Github Repository with sample/reference projects.

• Thank you very much for your answer. I will definitely look into it. – Tom L. Feb 22 '15 at 7:32

Ooof. I would have to hear a really good practical reason behind why the features of C++ make any sense for microcontroller-level projects, in order to justify the expense of the language. However, I think what might serve you best here is to start by reviewing the board support package from any chip vendor. For example, take a look at the gcc libraries supplied by TI/Atmel/Microchip for their devices. In those libraries, the vendor will assign register addresses to friendly names (like PORTB or SREG, etc). This will give you an idea of how to make your own or modify it (should you need to) in any other language. Although, you probably won't need to make much modification to these and could simply include using extern "C" {}.

Secondly, you might want to read up on the chip vendor's compiler or gcc extension to get an idea of how they map ISRs (interrupts) to function calls. Often, this is also done in the BSP, or otherwise they will use some non-standard syntax which only their compiler can parse.

Finally, if you are convinced C++ is the way to go, have a look at some design pattern material as a way to set rules for yourself and team. This will help you better construct your software in the dangerous jungle that is C++, and perhaps maximize your value from it. One resource that worked well for me is Head First Design Patterns.

• Well, reasons are given in this thread: electronics.stackexchange.com/questions/3027/…. Regarding the use of BSPs from chip vendors: I checked the ones from Atmel Studio. All of them are intended for C, when you create a new C++ project it will give you an "empty" project. Do you know of any sample (doesn't need to be Atmel) projects? – Tom L. Feb 3 '15 at 6:52
• For one, try to get out of their IDEs, it is probably confusing the problem. Go with GCC if you can (even at the cost of performance, for now). A BSP written in C will likely be sufficient for anything you write in C++. This is because the BSP libraries are mostly just vector tables, #defines, and possibly some wrapper routines (which are most likely portable). So for na MCU like the Atmel ATTiny88, for example, you'll have one file that just maps registers to labels. This can be linked into a C++ project. – NateFisher Feb 3 '15 at 7:05
• Quiz question, @Nate. What features of C++ are so heavy that they require special justification in the context of small embedded systems? – Nick Alexeev Feb 3 '15 at 7:29
• @NickAlexeev I guess I look at it as more opportunity for complexity. In general I'd strive to simplify, whereas C++ introduces a complexity, which may be justified in projects at a certain scale, although likely not in ~1kloc designs. Also, the modularity argument doesn't stand, you can get modularity in C with a combination of design patterns, style and storage class specifiers. – NateFisher Feb 3 '15 at 7:42
• @Nate The question "Is C++ right for embedded?" has been a subject of moderately religious conflict. I tend towards the C++ side. So, I keep track of statements like "Bad management/process/developers ⇒ bad software. Applicable regardless of language and problem domain." From here: The Case for C++ in Embedded Systems. – Nick Alexeev Feb 10 '15 at 3:47