Is C++ really suitable for embedded systems?

[DeclaredButNotUsed]

After spending almost half a year structuring and building a project in C++ with lots of generic libraries (no hardware related) I had to took on a new project that its requirements led me to use a PIC18F.

Soon, I found out that I could literally use nothing out of the box. I couldn't compile anything that was in C++ and the most important stuff was in C++.

I know that it's just a single example but it was a nightmare having to re-write almost everything. I had to extract my classes' methods, put them in h/c files and create new modules. Fortunately my cmake build system did help me a lot for that. But I ended up with a bunch of code duplication. Yes I know I can use those c implemented modules inside my classes now for my other projects but that requires testing again. It's not that simple.

Some people would ask, why did you choose such an old chip. Global semiconductor shortage forced me to do so. Also, there are occasions when a Cortex-M3 with tons of RAM isn't a good fit.

The project took a month more due to the extra work that had to be done.

This made me to reconsider.
Is C++ really suitable for embedded systems?

Why should I use C++ if I can't compile a hardware independent piece of code for every silicon out there

What would you do in that case?

 

[betwixt]

I would never use C++ for a coding an MCU. As you found out, it carries too much baggage. Plain old 'C' is however very good. I think from the outset, C was designed to be compatible at machine level while C++ was designed to be easier at a human level.

Brian.

 

[Aussie Susan]

It is 'horses for courses'. Some of the larger MCUs (especially those based on ARM and MIPS devices) can use C++ or C# or whatever compiler you can find that does the job.
However the smaller MCUs tend to also have small RAM and FLASH sizes (and some even have hardware-limited stacks) which makes the use of object-oriented implementations difficult, if not impossible.
When you use these smaller MCUs then you normally need to tailor your code to the specific task at hand. Even the use of libraries, which people think will let them transfer their code from one MCU to another, even in the same family of devices, can be problematic due to the different module implementations of the same basic operation (e.g. SPI might sometimes be mixed with I2C in the module for one device but be separate module sin another with different registers and possible even different bits within registers.
Don't forget that these smaller devices typically are used for very low-level tasks and not for number-crunching or other non-hardware-specific tasks.
Susan

 

[andre_luis]

For baremetal programming up to 16bits cores, in most cases C is what confortably fits the microcontroler core resources. For 32 bits microprocessors with external memory, let's agree it is not intended for ordinary tasks, and the OOP approach could be considered. By the way, the term embedded systems can embrace a vast number of cores with varied architectures.

 

[FvM]

As far as I'm aware of, only IAR C/C++ compiler for PIC18 supports classes and other C++ constructs. I have no experience with this tool and don't know if it can generate slim code from C++ sources, hopefully it does. Nevertheless embedded programming for small CPUs must be resource aware which probably involves avoiding of certain C++ elements.

 

[KlausST]

Hi,

If I'm not mistaken then Arduino uses C++

Klaus

 

[Aussie Susan]

If I'm not mistaken then Arduino uses C++

I could be cynical and say 'I rest my case'!!!

In my experience you can quickly run out of FLASH and RAM in the Arduino framework because of the overheads C++ incurs, even when trying to move beyond the fairly simple apps. Also if you are using the Due then you have some power, but the Uno and even the Mega are really good for straight forward applications (where they certainly have their place).
Susan

 

[DeclaredButNotUsed]

There are many C++ advocates out there. You can also find many videos on YouTube too.

I do not support the extensive or the committed use of C++ in embedded software but it really gave me some boost during a very low power application. I used templates where I was struggling with many preprocessor macros in C.

The final binary was bigger by less than 100 bytes which in a flash of 256KB is negligible.

However as I mentioned in my first post most of the elegant libraries I wrote cannot be used in smaller MCUs. I'm used to break complicated libraries and tasks into smaller so I can use only the pieces I want in future projects. Cmake does a wonderful job in that. Then was when the nightmare started when CMake tells you that this folder over there is written in C++ and cannot fetch it in compilation. Bad news but wait... I had a C implementation of this module. Then you end up searching your main commit history.

My initial intention to open this thread is to read some advice from more experienced engineers about how to handle situations like this one.

I also saw Arduino in the comments. In my opinion Arduino became popular thanks to his OOP he offers to its users. I also have seen it extensively in the industrial environment. I remember I was talking to an embedded software team who did IoT project on industrial machinery and told me that the whole project was built on mostly what Arduino offers. Even they used Arduino IDE.

Anyway I'm about to start an automotive IoT project with cellular module, a GPS module and a Cortex-M4 for telemetry purposes. I've done it in C in the past and I was thinking to go with C++ with this one. But now I'm seriously re-considering to use C again.

 

[podericof]

After spending almost half a year structuring and building a project in C++ with lots of generic librCaries (no hardware related) I had to took on a new project that its requirements led me to use a PIC18F.

Soon, I found out that I could literally use nothing out of the box. I couldn't compile anything that was in C++ and the most important stuff was in C++.

I know that it's just a single example but it was a nightmare having to re-write almost everything. I had to extract my classes' methods, put them in h/c files and create new modules. Fortunately my cmake build system did help me a lot for that. But I ended up with a bunch of code duplication. Yes I know I can use those c implemented modules inside my classes now for my other projects but that requires testing again. It's not that simple.

Some people would ask, why did you choose such an old chip. Global semiconductor shortage forced me to do so. Also, there are occasions when a Cortex-M3 with tons of RAM isn't a good fit.

The project took a month more due to the extra work that had to be done.

This made me to reconsider.
Is C++ really suitable for embedded systems?

Why should I use C++ if I can't compile a hardware independent piece of code for every silicon out there

What would you do in that case?

when you select the microcontroller, in some way you also select the language that you will use.
C++ is very powerful but you will waste a lot more memory than C. So, for example, if you use a PIC microcontroller, you will probably do better using C. On the other side, there are now MCU with RAM and ROM with the magnitude of MBytes now... for example ESP32, or the Cypress PSoC 6.
Said that, (with the exception of the ESP32) most of my programs
for MCU I made in C language.

Good luck!

 

[doraemon]

Hello!

Many people talk about "a lot of overhead" without specifying what is "a lot".
I have used C++ on rather "small" microcontrollers (MSP430), and it works just fine.
Let's put numbers on what I call "small", I mean: 8k RAM and 32 k flash (for example
MSP430F5510).

I have still to see a real example written in both C and C++ version, with the same compiler.
I made experiments in the past using MSP430, IAR compiler, but for speed, not for size.
I found out that there is no speed difference as long as you do the same thing.
If you call a function vs call an object's method, you have a difference of 1 clock
(when using MSP430 + IAR). The reason is that in C case, you call the function directly, and in
C++ case, you call a method, which is a function that belongs to an object. I would not be
surprised that in C, if you call a function that belongs to a structure like this : S->F(), then
you get the same speed as when you call an object's method.

Now about Arduino: I made a quick test recently because some people said that
digital_write is slow. So I tried on a arduino mega, with atmel 2560. And indeed, doing
digital_write vs direct port access is extremely slow, you can divide the speed by at least
10. But if you don't use Arduino's specific functions, then it's as fast as C.

Well, sorry for the digression, I would like to see a simple program, for instance a thermometer,
in 2 versions, one in C and one in C++. Then compare the code size.

Now in case "size matters": this is more guts feeling, but my impression is that C++ allows
you to do some "source code factorization". What is done in the base class doesn't have
to be redefined. Very useful for graphics (even for small microcontrollers as above). And at
the end of the day, I wouldn't be surprised that you can save on code size, and beside this
I have never been short of flash or RAM by using C++.

Dora.