Why are C, C++, and LISP so prevalent in embedded devices and robots?

Question

It seems that the software language skills most sought for embedded devices and robots are C, C++, and LISP. Why haven\'t more recent languages made inroads into these applicat

Answer 1

Because embedded devices mostly have limited resources where it is not welcome to have luxury such as automatic garbage collector. C/C++ allows you to work on quite low levels and program close to machine so that you get effective code as very much needed on those devices.

One more area where high-level languages like Java and .NET don't play well is real-time operation. You can't afford to get suddenly stalled because the garbage collector just kicked in at the worst possible moment.

Answer 2

Most commercial and industrial robots are programmed in C or C++. There maybe another language that the user interacts with. For example The industrial robot company I work for uses C running in a VxWork OS, but the applications programmers like me work with a proprietary language for commanding the robot. Both C and C++ give you a great deal of access and control over the hardware. You don't find too many commercial drivers for high power servo control motors. While complex these robots just follow basic routines.

LISP is mainly used in research robots like those that competed in the DARPA challenge. These types of robots need more "intelligence" then industrial or commercial robots.

Answer 3

The main reason for the prevalence of C and C++ is that the runtime is deterministic for both due to the lack of garbage collection requirements. This makes it a good choice when you have to provide runtime guarantees. Not too mention that C has been considered the "higher level assembly language" of choice for many years.

Another interesting observation is that most embedded devices do not need or even have access to a complex GUI layer -- cellphones are an obvious exception. Most of the embedded work that I have done professionally has been in the cable set-top box arena so I may have a slanted view of things. And "No", I don't consider the set-top box to be a hard embedded environment. We grew up from having nothing more than a raw memory map of what is "on screen" and very little in the way of resources. To make a long story short, on screen graphics are an exercise in bit-twiddling with fixed bit widths - this is another place that pointers in C really shine.

I'm really not too surprised that Java hasn't made headway into the more "bare bones" market yet. The interpreter is just too heavy even though the Java ME was supposed to solve this. It is pretty prevalent in cell phones (e.g., BREW) and is slowly making its way into the set-top and TV markets (e.g., <tru2way> and GEM) but it isn't there yet and I'm really not sure that it will ever be.

As others have mentioned, FORTH is an "interpreted" language that has been used in a number of embedded environments as well as in quite a few bootloaders. Interpreted languages can definitely be used in realtime environments. Not all implementations of FORTH are interpreted though. LISP has been embedded as well.

I think that the main criteria for an embedable language are:

1. deterministic memory management
2. access to well-defined bit sizes (still not sure how LISP fits in here)
3. simple execution environment
4. entirely functional or general purpose
5. flat memory model

The last point is the most interesting in my opinion - this is also why I believe that many languages will have trouble in the embedded market. Pure functional languages are a natural fit for concurrency and usually work in a flat memory model. General purpose languages work well because they don't usually proscribe any particular threading model which gives a lot of flexibility to the RTOS runtime implementers. Virtual memory environments are damned near impossible to implement so that they are deterministic and fast. This makes it very difficult for languages that require virtual memory support to really function correctly.

Answer 4

• Embedded system needs a bare minimum OS and simple (not always) Application, since most OS-es are "C" its a natural choice

• Scarcity of Processing/Memory resource force optimization from very low-level. C (edge over C++) has a great scope of Optimization