4 ms·

There already are more options than C on embedded devices. You can run C++, Lua, Python, Ada, Lisp, Java, Forth, Rust, and dozens of others. The reason C domina

There already are more options than C on embedded devices. You can run C++, Lua, Python, Ada, Lisp, Java, Forth, Rust, and dozens of others. The reason C dominates is that it's by far the most flexible, portable, and economical of these, despite its safety issues.

01100011 8y ago
I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. Also C compilers were some of the most common for embedded platforms going back a few decades. Up until IoT became a buzzword, the embedded world was sort of insular and you had a lot of guys who got their start in the 80s or before. Sure, there's Forth, but that pretty much died out decades ago. C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.
- Sytten 8y ago
  Totally agree and thats what they still teach us at school in EE and CE (believe it or not). I worked a bit on embedded devices during internships and the only thing I saw is C sometimes with an API to abstract the registers (I was in the world of PIC). I talked with guys that still only coded in assembly and C was a "new" thing for them. People just don't realize that if you can save a KB of RAM and cycles of processor, you save on cost of pieces (you can use cheaper ones) and if you are to produce million of pieces thats a lot of money...
  - berti 8y ago
    I never understood the attraction of PIC in the face of ARM. The ecosystem seemed so much weaker in terms of compilers, libraries, and sheer variety of parts available.
    - 01100011 8y ago
      IIRC, PIC appealed to those embedded/EE guys because it was simple. It was also really cheap. You could add a tiny bit of smarts to your design for a little bit of money and effort. Those guys became well-versed in the PIC weirdness and stuck with it even though other, more traditional(i.e. 8051 based) micros came out with good features at nice price points. I don't remember a lot of cheap, easy to use options based on ARM around the time that the first PICs came out. Honestly I'm not sure though. I skipped the PIC entirely. I dealt with Z8's and 68HC12s at the time(and TMS320s, but that's another story).
- berti 8y ago
  > I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. I think that's a pretty unfair characterization. > C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time. I've been doing a little prototyping at work recently with micropython (not my decision), and this is one of things that frustrated me. There's also lack of good tooling compared to (embedded)C/C++, and the lack of libraries. Regular pure-Python libraries either don't run, or perform very poorly because they don't stick to the subset of the standard library that's "acceptable" in micropython. It's basically a whole different ecosystem to Python, negating a lot of the advantages of Python.
  - 01100011 8y ago
    Well, that's my experience since working in embedded since '97. Remember there weren't a lot of options back then. It was the days before flash memory and you had to either use UV erasable EEPROMs or make a custom masked part. The C++ compilers were all horrible and inefficient. The debuggers barely worked. C was often your only option for a high level language, if you even had one. Some of the parts I used back then were ASM only, and if you managed to have a compiler it was so inefficient that you couldn't use it. The embedded world as I knew it was ruled by EEs. These people were barely programmers. I knew guys who would rather cut and paste code instead of make functions. Regarding embedded Python, you have my condolences. I took a job where they use it to implement most of the system level code for a safety critical device. I was excited to do more Python until I realized what a poor choice it was for embedded. Hell, I'd rather use Java because at least you have a compiler to catch a whole class of bugs. I'm old fashioned. If someone's life depends on it, write it in C, avoid dynamic allocation, and make heavy use of state machines. My friend works on satellite code and that's basically how it is. They don't even use an OS.
    - berti 8y ago
      I guess the CS component of EE has grown quite a lot since back then. You learn at least a solid programming base early on, and get much deeper into CS if you go down the embedded systems path. I totally agree with everything in your last two paragraphs!
monocasa 8y ago
And C lacks a GC. Practically GCs don't fulfill the constraints of a lot of embedded projects. Even the real time GCs come at a heavy perf cost. C++ has had a remarkable amount of uptake over the past few years. TI has been pushing it hard for using C++ with their DSPs.
- pjmlp 8y ago
  Hopefully as it allows for more secure coding, but it is a struggle against the established mentality, as it has become a common theme on C++ conferences.

01100011 8y ago

I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. Also C compilers were some of the most common for embedded platforms going back a few decades. Up until IoT became a buzzword, the embedded world was sort of insular and you had a lot of guys who got their start in the 80s or before. Sure, there's Forth, but that pretty much died out decades ago. C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time.

Sytten 8y ago
Totally agree and thats what they still teach us at school in EE and CE (believe it or not). I worked a bit on embedded devices during internships and the only thing I saw is C sometimes with an API to abstract the registers (I was in the world of PIC). I talked with guys that still only coded in assembly and C was a "new" thing for them. People just don't realize that if you can save a KB of RAM and cycles of processor, you save on cost of pieces (you can use cheaper ones) and if you are to produce million of pieces thats a lot of money...
- berti 8y ago
  I never understood the attraction of PIC in the face of ARM. The ecosystem seemed so much weaker in terms of compilers, libraries, and sheer variety of parts available.
  - 01100011 8y ago
    IIRC, PIC appealed to those embedded/EE guys because it was simple. It was also really cheap. You could add a tiny bit of smarts to your design for a little bit of money and effort. Those guys became well-versed in the PIC weirdness and stuck with it even though other, more traditional(i.e. 8051 based) micros came out with good features at nice price points. I don't remember a lot of cheap, easy to use options based on ARM around the time that the first PICs came out. Honestly I'm not sure though. I skipped the PIC entirely. I dealt with Z8's and 68HC12s at the time(and TMS320s, but that's another story).
berti 8y ago
> I think C dominates because it's a language many embedded guys, who often are EE's not CS graduates, can get their head around. I think that's a pretty unfair characterization. > C is also deterministic, unlike, say, Python, where you don't have a compiler to catch type errors and things can blow up unexpectedly at run time. I've been doing a little prototyping at work recently with micropython (not my decision), and this is one of things that frustrated me. There's also lack of good tooling compared to (embedded)C/C++, and the lack of libraries. Regular pure-Python libraries either don't run, or perform very poorly because they don't stick to the subset of the standard library that's "acceptable" in micropython. It's basically a whole different ecosystem to Python, negating a lot of the advantages of Python.
- 01100011 8y ago
  Well, that's my experience since working in embedded since '97. Remember there weren't a lot of options back then. It was the days before flash memory and you had to either use UV erasable EEPROMs or make a custom masked part. The C++ compilers were all horrible and inefficient. The debuggers barely worked. C was often your only option for a high level language, if you even had one. Some of the parts I used back then were ASM only, and if you managed to have a compiler it was so inefficient that you couldn't use it. The embedded world as I knew it was ruled by EEs. These people were barely programmers. I knew guys who would rather cut and paste code instead of make functions. Regarding embedded Python, you have my condolences. I took a job where they use it to implement most of the system level code for a safety critical device. I was excited to do more Python until I realized what a poor choice it was for embedded. Hell, I'd rather use Java because at least you have a compiler to catch a whole class of bugs. I'm old fashioned. If someone's life depends on it, write it in C, avoid dynamic allocation, and make heavy use of state machines. My friend works on satellite code and that's basically how it is. They don't even use an OS.
  - berti 8y ago
    I guess the CS component of EE has grown quite a lot since back then. You learn at least a solid programming base early on, and get much deeper into CS if you go down the embedded systems path. I totally agree with everything in your last two paragraphs!

monocasa 8y ago

And C lacks a GC. Practically GCs don't fulfill the constraints of a lot of embedded projects. Even the real time GCs come at a heavy perf cost. C++ has had a remarkable amount of uptake over the past few years. TI has been pushing it hard for using C++ with their DSPs.

pjmlp 8y ago
Hopefully as it allows for more secure coding, but it is a struggle against the established mentality, as it has become a common theme on C++ conferences.