Choosing a programming language is an essential part of any serious embedded design project. But the task can be daunting. When should you use a processor-specific language? Why not just use C?
Let’s talk about languages—specifically, embedded control languages. Everyone has their favorite, typically whatever they learned first, but when you get right down to it, all languages offer the same basic features.
First of all, you need to be able to specify a sequence of steps and then select between two (or more) alternative sequences—the if-then-else construct. You also need to be able to repeat a sequence, or loop, and exit that loop when a condition is met. Finally, you want to be able to invoke a sequence from multiple places within other sequences—a call function.
Assembly language is the lowest-level language you can use on most machines. Its statements bear a one-to-one relationship with the instructions the hardware executes. If-then-else and loop-exit constructs are implemented using conditional and unconditional branch instructions, and there’s usually a hardware stack that facilitates subroutine call and return. This is both a blessing and a curse—it enables you to become familiar with the hardware and use it most effectively, but it also forces you to deal with the hardware at all times.
Very early on in the development of computers, the concept of a high-level language (HLL) was developed to reduce this hardware focus. By creating a set of abstract computer operations that aren’t necessarily tied to a particular processor, the HLL frees the programmer from a specific hardware architecture and enables him to focus on the actual algorithm development. The compiler and library writers took these abstractions and efficiently mapped them onto the hardware. HLL opened up programming to “non-hardware” people whose first interest was the application problem and its solution.
Today, there are literally hundreds of computer languages (see http://en.wikipedia.org/wiki/List_of_programming_languages). Some of them are completely general-purpose, while others are very domain-specific. Two languages have been implemented on virtually every microprocessor ever invented: C and BASIC. (There’s no way I can mention them all, so I’ll just touch on some popular embedded ones.) Of the two, C is by far the more popular for embedded apps, since it runs more efficiently on most hardware. Many people would argue that C isn’t a “true” HLL; but even still, it’s a huge step up from Assembly language in terms of productivity.
There have been some niche languages intended for small systems. For example, there’s what you might call a family of reverse-Polish notation (RPN) languages: Forth, Postscript, and does anyone remember a tiny interpreted language called Mouse? These never caught on in any big way, except for Postscript, which is almost universally available these days on printers as a page-description language. But it’s a full programming language in its own right—just ask Don Lancaster!
Along the way, there have been a few processor-specific languages invented. For example, there’s JAL—just another language—which is optimized for 8-bit Microchip PIC processors, and Spin, which is designed to support the parallel-processing features of the Parallax Propeller chip.
Once you start getting into larger 16- and 32-bit chips, the set of available tools expands. Many of these processors have C/C++ toolchains based on the GNU Compiler Collection (GCC). However, this means you can really use any number of languages in the collection on these processors, including Fortran, Java, and Ada.
The designers of some embedded systems want to include the ability for the system to be programmed by their end users. To this end, the concept of an “extension language” was developed. Two notable examples are TCL and Lua. These provide a standard notation for control constructs (branching, looping and function calls) wrapped around application-specific primitive operations implemented by the system designer.
Once you start getting into systems that are large enough to require an operating system (real-time or otherwise), many of the available choices support the POSIX API. This means you can use any of the mainstream scripting languages—such as shell scripts, Perl, Python, Ruby, PHP, etc.—either internally or exposed to the end user.
And finally, there’s the web-based user interface. Even relatively simple embedded applications can have sophisticated GUIs by pushing much of the programming out to the browser itself by means of ECMAscript (JavaScript) or Java. The embedded app just needs to implement a basic HTTP server with storage for the different resources needed by the user interface running on the browser. There are all kinds of toolkits and frameworks out there that help you build such a system.
I’ll stop now. The point is, even in the world of embedded computer applications, there’s a wide variety of tools available, and picking the right set of tools for the job at hand is part of the system design process. Taking a higher-level view, this brief survey might give you an idea of what kinds of tools you would want to put some effort into learning, based on where your interests lie or the application dictates.
