15

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"

  • 2
    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? – Jon L Jul 04 '12 at 21:15
  • 1
    @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. – Rocketmagnet Jul 04 '12 at 21:37
  • @Rocketmagnet, I wasn't trying to suggest that C is perfect by any means. I was more trying to get the OP to go down the avenue of, "well, I wish I could do X for example, you can do that in one line in Python!" and try to explain what happens at run-time when such a statement is executed in a high level environment, thus illustrating how that does not translate well on resource constrained systems. – Jon L Jul 04 '12 at 21:41
  • 3
    Embedded isn't strictly C. Here are a bunch of high level languages for embedded systems: http://electronics.stackexchange.com/questions/3423/survey-of-high-level-language-interpreters-compilers-for-microcontrollers?rq=1 – Kellenjb Jul 05 '12 at 03:27
  • 1
    "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. – Toby Jaffey Jul 05 '12 at 09:20
  • There are also other languages which are not Turing-complete: https://en.wikipedia.org/wiki/IEC_61131-3 https://en.wikipedia.org/wiki/Simulink Usually they generate C code. – starblue Jul 05 '12 at 09:33
  • 1
    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. – Kortuk Jul 05 '12 at 15:40
  • Here's a recent article on the "why C?" subject. – Nick Alexeev Jul 05 '12 at 19:43
  • 1
    @Kortuk - Why close it now after it has acquired all these good answers, and is obviously a popular question view/vote wise? Doesn't make much sense to me... – Oli Glaser Jul 05 '12 at 21:20
  • @OliGlaser, because most of the measure of good and bad subjective is actually based on the answers. I knew immediately that it would be an issue but really hoped it would follow those rules well. Instead users have posted many very simple answers and most all of the answers are just receiving upvotes for answering. The number of flags are also a big sign there is a problem. I would enjoy discussing it more in chat. – Kortuk Jul 05 '12 at 21:25
  • @Kortuk - Fine, close it when it first gets asked if it doesn't meet guidelines (no need to wait - I think it was pretty obvious from the start the answers would be as given) However in this case it was left open and now has a lot of very useful information (I would not say the answers are simple at all) Why not make it a Wiki at least? Wouldn't this help all those who want to ask a similar question? You all do a great job, but I just get the feeling that very occasionally the strict adherence to rules wins out over "common sense" ;-) – Oli Glaser Jul 05 '12 at 22:17
  • @OliGlaser, There was a chance that the community would enforce the standards itself, answering with quality and downvoting those that dont meet that standard, it was also possible that discussions would stay clear. Less then 20 hours and 5 flags? Vote arguments happening? I would prefer continue this discussion in chat if you want to talk, it will be permanently in existence for reference there but it wont muddle the waters on this question. I cant be there to close things instantly, the community can but voting to close or flagging, but without that diamond moderators take time, not our job. – Kortuk Jul 06 '12 at 00:24
  • @OliGlaser, The guidelines are a bit fuzzy on these things though, it is hard to tell from just a question if the answers are going to be constructive, the first couple answers when I remember seeing it looked really good and I thought this question might turn out well. Questions that used to be so shopping oriented would only get links now get thorough answers and we are mostly able to leave the boundary questions up but only have to close those questions that are completely a case of finding a link. I hope as our community grows this becomes less of an issue. – Kortuk Jul 06 '12 at 00:29
  • I think it is because C(++) is the first language a manufacturer ports to his platform and because most higher level languages are actually written in C(++). So apart from assembly, C is alway around on nearly any platform. This makes code reasonably portable between platforms and libraries are very soon available. Porting other languages (and its libraries) takes time, third parties, ... – jippie Jul 06 '12 at 23:08
  • If C/C++ stands for statically allocated then it is not subective and the reason is even exposed in the Universities. – Val Sep 14 '13 at 21:17

11 Answers11

18

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++.

Wouter van Ooijen
  • 48,572
  • 1
  • 63
  • 136
  • +1 - nice answer. Ada seems an interesting language, are there any Ada compilers for small micros around? – Oli Glaser Jul 05 '12 at 03:19
  • 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. – Wouter van Ooijen Jul 05 '12 at 08:02
  • 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) – Oli Glaser Jul 05 '12 at 21:44
  • 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... – Oli Glaser Jul 05 '12 at 22:22
  • 2
    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! –  Dec 14 '12 at 10:21
  • I think that embedded has another major aspect besides resource constrainess - time determinism. You need to do stuff in realtime. I noticed that in many courses, "realtime comutation" is even unconcously interchanged with "embedded computer". Dynamic stuff tends to break this requirement. – Val Sep 14 '13 at 21:12
  • For me time determinism is a special case of a resource constraint, the resource being time, and the constraint being two-sides. You are totally right that dynamic stuff (especially general purpose memory allocation/deallocation) will mess this up. I try to teach my students that real-time and embedded are NOT the same, even though they often go together. – Wouter van Ooijen Sep 15 '13 at 07:01
9

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.

mctylr
  • 1,580
  • 9
  • 13
5

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.

Kortuk
  • 13,412
  • 8
  • 62
  • 85
Rocketmagnet
  • 27,394
  • 17
  • 96
  • 182
  • 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. – Kortuk Jul 05 '12 at 01:24
  • You can always use Pascal - it seems to have the added limitations that you are seeking :-). Or some form of Super-Lint. – Russell McMahon Jul 05 '12 at 02:02
  • 2
    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. – darron Jul 05 '12 at 02:29
  • 1
    @RussellMcMahon - I can't use Pascal, because there's no Pascal compiler for the MCUs I'm using. – Rocketmagnet Jul 05 '12 at 08:26
  • @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. – Rocketmagnet Jul 05 '12 at 08:27
  • @Rocketmagnet: Are you sure that there isn't a Pascal compiler for your MCU? It seams that your follow tags are Arduino (which is AVR) and PIC, so I suggest you to take a look at http://www.e-lab.de/index_en.html – avra Jul 05 '12 at 09:26
  • @avara - Thanks for the link, bit it looks like the Pascal compiler supports PIC16s only. We use PIC18s and PIC32s. Also we'll be moving to PSoC5 soon. – Rocketmagnet Jul 05 '12 at 15:12
5

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.

vsz
  • 2,564
  • 1
  • 18
  • 35
  • 1
    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. – supercat Jul 05 '12 at 14:50
5

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 ?

Deek
  • 51
  • 2
  • Interesting, thanks - I'd not heard of SPARK, will check it out. – Oli Glaser Jul 05 '12 at 22:00
  • 1
    Some studies show a speed-up relative to an existing application in C - look at the "Ironsides" DNS server... –  Dec 14 '12 at 10:16
4

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, ...)
Sam
  • 235
  • 1
  • 5
3

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.

AndrejaKo
  • 23,431
  • 27
  • 112
  • 189
3

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.

tylerl
  • 672
  • 6
  • 15
3

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.

starblue
  • 6,502
  • 2
  • 23
  • 36
2

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

Amit Tomar
  • 137
  • 3
1

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?

fceconel
  • 2,659
  • 22
  • 19
  • 4
    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) – Kortuk Jul 05 '12 at 06:34
  • 3
    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...) – Wouter van Ooijen Jul 05 '12 at 07:11
  • 1
    @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. – fceconel Jul 05 '12 at 15:49
  • @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. – Kortuk Jul 05 '12 at 16:14