Why C++ is a viable alternative to C in embedded systems design

11/20/2008 3:34 AM EST

I have years experience on both C and C++. But most of our embedded software are done in C only. Why? because C is simple and straightforward. It's hard to say which one is better, C or C++, but I always believe one principle: Do things simple, and do it well.

By the way, I don't think polymorphism is always good. It's very easy to be over engineering if used inappropriately.

11/21/2008 2:25 AM EST

The author writes:
"Anecdotal newsgroup discussions report space and performance efficiency losses of between 8 percent and 30 percent for C++ implementations. Of course, for the exact same code using the same C library, we expect identical binary code."
Below is a real-life example of a huge C++ inefficiency.
One time I used perfectly written (I checked the sourse code) library C++ class to set 0/1 at I/O pins of Coldfire 5270 microcontroller. The used function has single drawback: 19 us to set either 1 or 0 - with 147 MHz of the core frequency.
I created specialized C inline function, which only write to the needed registers. This implementation took only 0.5 us to change state of the pin.

11/21/2008 8:17 AM EST

Malcolm Gladwell, author of Tipping Point and Outliers, was on the nightly news last night saying that it takes about 10 years to become truly expert at anything. Why would developers with over 10 years experience in C want to start over with C++ instead? I just don't see the advantage.

11/21/2008 2:55 PM EST

Next time, please address debugging tools for embedded C++ -- and I'm not talking high level
"analyzers", but low level source debugging.
In my 30 years of experience, the half dozen embedded C++ projects I saw were a nightmare to work on, and in 2 cases I saw it bring down the company.

11/22/2008 12:49 AM EST

The article is consistent with my experience. I see very little difference in code size and performance using C++. If you understand what C++ is doing for any given line of code, it is very easy to determine the implications on code size or performance.

It is probably worth noting that unless you go about architecting your application from an OO perspective, you'll get very little use from switching to C++. If you are already comfortable with design patterns and OO languages like Java or C#, it isn't a stretch to consider catching most of the benefits of those languages by using the only OO language available to when working on bare metal.

Comparing a specialized C inline function to a library written in C++ doesn't demonstrate C++ inefficiency. That same C function written as an inline member function would have produced the same result as the C function. I would expect that an optimized inline C function is generally faster than a C library function that does the same thing, like writing to a UART tx register instead of calling putc().

I don't see how the use of C++ could ever be the sole factor in bringing down a company.

IAR, Green Hills, and even gcc/gdb all provide suitable debugging alternatives when you need to get close to hardware and see what your C/C++ is doing.

11/25/2008 2:28 PM EST

Fergus,
Although I can see that the real of SW development can be hidden behind C++. I have heard all of the exceptions you'd voiced as well. I also was responsible for writing/porting the C++ runtime library to an RTOS. This library was recoded by several talented engineers with the intent to minimize and optimize the library. For those who are unaware, this runtime library is Critical for C++. I does all of the nasty work that is hidden behind C++. I digress, this library, after diligent efforts to make it as small as possible, was 2x the memory footprint of the RTOS itself. It took ~4x the time to handle exceptions. It was a major effort to install interrupt handlers which 'conformed' to the C++ style. The abstraction made the debugging effort a great deal more difficult. This is mostly due to the tedium of stepping through unfamiliar code. Code written by an unknown and unobtainable resource.

So, yes. If you have lots of headroom and plenty of memory then C++ can be used to make the development effort Seem simpler. There are also a larger number of students who know C++. Most of these haven't ever been faced with challenges that are unique to hard realtime and embedded systems.

Cheers!

11/27/2008 7:11 AM EST

I guess any poorly designed solution, using C or C++, can have detrimental effects to companies and their clients.

We have been making embedded control systems for years using C++ and our own development framework, CDP - Control Design Platform, and have been successful in doing so. Using a standardized framework, has ensured that all the projects have a common base and has also made it easier to debug and troubleshoot. We've even managed to deliver quadruple-redundant solutions running on different OSes, e.g. Linux and RTOS32. For more information about our framework, check it out here: http://www.icd.no/

11/28/2008 3:08 AM EST

We have used C (and the odd bit of assembler) for embedded systems for over 10 years now. Although our toolset now allows us to choose C or C++ we naturally do things the way we already know.
There are efficiencies to this.
However this was an interesting article and I can see some benefits to embedded C++ provided the tradeoffs are properly considered. This has encouraged me to look into it a bit more closely. Amongst other things, it makes the adding of a version to each module easier as they can all be called version. This is something you can't do as easily with C.
Thanks,
Ray Keefe

12/30/2008 8:30 AM EST

God Bless those who know C++ well enough to create compact beautiful code quickly, it is extremely rare. It has been my professional experience the use of C++ in any embedded project invites programmers with no embedded experience to contribute. HR and managerial types see C++ on a resume, and you have a programmer on your team who is used to dual core 3 GHz platforms which hides bad programming very very well. I remember a young fella fresh out of school (a recent addition to our team), was curious about the language I was programming in, I said 80186 assembly. He sad flatly, with confidence, "Dude, you really need to update your software." C# of course!

The article kinda says this: C will always work, whereas C++, used correctly, for the right application, and with attention to detail, is a great option.

I agree with Marco, simple is always better. I have a lot of experience, and I am going back to the past in my designs. CPUs with no memory protection, make everything global, severely limit indirection. The smaller the code, the less can go wrong. A lot of systems programmed this way decades ago, are still running today (trains, planes, nuke plants).

12/31/2008 1:47 AM EST

My company makes and sells Communication Protocol Source Code Libraries in three languages - C, C++ and C# (http://www.sunlux-india.com/ProtocolLibraries.htm). These are intended to be used in industrial embedded devices like Energy meters etc. For every 50 licenses of the 'C' library, we sell 1 of C++ and maybe around 10 of C#. This is in spite of the fact that our C++ and C# libraries are more versatile in functionality. We found the reason to be that the 'C' libraries are "simple", very "light weight" and easy to modify. This echoes the comments above that simplicity and reliability are factors considered more important in embedded systems.

1/21/2009 6:33 PM EST

I´he made software profissionaly over the last 15 years (as a design house "handson" director), and "boy"fissionaly for the first 6 years (6+15=21).In the beginning I consiedre my self the king (but still a boy)of assembly language, one I knew the language and its tricks very well, besides have lot of proprietary libs.
One day a not "king" friend of mine (TI boy)introduced me C, and 3 months later I felt as a fired King and now I was an "office boy" in the C world (even less then my "navy" friend).Beside this new condition I became a faster designer with more quality than before.So 8 years later (too late...), and "hundreads" of design, I got reasonamble experience in C, I started to fight with my framework, my team speed and profitability.
Today I fell my self as that time of assembly to C, but now I´m considering 3 points to solve: 1-framework 2-UML 3-C++
The UML use, specially state diagram , when used by "practical" guys, can accomplish a very powerfull job.It goes beyond the code!!!
After read 2,000 pages of books and articles and others cases I decided to bet on this architecture.
To me its clear that this can make the things "much" more clean, although the things say "hey: I´m already clear!".
In our case we use basically ColdFires mcus and our applications is not time critical applications, although we have some foot print restrictions.
I undesratood that OO perspective is the "current ball" for the increasing of complexity on embedded designs.But I confess I got scared with the mention of 19us to 0,5us comparsion from YevgeniT !!!
I really appreciate this discussuions..thanks guys..

2/24/2011 8:32 PM EST

I think we are heading for an age where distributed architectures will prevail strongly even within the micro-controller environments.
Imagine creating a robot with sufficient enough AI in its "brain", such that minimal high level signals may be sent to say the hand to make a fist. The hand will most likely require its own micro - or set of to perform complex hand movements.
As desktops and servers reached a point in performance and needed to go multi-processor and multi-core, so to will the environment of micros.
This will be especially true in the above scenario where the micro will be required to do very heavy computing.
Such heavy computing will (if multi-core mircro exist) be done in C++ using a multi-threaded framework. C++ will provide excellent abstraction of the had object in this case with each finger as an instance of a finger object ...
The multi-threaded framework will allow us to use all the cores very effeciently providing a high degree of scalability with high performance.
In addition, multi-threading if done correctly with a good framework can really simplify code via a higher level of abstarction (we start this process and let it run ...).
Doing multi-threaded development in a non o-o language is a nightmare.
I'll challenge any C programmer at a task that needs to be solved for a backend server process, where the use of multi-threading will most likely be highly beneficial. To make things worse - we can test on a 2-core, 4-core & 8-core. In each case the gap of performance will increase. Then imagine what will happen when run on a 64-core.