Issue 260: Embedded Control Languages

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?

In the March issue of Circuit Cellar, Steve Ciarcia reviews a handful of programming languages and types of and processors—and projects—for which they are intended.

Here’s Steve’s take:

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 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.


GPS-Based Vehicle Timing & Tracking Project

The KartTracker’s Renesas kit (Source: Steve Lubbers CC259)

You can design and construct your own vehicle timing system at your workbench. Steve Lubbers did just that, and he describes his project in Circuit Cellar 259 (February 2012). He calls his design the “Kart Tracker,” which he built around a Renesas Electronics Corp. RX62N RDK. In fact, Steve writes that the kit has most of what’s need to bring such a design to fruition:

Most of the pieces of my KartTracker are already built into the Renesas Electronics RX62N development board (see Figure 1). The liquid crystal display (LCD) on the development board operates as the user interface and shows the driver what is happening as he races. The integrated accelerometer can be used to record the G forces experienced while racing. A serial port provides connections to a GPS receiver and a wireless transmitter. Removable flash memory stores all the race data so you can brag to your friends. You now have all of the pieces of my KartTracker.

The following block diagram depicts the relationship between the CPU, base station, flash drive, and other key components:

KartTracker Diagram (Source: Steve Lubbers CC259)

The software for the system is fairly straightforward. Steve writes:

The KartTracker software was built around the UART software sample provided with the RX62N development kit. To provide file system support, the Renesas microSD/Tiny FAT software was added. Finally, my custom GPS KartTracker software was added to the Renesas samples. My software consists of GPS, navigation, waypoints, and display modules. Support software was added to interface to the UART serial port, the file system, and the user display and control on the RX62N circuit board.

Pseudocode for the main processing loop (Source: Steve Lubbers CC259)

Read Steve’s article in the February issue for more details.

If you want to build a similar system, you should get familiar with the Renesas RX62N RDK. In the following video, Dave Jones of EEVBlog provides a quick and useful introduction to the RX62N RDK and its specs (Source: Renesas).

Good luck with this project. Be sure to keep Circuit Cellar posted on your progress!

Click here to purchase Circuit Cellar 259.