C vs C++ for Embedded System Programming?

[tatteredpotato]

I've recently been doing some work with embedded systems programming, and up until now I've tried to limit myself to mostly C features, but when I originally learned programming, I learned OOP, so I find myself spending a lot of time trying to figure out a good way of implementing things in a more procedural/C-style.

The project I'm working on is a simple GPS program (text only... no maps or anything) that runs on an Altera Cyclone II FPGA with a NIOS II processor on board. I guess until this point I assumed using classes was an unacceptable overhead, but is that the case? Should I stick it out with C or just go with what I know best (C++)?

 

[degibson]

You can use C++ in the embedded domain, if you can find a compiler for your target. There isn't any overhead for straight-up classes and OOP... there is some inefficiency in virtual function calls and some more exotic C++ stuff, but "classes" can be (and usually are) implemented as wrappers around procedural code that take hidden struct* arguments.

Now, before the crazies go wild, OOP can hose your performance for a variety of reasons. E.g., cache locality, alignment, function call overhead, etc. It matters more in an embedded domain. But use your head and you'll be fine. Again, assuming you can find a C++ compiler for your target.

One thing I would watch out for: Templates. Templates can lead to code size explosion, which could overflow a smaller embedded target's instruction memory. I'm not familiar with the NIOS II, so I'm not sure if this is a concern or not, but be aware.

 

[Cogman]

OO will almost always result in slightly large code then procedural. However, by larger, I should qualify that it is a slight increase, not a huge one.

If you really, really, need the code to run fast, then C is probably your best bet. Aside from that, a good assembly programmer can beat a compiler.

If your processor can handle C++ code, then I would use it, the maintainability that you gain outweighs anything you would lose in speed.

 

[tatteredpotato]

Thanks for the input. As for questions regarding the availability of a C++ compiler, Altera has a modified version of Eclipse that they call the NIOS II IDE which actually seems to have really good C++ support, so no worries there.

Also, the system I am working on will have 8Mb of SDRAM available, and really the scope of the project is just to read and manipulate some text sent over RS232 from a GPS module, and then output to a 16x2 Character LCD, with some sort of rudimentary menu system.

The point on templates... I'm pretty sure I'd read warnings of that nature before since templates in C++ are (IIRC) implemented at compile time quite simply as a complete copy of the code with the correct datatype inserted for the template type. So if you implement a template with 4 different datatypes you'll have approximately 4 times the code size if you would have used only 1 datatype.

 

[pdusen]

So if you implement a template with 4 different datatypes you'll have approximately 4 times the code size if you would have used only 1 datatype.

This is only true if you actually use the template with the 4 different datatypes somewhere in your code. Template combinations that aren't used are ignored by the compiler.

 

[chronodekar]

Most embedded projects are done with C. Optimization was the original reason, but as time went by, I think the embedded programmers got so stuck up with C, that they don't know what/how to use OOP. (its what I'm seeing at times)

If you have a good profiler or a similar tool for your system, then I'd recommend C++. You should be able to narrow down any bottle-necks that way.

-chronodekar

 

[Modelworks]

I learned embedded programming on the z80 cpu, so I started with ASM then went to C then c++ for newer processors. I think part of the difficulty with people coming from other forms of programming to the embedded world is that they don't really understand what the processor is doing. If you don't understand how the processor you are programming is organized internally then really any language can cause problems. Every embedded cpu has its own quirks, I would never depend on the IDE or compiler to have implemented fixes for them without me knowing what they were first. I have seen many programmers writing code for a chip they have never even read the datasheet for, they just know it is a processor and runs code they write.

I think all three are still required ASM, C, and C++ . For the low end slower clocked and small storage I go with ASM. The 4Mhz + parts C, and for the high end DSP type chips C++.

Try not to rely on a IDE as a crutch for programming the micro. There are a lot of upcoming programmers that rely so heavily on functions built into the IDE that they are lost when it comes to doing something out of that framework. I see it all the time answering questions on embedded forums and mailing list. Someone will ask how to do something and when I tell them the code they will need the usual reply is 'there is no function to do that so how do I get the code to work. ' Embedded programming is one of the most challenging forms of programming, you usually have very limited resources so you have to be creative.

If you study your target processor then you can use whatever you like to program it.

 

[synn_]

I didn't done much into embedded but only thing i have done is few simulators.

 

[Cogman]

I learned embedded programming on the z80 cpu, so I started with ASM then went to C then c++ for newer processors. I think part of the difficulty with people coming from other forms of programming to the embedded world is that they don't really understand what the processor is doing. If you don't understand how the processor you are programming is organized internally then really any language can cause problems. Every embedded cpu has its own quirks, I would never depend on the IDE or compiler to have implemented fixes for them without me knowing what they were first. I have seen many programmers writing code for a chip they have never even read the datasheet for, they just know it is a processor and runs code they write.

I think all three are still required ASM, C, and C++ . For the low end slower clocked and small storage I go with ASM. The 4Mhz + parts C, and for the high end DSP type chips C++.

Try not to rely on a IDE as a crutch for programming the micro. There are a lot of upcoming programmers that rely so heavily on functions built into the IDE that they are lost when it comes to doing something out of that framework. I see it all the time answering questions on embedded forums and mailing list. Someone will ask how to do something and when I tell them the code they will need the usual reply is 'there is no function to do that so how do I get the code to work. ' Embedded programming is one of the most challenging forms of programming, you usually have very limited resources so you have to be creative.

If you study your target processor then you can use whatever you like to program it.

Heck it isn't even that IMO. A lot of new and upcomming programmers just plain suck. In my entire CompE class, and perhaps even the entire CS group, I think I'm the only one that has ever actually read the MSDN.

Heck, we are doing verilog programming right now, and my goodness, it is amazing how many of the students have no freaking clue. They are too helpless to go out and google "verilog tutorial". And thus have problems understanding simple concepts like an If statement or a case statement.

I laughed in all their faces when they mocked me for saying "I really hate doing the wiring for circuits." Or, "I really dislike doing these giant truth tables." and their responses were something like "yo, Truth tables so awesome!!! I want to do truth tables for the rest of my career!"

Yeah, you guys go do truth tables 'till the end of time. I'll go get some actual work done.

<- bitter nearly finished CompE undergrad.

 

[degibson]

<- bitter nearly finished CompE undergrad.

Hang in there, Cogman. You'll eventually find a place where the largely incompetent people have been mostly sorted out, leaving only moderately incompetent people in their place.

 

[Markbnj]

Hang in there, Cogman. You'll eventually find a place where the largely incompetent people have been mostly sorted out, leaving only moderately incompetent people in their place.

lol.

 

[Cogman]

Hang in there, Cogman. You'll eventually find a place where the largely incompetent people have been mostly sorted out, leaving only moderately incompetent people in their place.

, And I really don't mean to sound conceited. Most of the people around on this board, I respect. Heck, far too often I find places like this as a wealth of knowledge. There is just a lot of info out there, and I know that I really only have a somewhat basic knowledge of it.

But dang, a fair amount of guys at my school are completely worthless.

 

[presidentender]

, And I really don't mean to sound conceited. Most of the people around on this board, I respect. Heck, far too often I find places like this as a wealth of knowledge. There is just a lot of info out there, and I know that I really only have a somewhat basic knowledge of it.

But dang, a far amount of guys at my school are completely worthless.

A fair amount of guys at every school are completely worthless, which is why those of us who are marginally worthy are still employable.

 

[degibson]

A fair amount of guys at every school are completely worthless, which is why those of us who are marginally worthy are still employable.

Very much the truth.

 

[Markbnj]

I've been in the business professionally since 1990, and started programming in 1975. In that time I can count the number of really good developers I have worked with on both hands and have some fingers left over. I think it's that way in almost any business: you have those who love what they are doing and excel at it; and you have those for whom it's just a day job. I believe programming, by its nature, stretches the gap between those two poles such that the really good developers are much more productive than the average developers.

 

[Modelworks]

Hang in there, Cogman. You'll eventually find a place where the largely incompetent people have been mostly sorted out, leaving only moderately incompetent people in their place.

The way it usually works is the incompetent people end up in upper management telling the talented people below them how they should be doing things

 

[robmurphy]

The Dilbert principle "incompetent employees are intentionally promoted to prevent them from doing harm"

Rob

 

[bobsmith1492]

Also, the system I am working on will have 8Mb of SDRAM available, and really the scope of the project is just to read and manipulate some text sent over RS232 from a GPS module, and then output to a 16x2 Character LCD, with some sort of rudimentary menu system.

That's very powerful for an embedded processor. You should have no problem using C++ (particularly since you said your compiler supports it.)

I'd still vote for C simply because it forces a lower-level understanding of what the code and processor are actually doing (and it's what I've always used, naturally). Embedded system programming is all about starting from the ground up. The best way to understand a system is to design the hardware, set up the software with no frills involved (configure the registers and I/O pins, write the peripheral drivers, etc), and finish with the application on top.

However, that's typically for smaller processors (say 2-100KB of RAM, 2-50MHz, 16-256KB flash). On the device you're talking about, you can probably find libraries with drivers so you don't have to worry about any low-level code. So, speed is not a concern and C++ becomes very viable. However, if you run into problems, you will have no recourse as you are relying on code you do not understand in the drivers.