Why does ARM mbed rely on C++? Is C++ the future?

[5upercircuits]

Hey guys,

I recently got into ARM mbed and was quite surprised that they are heavily relying on C++. Up until that point I thought that using C++ for low-level development was not a good idea. Typical arguments supporting this are:

Note: not all of these arguments are my own, googled before I asked the question.
- C++ is slow. (real-time, soft-realtime, etc.)
- C++ produces bloated machine code.
- Objects are large.
- Virtual functions are slow.
- Abstraction leads to inefficiency.

On the other hand, we have ARM one of the industry leaders who decided to create a new low-level OS in C++. I suppose ARM has many experts who know what they are doing, when they decided to go for C++.

Now to my question, did we reach a point where it is advisable for an electrical engineer / embedded software engineer to learn C++? Is C++ the future for embedded?

[ataradov]

ARM mbed is a poorly conceived framework, barely any better than Arduino. ARM sells IP, they don't really care about the software. The more generic it is, the less amount of money they need to spend on engineering resources that are not contributing to a bottom line. The more bloated it gets, the more money they get (hey you need a more powerful core to blink that LED).

C++ can be better than C in embedded if you understand what you are doing. The problem is that it is very easy to slip if you don't constantly check, especially in a team with different level of expertise.

All those things you have listed are bad. Except for machine code size. I worked on a reasonably big project in C and simply using C++, we got a reduction in binary size of a few percent. All with GCC. But C++ templates can be used to a great advantage, and especially in embedded, where you need to get creative at times to get the code size down.

[rounin]

I've actually always used C++ for embedded (AVR8 / STM32 / PIC32 / Automotive PowerPC) (and cluster/hpc stuff). It can blow your foot off if you don't know what you are doing, but it can be much nicer than C with very little extra overhead.

Most of the slow features are optional. My favorite is when old guard C programmers gripe about C++ constructors being slow... not only are they optional but every real C library I have seen has an init function to set the struct members, or a call to memset(0). Not really a difference then....

Things like virtual functions are not much slower than a function call through a pointer offset / indirection, which is usually fast.

Real-time and soft-real time are about provably bounding your execution run time ---- This is a much different statement than saying C++ is slow. C++ is fine, just make sure you are using deterministic features. Eg, no heap. Or only special heaps. Using C doesn't magically make you hard-real time safe.

C++ can generate code that is large in bytes, especially in debug mode, mostly though bloat that templates make. No defense there.

Abstraction can make code that is slightly slower then no abstraction (as in, ~few extra pointer indirection for a virtual function call), but having a set of peripheral drivers written against a base hardware abstraction class is really nice. It makes switching architectures or even to eg linux simple. IMO abstraction isn't really optional. It is just how you do it, and doing it will have a non-zero cost unless you use C macros to hard-compile in your HAL layer.

For a contrived counter example, on a desktop pc with -O3 -march=native turned on, I've seen C++ templated code run 6x faster than C because the compiler had more information to optimize (alignment, etc) with so it used the perfect AVX instruction instead of the more general sse code the C version used.

Template code can eat up all your L1 cache fast though. And all your flash. and take forever to compile. But is is very worth it to never have macros infest a program. It is a balance, depending on what you are doing it might actually help L1 cache usage, if you use the same templated function a lot.

C++11/C++17 added a lot of nice features. Templates + constexpr can make a lot of magic happen at compile time, and are easy for the compiler to verify that they are functionally pure, so tend to inline and optimize well, which would generate nice machine code.

[rounin]

But yeah, please don't dynamic_cast up a hierarchy in a tight loop, looking for the "right" type to pun to. Even on your 48 core 4GHz server. It'll make me cry. (This is when virtual functions get expensive... just call the virtual function! then it is cheap)

[ikrase]

ARM mbed is a poorly conceived framework, barely any better than Arduino.

That's too bad. I had found mbed to be useful when I used it in college.


What framework would you suggest for somebody who finds Arduino to be toylike (but so many easy-to-use libraries!) but has found most other microcontroller programming enviroments to be impenetrable at every step of the process?

[ataradov]

when I used it in college.

Exactly. That's as much use as you gonna get out of it. Good for prototyping/learning. You must be very stupid to base a long term project on it. Or you can start a project, just be prepared to replace modules one by one once you reach the limit of their usefulness. This will not lead to a great architecture in the end, so be prepared for some refactoring as well.

Also, the number of MCUs supported by mbed is very limited. And chip vendors are not rushing to invest resources into something that will make their MCU look like all others and be  easily interchangeable.

What framework would you suggest for somebody who finds Arduino to be toylike (but so many easy-to-use libraries!) but has found most other microcontroller programming enviroments to be impenetrable at every step of the process?

None. Read the datasheet and write the code. It is not that hard, and gets easier as you go.

[rounin]

What framework would you suggest for somebody who finds Arduino to be toylike (but so many easy-to-use libraries!) but has found most other microcontroller programming enviroments to be impenetrable at every step of the process?

What ataradov said. There are so many assumptions baked into a given library implementation. For things like embedded drivers, it is pretty easy for those to not work once you start stressing the design a little, when you want to start using DMA or deferring interrupt handling, or using *all* the modules at the *same* time, with the buffers held on external memory, with a 3rd party RTOS...

And most silicon vendor's drivers and example code are trash. Just useful enough to help you find the part of the manual to read. Maybe they are all written by 1st year interns. I've had awful luck with the PIC32 auto-gen drivers.

[igendel]

Embedded.fm's last episode is very interesting and relevant to the "C++ on Embedded" debate:
https://www.embedded.fm/episodes/137repeat

(my subjective impression is that this debate is mostly over, people realized C++ is fine if you know what you're doing)

[tggzzz]

Real-time and soft-real time are about provably bounding your execution run time ---- This is a much different statement than saying C++ is slow. C++ is fine, just make sure you are using deterministic features. Eg, no heap. Or only special heaps. Using C doesn't magically make you hard-real time safe.

That's true as far as it goes. Unfortunately hardware also screws hard realtime guarantees, especially if there are memory caches and/or interrupts in the system.

The only hard realtime embedded system I know is xC running on xCORE processors; the IDE will guarantee timings by examining the binary code. That's important since any system that is based on measuring execution times relies on the code happening to execute worst cases - and that's bloody difficult to guarantee if caches are in the system

[5upercircuits]

None. Read the datasheet and write the code. It is not that hard, and gets easier as you go.

I would have totally agreed with you a couple years ago. I was also writing all the drivers by myself, accessing hardware registers, reading the datasheet etc. There are two problems with this though:
1. The approach to start with a baremetal system and then code everything yourself is fine if you've got 20 engineers and a big budget $$$. What do you do if you're a freelancer, startup? You can't start with preparing your libraries for 2 years before releasing something that also makes money...
2. While I spend 3 weeks coding a driver, getting it to work and ironing out bugs, the mbed or Arduino kiddy just create a fully functional BLE app with LFS filesystem, Ethernet webserver, etc. in the same time

I agree mbed and Arduino may be trash, but they are also so much more efficient in the short run. Maybe we should not write our own libraries but improve the public libraries like Arduino and mbed?

Note: I have to admit, I'm not a pro software guy, but a pro hardware design guy, so have mercy on me 

[andersm]

- C++ is slow. (real-time, soft-realtime, etc.)
- C++ produces bloated machine code.
- Objects are large.
- Virtual functions are slow.
- Abstraction leads to inefficiency.

The question you should ask is, compared to what? Most larger C codebases tend to reinvent some form of classes with virtual functions, but with the limitations of C the result is always worse. Also, when you've seen the exact same arguments about C++ being to large/slow for microcontrollers repeated for twenty years, while at the same time their performance has increased by orders of magnitude, you know the problem isn't the language.

C++ has a steep learning curve, but you can also use it as a "super-C" with improved type safety, adopting features as you go along. Templatized constexpr functions are the macro language you always dreamed C had.

[Fire Doger]

I agree mbed and Arduino may be trash, but they are also so much more efficient in the short run. Maybe we should not write our own libraries but improve the public libraries like Arduino and mbed?

That would be perfect, but someone has to make them public first and they must be good to attract other experienced software guys. Did you plublished free the libs you wrote?

[Jeroen3]

Now to my question, did we reach a point where it is advisable for an electrical engineer / embedded software engineer to learn C++? Is C++ the future for embedded?

Yes. Embedded projects become more and more complicated that managing everything in C becomes tedious and architectures become more susceptible to simple errors. If you can cherry pick features from C++ to make managing big projects easier, you should.

ARM mbed is a poorly conceived framework, barely any better than Arduino. ARM sells IP, they don't really care about the software. The more generic it is, the less amount of money they need to spend on engineering resources that are not contributing to a bottom line. The more bloated it gets, the more money they get (hey you need a more powerful core to blink that LED).

The purpose of Mbed was not to provide a high performance framework to use in your products. It's a rapid prototyping platform developed to make ARM accessible. It succeeded, and now supports other chip vendors than NXP, an OS and various other stuff. Looking at the objective it was launched for, I say it still succeeded.

The problem is that it is very easy to slip if you don't constantly check, especially in a team with different level of expertise.

The same applies to complicated pointer architectures in C because of features missing from C.

Note: not all of these arguments are my own, googled before I asked the question.
- C++ is slower. (real-time, soft-realtime, etc.)
- C++ produces more bloated machine code.
- Objects are larger.
- Virtual functions are slower.
- Abstraction leads to runtime inefficiency.

- You can simplify pointer syntax, because that what your referring to I think. C++ implicitly adds some dereferencing.
- You can use less LOC to achieve similar results.
- You have real objects!
- You don't have to write code multiple times.
- You save development time.

Imagine only using objects and inheritance of C++. My life becomes so much easier.
Sometimes you don't have to write perfect assembly, but good code that your coworkers can support.

[JPortici]

1. The approach to start with a baremetal system and then code everything yourself is fine if you've got 20 engineers and a big budget $$$. What do you do if you're a freelancer, startup? You can't start with preparing your libraries for 2 years before releasing something that also makes money...
2. While I spend 3 weeks coding a driver, getting it to work and ironing out bugs, the mbed or Arduino kiddy just create a fully functional BLE app with LFS filesystem, Ethernet webserver, etc. in the same time

at the moment i'm the only guy developing hw/sw here.
1. In the same amount of time you can either understand how the peripherals in your system works and write the driver or use the provided driver and when it doesn't work learn how the peripheral work, try to understand what the hell the guy was thinking when he wrote the library and proceed to write a new one because it's all blocking code and/or can't do something and/or it can be used with SPI1 to SPI4 and i'm using SPI5.
2. in the exorbitant amount of 2 days i wrote my first application using sd card with fat32 (also with can and ble) using a new processor family. i used the vendor-provided libraries for SD/Filesystem, in the SD library only i had to replace the peripheral library call with my much simpler functions (as i don't need to reconfigure on the fly, i can substitute entire functions with a single line of code and a comment which explains the bit settings.) and everything was just working.

Then, in the afternoon of the first day i started writing the actual program functions (write string, get string). on Day 2 the first prototype was being tested.

After that, i spent many days on testing and finishing the application, ironing out bugs but the point is that it didn't take much time to prepare a first draft, compared to arduino or mbed or whatever.

[legacy]

Note: not all of these arguments are my own, googled before I asked the question.
- C++ is slow. (real-time, soft-realtime, etc.)
- C++ produces bloated machine code.
- Objects are large.
- Virtual functions are slow.
- Abstraction leads to inefficiency.

this happened several years ago in its childhood, then C++ (and C++11) has grown becoming grown-tool for grown men (at the beginning it was a toy, for students, giving good points for researchers to improve it)

oh, of course, you need to know HOW to use it 

[legacy]

is C++ the future?

nope, the future is C++11 (or C++n*)

[ikrase]

While I definitely don't know much about the more technical side of C++ vs C, I found some of the extremely limited use of some C++ features like the mostly-static use of objects (like are used in Arduino code) to be kind of nice from a writing-the-code perspective.

Serial1.write("stuff\n"); is much preferable to mucking around with structs.



I agree that doing embedded stuff without any insight into your hardware and ability to work with drivers/libraries is a losing proposition. However, I have just found the barriers to entry to be overwhelmingly high compared to what should be -- and is -- possible.

Being tossed a 100+ page datasheet and a header file full of register memnomics to just read values out of an ADC is not my idea of efficiency, and is clearly going to be duplicated effort between every single user.

In my experience just getting toolchains installed and functioning can be amazingly painful. Meanwhile, in the time I was working with it, mbed seemed to be fairly functional as a "Arduino for adults" product.

[tggzzz]

is C++ the future?

nope, the future is C++11 (or C++n*)

Quite

Although I'd probably add ".... and always will be\n".

[SiliconWizard]

I wouldn't touch mbed even with safety gloves. 

That said, C++ has some benefits over C, but it's a monster that some highly-regarded people consider should never have existed (including Linus Torvalds and Niklaus Wirth, who are not exactly dumbasses).

I rarely see any reason to use it in embedded settings, where we often see, when C++ is used, very trivial stuff encapsulated ad nauseam for no good reason whatsoever, except maybe looking hype. Especially on small targets like microcontrollers. And it can also make debugging a lot harder.

Some may object (no pun intended) that GUIs, for instance, are much easier to design with object-oriented languages. There are some nice GUI libraries in C for embedded development though, that are fairly straightforward to use. YMMV.

For bigger targets than small microcontrollers, higher-level languages than C may have some benefits. I would personally tend to favor ADA to C++ in this case. Granted ADA is kind of a huge monster too, but at least it gets object orientation and safety features right IMO.

As to what is the "future", it's kind of hard to predict. Whereas C++ is actually declining in use overall, and Java is starting to as well (after a two-decade raise), C is still going strong for embedded development, so I don't think it's going away anytime soon. And why is mbed using C++, I'm not sure. Some tech decisions in big companies are not as rational as you may think.

[ataradov]

1. The approach to start with a baremetal system and then code everything yourself is fine if you've got 20 engineers and a big budget $$$. What do you do if you're a freelancer, startup? You can't start with preparing your libraries for 2 years before releasing something that also makes money...

You absolutely can and should. Sure on day 1 you will feel behind, but after a few weeks, you will be at the same point, but you will have a code base that you know. Plus the code does not go away, once you write it, it travels from project to project.

2. While I spend 3 weeks coding a driver, getting it to work and ironing out bugs, the mbed or Arduino kiddy just create a fully functional BLE app with LFS filesystem, Ethernet webserver, etc. in the same time

An then they spend the rest of the product life cycle trying to find subtle bugs in a system they don't know how to debug.

You can start with rmbed or Arduino if it feels more comfortable, jut do it with explicit goal to replace things as fast as possible, so don't get comfortable with the whole framework, just pick the "hard" parts here and there, do the easy parts yourself.

[tggzzz]

I wouldn't touch mbed even with safety gloves. 

That said, C++ has some benefits over C, but it's a monster that some highly-regarded people consider should never have existed (including Linus Torvalds and Niklaus Wirth, who are not exactly dumbasses).

I rarely see any reason to use it in embedded settings, where we often see, when C++ is used, very trivial stuff encapsulated ad nauseam for no good reason whatsoever, except maybe looking hype. Especially on small targets like microcontrollers. And it can also make debugging a lot harder.

Some may object (no pun intended) that GUIs, for instance, are much easier to design with object-oriented languages. There are some nice GUI libraries in C for embedded development though, that are fairly straightforward to use. YMMV.

I've seen people waste years on C++ GUIs, when there were alternatives (Smalltalk or Objective C then, add Java now). Those alternatives would have allowed them to skip past the problems inherent in C++ and allowed to concentrate on their problems, not the tools.

There are swamps that need draining, and C++ is an aligator.

For bigger targets than small microcontrollers, higher-level languages than C may have some benefits. I would personally tend to favor ADA to C++ in this case. Granted ADA is kind of a huge monster too, but at least it gets object orientation and safety features right IMO.

Yes, but there are some other alternatives.

As to what is the "future", it's kind of hard to predict. Whereas C++ is actually declining in use overall, and Java is starting to as well (after a two-decade raise), C is still going strong for embedded development, so I don't think it's going away anytime soon. And why is mbed using C++, I'm not sure. Some tech decisions in big companies are not as rational as you may think.

C and C++ will be around for a long time, just as COBOL is. But for new projects COBOL isn't the language of choice - and neither should C++ be.

[rstofer]

You can start with rmbed or Arduino if it feels more comfortable, jut do it with explicit goal to replace things as fast as possible, so don't get comfortable with the whole framework, just pick the "hard" parts here and there, do the easy parts yourself.

My little mbed LPC1768 project was pretty simple:  receive a stream over SPI, mangle the data and send it to a LaserJet printer over TCP/IP.

I had to write the interrupt driven SPI Slave (no big deal) but I didn't have to write the TCP/IP stack.

I had the project done in a couple of days instead of spending weeks and weeks re-inventing the network stack.  In the end, I would have copied something, from somewhere, and hoped for the best.

[ejeffrey]

Note: not all of these arguments are my own, googled before I asked the question.
- C++ is slow. (real-time, soft-realtime, etc.)

This is not really true.  There are some parts of the language that are slow, and in some cases there is a little extra overhead.  But generally when you do the same thing as C, it will be within a few % of the C implementation.  And it isn't really a big deal for "realtime" -- it's not like a garbage collected language where things may pause non-deterministically.  Real time doesn't imply fast, it just requires predicable execution times, and C++ can certainly accomplish that.

- C++ produces bloated machine code.

This is less true than it used to be (compilers have gotten better).  Also it really depends on what you are doing.  C++ is generally more aggressive about inlining than C which can cause machine code bloat but also be good for performance.  Uncautious use of templates can also cause code bloat, but proper use can provide better performance and lower memory footprint than the alternatives.

- Objects are large.
- Virtual functions are slow.

These are sort of at odds.  C++ uses virtual method tables, where each instance has a single vtable pointer to a static array.  Compared to the typical implementation of virtual dispatch in C (multiple method pointers per instance) this is more compact but potentially slightly slower.  Of course you can do virtual method table in C, and that is what you would do if your object had a lot of virtual methods and you wanted to save space.  In that case the performance would be similar or worse than C++.  The same implementation in C++ will usually be faster as it provides more hints to the compiler to allow for optimization.  For instance, changing the vtable pointer of an already initialized object is illegal in C++, but not in C.  So if you are making a virtual method call in a loop, the C++ compiler is more likely to be able to be able to hoist the virtual method address load out of the loop.

- Abstraction leads to inefficiency.

That's always a risk, but C++ lets you choose your level of abstraction when it makes sense.

Exceptions and RTTI are both features that are commonly suggested to be slow and bloated.  Again, compilers have gotten better about this over time, so the early criticisms are maybe overblown.  The point here is to not use them if you don't need them.  On the other hand, if you really do need them, any kludge you come up with in C is probably going to be slower and more bloated than C++.

[NorthGuy]

- C++ is slow. (real-time, soft-realtime, etc.)
- C++ produces bloated machine code.
- Objects are large.
- Virtual functions are slow.
- Abstraction leads to inefficiency.

Is C++ the future for embedded?

Yes. Inefficiency is the future. If you don't like inefficiencies produced by C++, get over it. By the time you make peace with C++, there will be something even less efficient - Linux, Python, whatever. The whole generation of designers (software and hardware alike) grew during the period of tremendous growth in hardware technologies. During this period, a strategy of getting quickly into a newer cutting-edge technology (as opposed to creating solid efficient designs for existing technology) was winning big time. Thus, if you want to be ahead, jump as far as you can. When you consider C++, don't think if it's efficient or not, rather be afraid that it might be already obsolete.

Of course, you may hope that the efficiency era may return, and this might be indeed the case, but I wouldn't count on that being any time soon.

[ejeffrey]

blah blah blah, get off my lawn you damn kids.