why are embedded systems programmed in C?
Is it because of the slightly larger overhead on C++ (or drastically larger c#)?
Printable View
why are embedded systems programmed in C?
Is it because of the slightly larger overhead on C++ (or drastically larger c#)?
I'd say because of the overhead and also because C is closer to the hardware level than C++. I think there are quite a few topics on this already. Most if not all universities teach engineers C in their first year, especially electrical and telecommunications engineers.
C++ is a little more complex, this is true. And some embedded systems just can't handle it (this just shows how weak embedded systems truly are :D). It seems amazing how much it's possible to cram into such inferior hardware with lightning-fast code written in C.
(And I doubt we will ever see C# on embedded systems; it's just a too big, too bloated language; plus it's interpreted.)
Embedded systems encompass a lot of things, from little tiny PIC systems where the programming language is probably assembler and no real OS, to large monsters with multiple processors and many gigabytes of memory running 64-bit versions of Linux or Windows.
My definition of an "embedded system" is "a computer with a dedicated purpose that can't trivially be made to do other things". There's an embedded computer in your CD-player, MP3 player or any modern car-stereo. There's also embedded computers in the telephone switch that your phone calls go through when you call on a landline or mobile phone. Modern washing machines and dishwashers use embedded computers, and any larger ethernet switch or router would also have a processor somewhere.
Some of these systems are more concerned with code-size than speed, others need to cram in as much speed as possible with limited processor capacity. Whilst it's possible to write very efficient code in C++, it's often easier to do in C, because it's more obvious what code is actually being executed in plain C than in C++. [No one is going to buy an MP3 player because it has a 400MHz processor, when a 300MHz processor is good enough to do the job, so paying less for the 300MHz processor will be beneficial to the profit margin of the company producing the MP3 player - in the embedded business, no one is willing to pay for "extra performance"].
Many of the benefits in C++ are the ability to hide dynamic memory management. But embedded systems often have very limited memory, so dynamic memory is either very limited [so it's important to understand exactly how much of it is being used], or not allowed at all - you have to do everything with statically sized arrays. In this case, for example STL is pretty meaningless, as it relies heavily on dynamic memory allocation.
In cases where the limitation of memory and/or performance allows the use of C++, it's used in these system, and many popular embedded products are wholly or partly written in C++.
It's all about using the right tool for the job - a small embedded system is probably not going to need namespaces and layers of class hiearchies to solve the problem, since the task to solve is only a few thousand lines of code anyways. In a large embedded system, where the software is hundreds of thousand lines of code, C++ is likely to be a better fit to the job. You don't use your 10mm flat-blade screwdriver to fix a watch, right? [unless fixing it means mashing it to a pulp and getting a new one!]
--
Mats
I think the larger point here is also that the higher level the language, the more is being done "behind-the-scenes" as both matsp and Elysia have mentioned. With embedded systems, you want to limit the amount of stuff that's going on without your knowledge, because a lot of it will be irrelevant to you and potentially affect performance. That's not so much a problem on a large desktop PC, where a couple more CPU cycles mean nothing. But when every byte counts, it's a different story.
QuantumPete
Good point, QuantumPete - I hinted at it, and you expressed it more clearly.
--
Mats
It seems amazing how much bad advice it is possible for you to cram into such inferior posts. Knock it off.Quote:
Originally Posted by Elysia
Now hardware has a direct cost to the consumer so you often have to give up computing power to save on cost (both $$$ and things like electrical power). For example, I'm not going to pay more then about $10 for a solar power scientific calculator. With that in mind you have to balance the amount (and type) of hardware you have with its cost. And in my example you also have to make sure that the hardware doesn't draw more power then the solar cells can provide.
I recently completed a embedded project that I wrote in C. I then went to port it to C++ using a more object based model. I found that it became a lot more difficult to determine the number of instructions that were going to be executed for a particular operation. In my project a lot of stuff was being done in ISRs so I had to make sure that it was as fast as possible.
Now to give some comparisons: The processor was an 16Mhz 8bit processor that we got already installed onto a breakout board for $20. I recently got some Sun SPOTs that are 180Mhz 32bit processors that are programmed in Java and it cost me a lot more for them (to be fair they also have sensors, a battery, wireless, etc).
I think another reason that C is so popular is that it remains pretty close to assembly which is sometimes needed on smaller processors as you might need to make the code really tight or you might need to do something that can't (easily) be expressed in higher level languages.
Hey, did I say it was bad somewhere? I didn't.Quote:
Originally Posted by Thantos
Yes, it's inferior hardware. No, it's not bad hardware.
I find it pretty amazing how fast something can run on slow hardware vs how slow something runs on a PC.
If you'd compare the embedded vs PC, then you'd see how many cycles were lost on the PC! Now THAT seems amazing that they can cram fast code onto small hardware.
And NO, I don't have anything against C per se, I have something against how the standard handles type safety and all that. I'd be happy to write C code if the situation demands it. I'm pretty familiar with low level stuff.
It isn't inferior in the least. Less powerful yes but for its applications it is the proper hardware. If I tried to use my 2.3 GHz Dual core processor instead I would quickly drain the batteries. In that case the dual core would be inferor to the 16Mhz processor.
Let's define it less powerful, then. Yes, hardware is designed for the device it's embedded in, whether that be a portable device, a DVD player, or whatever.
It's such a small processor compared the "beasts" of today's x86-64 processors. However, with proper optimizations, you can run a lot of code on that machine that may rival the speed of today's processors. That, my friend, is the power of C and it's truly fantastic.