Embedded software developers have a reputation in the software world at large for being a bit slow. Not dim, you understand—everyone knows we tackle sophisticated problems—but slow to pick up on new software tools and languages. This accusation has some truth. Today, some 77.2% of projects use some C, another 46.2% use assembly language, and 44.2% use C++. (The numbers add up to more than 100% because a project may use more than one language.)
Few in IT would think of writing in a language as close to the machine as C, let alone assembly code, these days. We embedded developers would quickly retort that our problems have to be very efficient, very small, and in many cases, very fast too. We recognize, of course, the advantages of writing code at a higher level of abstraction. After all, studies for thirty years have shown that we can write the same number of lines of code per day, irrespective of the language. Since we get more functionality for a line of C++ than for a line of assembly, it stands to reason that our productivity increases as we move to a more abstract language.
Meanwhile, the IT folk are moving towards higher-level-still languages such as the Unified Modeling Language. The UML has made some headway in the embedded market, mostly as a sketching language, or as a blueprint for further software development. More usefully, it is also an executable language, with state machines for modeling concurrent behavior and exploring synchronization issues. But it is so far away from the machine that using a model-based language seems unlikely in the embedded space, unless we could generate fast, small, efficient code with complete control over the generated output, that is.
View Entire Paper | Previous Page | White Papers Search
If you found this page useful, bookmark and share it on: