15
\$\begingroup\$

I didn't like this question since it can't be easily answered but perhaps I can rephrase: "What keeps Embedded from changing languages?"

For instance, we pretty much see C/C++ for embedded (I think i've heard ADA mentioned before too? correct me if Im wrong)

But what exactly keeps the Embedded world from changing languages? Is it just that C is too easy to use or there just isn't really a "need" for a change since C does everything fine?

This has always kinda baffled me, not that im complaining. Since keeping it to a few languages keeps things standardized. But still the question remains.

I realize this is sort of a Subjective question, however My main Question is "Why" and not "IF/WHEN"

\$\endgroup\$
15
  • 2
    \$\begingroup\$ Is there a particular higher level language that you would like to see on embedded systems? EDIT: or rather, what language features are you interested in that C does not provide? \$\endgroup\$
    – Jon L
    Commented Jul 4, 2012 at 21:15
  • 1
    \$\begingroup\$ @JonL - There are a bunch of low-level features I wish C had. E.G. better bit/nibble/byte/word manipulation inside large ints. Better safety support, E.G. the types of features Ada has. \$\endgroup\$
    – Rocketmagnet
    Commented Jul 4, 2012 at 21:37
  • 3
    \$\begingroup\$ Embedded isn't strictly C. Here are a bunch of high level languages for embedded systems: electronics.stackexchange.com/questions/3423/… \$\endgroup\$
    – Kellenjb
    Commented Jul 5, 2012 at 3:27
  • 1
    \$\begingroup\$ "Embedded" has different meanings. A 4-bit microcontroller running a toaster is different to an ECU or Set Top Box. This spectrum makes your question hard to answer. \$\endgroup\$
    – Toby Jaffey
    Commented Jul 5, 2012 at 9:20
  • 1
    \$\begingroup\$ And, as expected, this has been closed. This question I had hope would receive high quality answers and people would work to keep it as a great question, this is not the case. Instead we are getting many answers that are one sentence that receive multiple upvotes, we have an answer that is prose that has a downvote war on it with flags galore, and the other answers generated more flags in 1 day then the rest of the site combined. The issue is that for many people there are many different right answers as to why they have not changed. \$\endgroup\$
    – Kortuk
    Commented Jul 5, 2012 at 15:40

11 Answers 11

Reset to default
18
\$\begingroup\$

First of all: forget about "embedded" as that is not a useful distinction. The all-important property is "resource-constrained". The most important resource is often time, in which case we talk about real-time systems, but it can also be memory or power.

  • New language adoption is hard and rare. It requires re-training, new tools, and finding a good way to work with the new language. This is costly, especially for the early adopters. It is also a chicken-and-egg problem: without a large user base there won't be good quality tools and libararies, but without those there won't be a large user base. Hence a new language must have a big advantage over the existing ones, otherwise it won't stand a chance.

  • Most "recent" new developments in languages have been filling the gap between the available CPU power and what the user needs. In other words: they can be inefficient in speed, but compensate by being easier on the programmer. Think of the rise of languages like Java, Python, Perl, Tcl that are essentially run by an interpreter (maybe after some compilation) and make heavy use of dynamic memory management. But this does not match well with the resource-constrained world, where we want to get a) the most out of the available resources, even at the expense of more programming effort, and b) a predictable use of resources.

  • C and C++ (or a suitable subset) are still the highest level languages that are in common use (enough that good tools, sufficient trained programmers, and extensive libraries are all available) that can meet predictable space and time requirements that are not to far from what is possible on current hardware. The only contender is I think Ada, but it has suffered from a bad start: the first implementations were (perceived to be?) too slow and inefficient, and now (even though good implementations are available) the language has fallen a bit behind in features (compared to C++). Personally I think this is a pity, other things being equal I'd rather fly in a plane that is programmed in Ada than one that has been done in C or C++.

\$\endgroup\$
7
  • \$\begingroup\$ +1 - nice answer. Ada seems an interesting language, are there any Ada compilers for small micros around? \$\endgroup\$
    – Oli Glaser
    Commented Jul 5, 2012 at 3:19
  • \$\begingroup\$ There is GNAT, the GCC Ada compiler. But AFAIK it has not been used much on micros, so you will have a hard time finding something that is read-to-run. \$\endgroup\$
    – Wouter van Ooijen
    Commented Jul 5, 2012 at 8:02
  • \$\begingroup\$ Yeh I saw GNAT mentioned on the Wiki page. You're right, not much around for small micros, but there seems to be a fair bit of support (as you'd expect) for mission critical stuff on 68k, x86, MIPS, etc (e.g. DDCI) \$\endgroup\$
    – Oli Glaser
    Commented Jul 5, 2012 at 21:44
  • \$\begingroup\$ I see there is SPARK Ada too, as mentioned by Deek below. I'll have to check it out when I have some of that elusive stuff they call time... \$\endgroup\$
    – Oli Glaser
    Commented Jul 5, 2012 at 22:22
  • 2
    \$\begingroup\$ Ada, in the form of Gnat, works just fine on the AVR microprocessor, as seen in Arduino. The smallest Gnat executable I have built was 65 bytes. Admittedly all it did was blink an LED, though the equivalent Arduino sketch was over 1K. By the time my executable reached 600 bytes it was driving 2 stepper motors independently... You don't need SPARK - unless you want to prove your LED blinker is formally correct! \$\endgroup\$
    – user16324
    Commented Dec 14, 2012 at 10:21
9
\$\begingroup\$

With 8 and 16-bit microcontrollers based embedded systems, it comes down to it is easier to develop software that can fit into the limited resources of these very modest storage limitations (maybe a few 100 bytes of RAM for low-end 8-bit microcontrollers, with 2-8 KiB of ROM or EPROM/Flash for code storage).

In those cases small languages like C or assembly tend to be the most commonly used development languages. As a very rough relative comparison, a complete assembler and C99 compiler can fit onto a single floppy disk, while you need several MiB for a modern C++ development system (with STL, etc.).

When you are looking at higher end micros (high-end 16-bit, and mostly 32-bit, with fairly rare 64-bit) and DSP in embedded environments then the restrictions weaken, and software development may make up the bulk of the development effort, so it makes sense to use the most productive development tools, including more advanced languages with features like Object-Oriented Programming (OOP) languages such as C++, and newer languages (Java, Perl, Ruby, Python).

It is possible in assembly and C to predict how much memory is being used, so that a space constrainted design is feasible, but advanced features such as templates, exception handling, and run-time binding make it impossible to exactly know the necessary memory footprint for a standard C++ program in advance. I don't know enough about MISRA C++, which is a subset of C++, to comment on it.

Languages based upon virtual machines running byte-code (Java, Perl, Python) are less mature in the embedded developer's experience, and as these languages are designed to insulate the programmer from the particular hardware, it also makes it more difficult to be conscience of such embedded hardware system's limitations and restrictions. These is less of an issue with fast 32-bit processors (e.g. ARMv7) with MiB if not GiB of RAM.

All the BASIC implementations that I'm aware of are quite simplistic in the language features, remaining largely true to the legacy of Dartmouth BASIC from the 1960s. This means that the language doesn't have any complex run-time libraries or exception handling, and an interpreter or compiler is fairly simple to write and is small in file size as well. Most microcontrollers have at least one BASIC compiler available for it.

I hope that outlines in broad strokes the reasons you'll find C and assembly primarily used on smaller or older embedded systems, and with the limitations of newer mid to high-end embedded systems differ only slightly from a traditional desktop personal computer.

\$\endgroup\$
5
\$\begingroup\$

In the embedded world, it can be a lot harder (or impossible) to provide software updates, and so it is all the more critical to guarantee correctness. Sadly C provides very little help in this regard, and allows the programmer to play fast and loose.

It pains me to use C for embedded systems, and wish I could at least move up to C++ for the many benefits it provides in the form of constraints like const, references, stringer typing, etc.

I guess the answer is simply that we're stuck with C because changing is not commercially viable. Everybody knows C, there are loads of compilers for it, libraries for it and tools to generate it. With a new language, we'd be starting from scratch.

I guess that's why people still use PHP.

PHP double claw hammer.

\$\endgroup\$
7
  • \$\begingroup\$ If you want to discuss the question use comments or meta, if you want to pat the user on the back for a good question upvote it or comment. \$\endgroup\$
    – Kortuk
    Commented Jul 5, 2012 at 1:24
  • \$\begingroup\$ You can always use Pascal - it seems to have the added limitations that you are seeking :-). Or some form of Super-Lint. \$\endgroup\$
    – Russell McMahon ♦
    Commented Jul 5, 2012 at 2:02
  • 2
    \$\begingroup\$ One likely very significant reason for C is that it's WAY easier to write a basic C compiler than a C++ compiler. I worked on one for a while before more important tasks pulled me away. Fun stuff! Writing a C++ compiler? Ugh. I prefer C++ as a user, though. \$\endgroup\$
    – darron
    Commented Jul 5, 2012 at 2:29
  • 1
    \$\begingroup\$ @RussellMcMahon - I can't use Pascal, because there's no Pascal compiler for the MCUs I'm using. \$\endgroup\$
    – Rocketmagnet
    Commented Jul 5, 2012 at 8:26
  • \$\begingroup\$ @darron - That's a very good point. However, there are very good open source C++ compilers, like gpp. They would just need to write a back end for it. \$\endgroup\$
    – Rocketmagnet
    Commented Jul 5, 2012 at 8:27
5
\$\begingroup\$

Has no one here heard of SPARK Ada ?

This is a "small" version of Ada language and related development tools for embedded systems, e.g. avionics and other safety-critical applications like medical equipment.

Studies have show just a 5-10% loss in processing speed compared to C/C++ with the more reliable SPARK coding.

I think that the proliferation of C in embedded systems is due to economic reasons :

  • It's already there and usually workable for most applications - and most applications on a volume basis are non-critical, no one will die if the washing machine overruns - so why change ?

  • The SPARK toolset is going to be an additional expense in itself and for training staff to use it.

  • The added benefits of SPARK (or other non-C languages) to the embedded controller/management system may not be enough to justify the necessary premium in the product's price in the consumer's eyes -- especially when they see apparently "good" rival brands selling for a lower price.

  • The AdaCore company is careful not to go too deep into the mass market applications as these will inevitably demand a big increase in technical support staff to deal with non-core issues. AdaCore is a high-level expertise company, prides itself as such and pitches its products and services at high technology companies. It's unusual for a language to penetrate new markets unless its main stakeholders really want to.

So, @ Wouter, you need not worry about dying in the skies for want of Ada embedded code !

It's already in the airplane systems for many years. Likewise for your pacemaker.

But for the dishwasher, the building services control system, the lab furnace controller and other not so strictly regulated arenas -- is it economically worth going the extra mile ?

\$\endgroup\$
2
  • \$\begingroup\$ Interesting, thanks - I'd not heard of SPARK, will check it out. \$\endgroup\$
    – Oli Glaser
    Commented Jul 5, 2012 at 22:00
  • 1
    \$\begingroup\$ Some studies show a speed-up relative to an existing application in C - look at the "Ironsides" DNS server... \$\endgroup\$
    – user16324
    Commented Dec 14, 2012 at 10:16
5
\$\begingroup\$

Most of the answers already stated the historical reasons (well known, everyone uses it, would not be easy to change the habits, etc). While I agree with them, we should keep in mind that there is another important reason.

It's not that "C is a bad or outdated choice but we still use it out of habit" (like the QWERTY keyboards).

C is on itself a very good choice for embedded development, especially in time-critical applications. Why?

  • it is low level enough to be easily used to implement real-time programs. If you need to measure time in the nanoseconds, have to catch an interrupt every 5 microseconds, or have to use exactly 64 bytes of total RAM, then with a very high level language it would most often be either impossible or very hard to solve it. C gives you much better control over the hardware than higher level languages, this is one of the most important differences between developing for embedded vs. PC.

  • it is high level enough to be fast and easy to code, compared to Assembly.

So, C is the best (or one of the best) compromise between the speed and direct hardware access of Assembly, and the easy reading and understanding of high level languages.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I think a major aspect in C's favor is that it allows one to optimize code for a particular platform while allowing such code to run (perhaps not as efficiently) on others. On something like a PIC, many C instructions will translate predictably into machine instructions; a loop like unsigned char i=63,j=128; do {something;} while(--j); while(--i); will not be as readable as unsigned int i=16000; do {something;} while(--i);, but it will run faster and be more efficient on the PIC. If the code were moved to the ARM, the second approach would be more efficient, but the first would still work. \$\endgroup\$
    – supercat
    Commented Jul 5, 2012 at 14:50
4
\$\begingroup\$

It's exactly the same reason why in regular programming the (most used) languages don't (really) change:

  1. Huge amount of existing code (libraries/existing implementations)
  2. Big tool set which can work with these languages (IDEs, simulators, ...)
\$\endgroup\$
3
\$\begingroup\$

I guess that the main reason for C's popularity is that first: C is popular and many people know it and second: None of the new popular languages like Java, C# and even many aspects of C++ are suitable for embedded work. Basically the 3 other languages I mentioned rely a lot on dynamic memory, which brings non-deterministic execution of program with it, objects, which bring dynamic memory with them, large memory requirements (since one of the more important sides of OO is usage of larger number of classes), the increasing popularity of just in time compiling (and many embedded platforms can't even compile their own C code at all)...

There's also the fact that many of the libraries which ship with say Java or C# are useless for large number of embedded projects.

On the other hand, we have older languages like Pascal or Basic. From my point of view, they aren't as popular because C made itself the "industry standard" language and very large number of programmers and engineers learn C today. In some schools Pascal or Basic aren't even learned. There's also the fact that many languages today popular have C-like syntax and using Pascal would feel strange to a C programmer.

As for FORTRAN, well I guess that it went into a niche field and is mostly used by engineers and scientists working in areas where there is a suitable ecosystem for its use. I don't see any particular reason (other than those I mentioned for Pascal and Basic) it isn't used on embedded systems.

Do note that in this answer I focused mostly on smaller systems. There are also many embedded devices which use more complex operating systems such as GNU/Linux or some other Unix derivative and for programming them, more or less any popualr language can be used.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ C is popular because C is popular? :-) \$\endgroup\$
    – stevenvh
    Commented Jul 5, 2012 at 15:33
  • 2
    \$\begingroup\$ @stevenvh Yes, that's true. It's a sort of positive feedback loop. The more popular it is, the more popular it gets. \$\endgroup\$
    – AndrejaKo
    Commented Jul 5, 2012 at 15:34
3
\$\begingroup\$

C is a very simple language, and has been on more than one occasion referred to as fancy assembly language. It is very nearly the minimum amount of abstraction you can provide above assembly code, as the C constructs map fairly directly onto machine-level constructs.

For this and several other reasons, it is very easy to implement a C compiler on a new chip. Much of the work is already done, there's comparatively little complexity or things to go wrong, and the low-level control allows you to fairly easily handle whatever quirks your hardware has.

C++ can be (actually originally was) implemented as a source-code translation layer on top of C, meaning you get C++ (or at least some version of it) for free with your C compiler.

With C and C++, you an bootstrap pretty much everything else you need for your new chip, making it the logical place to start.

\$\endgroup\$
3
\$\begingroup\$

Some reasons the others haven't mentioned:

  • Problem space: C is suitable for small and simple systems. If all you do is react to external signals and push a few numbers around then C works rather well (no complex data structures, no malloc, no complex error handling).

  • Production volume: If you have large production runs then it is economically sensible to save on each hardware unit and spend more on programmers, because programming is a one-time cost.

\$\endgroup\$
2
\$\begingroup\$

I think that is because C/C++ are the lowest level, high level languages.

\$\endgroup\$
1
\$\begingroup\$

In fact, for small embedded systems C is much more popular than C++. And the reason for that is the same as for not using other languages. C++ requires a runtime, unless you give away most of the features that make it different from C.

Apart from assembly, C is the only language I know that compiles to native code and for which having a runtime is optional. So it is guaranteed to be the smallest footprint and fastest execution time in a restricted environment (except if you use assembly).

On the other hand, in medium and large embedded systems (by which I mean more memory and clock, bigger word size) I wouldn't say C (or C++) is so prevalent. I've seen systems supporting Python, Forth... even Java.

But of course you almost always have the option of using C/C++, obviously, for the same reasons I mentioned above. And having the option, and being you someone that already is comfortable with C for small-embedded, why would you choose another language?

\$\endgroup\$
4
  • 4
    \$\begingroup\$ C++ can generate a lot of overhead but the fully compliant C++ compiler I used for MSP430 did not require a runtime, C++ did compile to native code. I am sorry, telling others is a disservice and I have downvoted you. You can remove the downvote by providing references that convince me I am incorrect(which will be hard, I have read the assembly listing of compiled C++ for my projects, part of making sure it compiles efficiently) or you can delete your answer which will remove the affect on your reputation(although at this point you receive +8 net rep) \$\endgroup\$
    – Kortuk
    Commented Jul 5, 2012 at 6:34
  • 3
    \$\begingroup\$ I fully agree with Kortuk. Some parts of C++ require extensive run-time support, but the part that does not is still a much much better C (and fully OO). The restriction to this subset is easily enforced by some compiler and linker switches. In some parts (the dreaded printf for instance) C++ has at least the language potential to require much less runtime support (if only std::cout were implemented with small systems in mind...) \$\endgroup\$
    – Wouter van Ooijen
    Commented Jul 5, 2012 at 7:11
  • 1
    \$\begingroup\$ @Kortuk, sorry for not being clear there, but when I said that "C is the only language that..." didn't mean C++ doesn't have both of those things, I meant that C has the combination of the two and C++ has one of them. My emphasis was on the runtime part. I'm also not saying that it is completely impossible to use C++ without a runtime, but it's pretty unusual. I can't see how you can have things like exception handling and RTTI without a runtime, for instance, and those are quite important features. But I apologize if the way I expressed this led to possible misconceptions. \$\endgroup\$
    – fceconel
    Commented Jul 5, 2012 at 15:49
  • \$\begingroup\$ @fceconel, I have never used C++ with a runtime environment, and we are discussing embedded systems here, I have never used a run-time on my microcontrollers. This question is a bit different then you may have read it, it is asking why C/C++ are the only prevalent choices, not why C instead of C++. I will admit, using something even as simple as cout will never happen in my micro, I have a few free pins, not a screen. \$\endgroup\$
    – Kortuk
    Commented Jul 5, 2012 at 16:14