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.


Issue 260: EQ Answers

These are the answers to the EQ questions that appeared in Circuit Cellar 260 (March 2012).

Problem 1—In an RS-232 interface, why is the idle or “mark” level a negative voltage?

Answer 1—RS-232 was developed in the days when people were connecting electromechanical teletypes to telephone lines with modems, and in fact, at that time the design of any equipment connected to a phone line was tightly controlled by the phone company.

The reason RS-232 uses a negative voltage for its idle state is the same reason the phone lines themselves use a negative voltage relative to ground for power—copper wires in long cables potentially exposed to moisture are significantly less likely to corrode if they have a negative DC bias on them.

Problem 2—Similarly, why does the “mark” level correspond to a logical “high” level on the TTL side of the interface?

Answer 2—Again, back in the days when RS-232 was developed, the primary logic families in use were DTL and TTL. Both of these technologies draw significantly less power when a signal is in the high state than in the low state, so the high state is preferred for the inactive state of any signal.

Problem 3—What does the following C function compute? You may assume the input argument is a positive integer.

Answer 3—Remember the algorithm that computes integer square roots by subtracting successive odd numbers from the input value? This function extends that concept to computing integer cube roots.

The reason this works is that taking the differences between successive values is the discrete equivalent of taking a derivative in the continuous world. The derivative of a cubic curve is a quadratic, and the derivative of a quadratic is a straight line. To generate a “straight line” in the discrete world, you just add a constant to a variable.

When you look at successive squares—0, 1, 4, 9, 16, 25, etc.—the differences are 1, 3, 5, 7, 9, etc. This is why the algorithm that subtracts odd numbers works for computing square roots.

When you look at the successive cubes—0, 1, 8, 27, 64, 125, etc.—the first set of differences is the sequence 1, 7, 19, 37, 61, etc. This doesn’t look very useful until you take the differences between those numbers, which are: 6, 12, 18, 24, etc., which is obviously another straight line.

Problem 4—Suppose you are given some calibration constants for a sensor in the form of four-digit hexadecimal (16-bit) integers, and you are told that the format of these numbers is “7 integer bits and 9 fractional bits.” How would you go about converting these constants to floating-point so that you could, for example, work with them in a spreadsheet?

Answer 4—The direct way to convert numbers in an arbitrary fixed-point representation to the equivalent floating-point value is to figure out what the representation for “1.000” would be in the fixed-point notation and then divide the given numbers by that constant.

In this case, with 7 integer bits and 9 fraction bits, “1.000” would be represented as binary 0000001.000000000, or 0×0200. So, if you are given a constant of, say, 0×5453, just divide it by 0×0200 to find out that it represents the value “42.162.”

Contributed by David Tweed (eq at

Issue 260: Creativity in Design

The seed for the interview with Hanno Sander on page 16 (Circuit Cellar March 2012) was sown at the 2008 Embedded Systems Conference in San Jose, CA. Hanno was at the Parallax booth demonstrating his “Dancebot,” which is a Propeller-based, two-wheeled balancing robot he wrote about in Circuit Cellar 224 (March 2009).

Balancing robot design (Source: Hanno Sander CC260)

Since Circuit Cellar is scheduled to publish Hanno’s book Advanced Control Robotics later this year, it made sense to interview him for our annual Robotics issue. As you’ll learn, Hanno is an enthusiastic designer whose intellect and passion for engineering have enabled him to travel the world and make electronics innovation his life’s work. His story should be an inspiration to everyone who reads this magazine.

After you finish the interview, check out the two robotics-related articles featured in this issue.

Square playing field (Source: Larry Foltzer CC260)

First, on page 20, Larry Foltzer tackles the topic of robot navigation with a fascinating article about position determination and acoustic delay triangulation. Next, turn to the back of the issue for Jeff Bachiochi’s article, “Wheel-Free Mobile Robots” (p. 64). Jeff takes you inside a Freescale FSLBOT mechatronics robot. Study the concepts he covers to prepare yourself for your next mobile robot design.

The rest of the issue includes a variety of articles on creative designs and essential engineering topics. I’m sure you’ll agree that the following articles are just as inspirational as they are informative.

Engineer and video game enthusiast Chris Cantrell explains how he built a Propeller-based TV gaming platform (p. 28). He describes how he hacked a joystick and got the classic Space Invaders video game up and running.

Propeller-based gaming platform (Source: Chris Cantrell CC260)

On page 36, Charles Edmondson presents his Rainbow Color Reader. The compact design can identify and announce colors for visually impaired users.

In the February issue, Alexander Pozhitkov introduced the NakedCPU project. This month he wraps up the article series by describing actual experiments and sets the foundation for future research (p. 42).

On page 50, George Novacek helps you prepare for the inevitable: microelectronic component obsolescence. You’ll find his tips invaluable as you move on to new projects.

Interested in the topic of thermal detection? Want to know how IR thermal sensing works? Turn to Richard Wotiz’s article on page 54.

On page 60, columnist George Martin provides his next engineering lesson learned from a real-world project. This month he covers the topic of working with—or without?—printer port connections.

I’d like to wrap up with a note to our staff and long-time readers. This is the 260th issue of Circuit Cellar. That’s quite an achievement! Thank you, colleagues, friends, and readers!

Circuit Cellar Issue 260 March 2012

Robot Nav with Acoustic Delay Triangulation

Building a robot is a rite of passage for electronics engineers. And thus this magazine has published dozens of robotics-related articles over the years.

In the March issue, we present a particularly informative article on the topic of robot navigation in particular. Larry Foltzer tackles the topic of robot positioning with acoustic delay triangulation. It’s more of a theoretical piece than a project article. But we’re confident you’ll find it intriguing and useful.

Here’s an excerpt from Foltzer’s article:

“I decided to explore what it takes, algorithmically speaking, to make a robot that is capable of discovering its position on a playing field and figuring out how to maneuver to another position within the defined field of play. Later on I will build a minimalist-like platform to test algorithms performance.

In the interest of hardware simplicity, my goal is to use as few sensors as possible. I will use ultrasonic sensors to determine range to ultrasonic beacons located at the corners of the playing field and wheel-rotation sensors to measure distance traversed, if wheel-rotation rate times time proves to be unreliable.

From a software point of view, the machine must be able to determine robot position on a defined playing field, determine robot position relative to the target’s position, determine robot orientation or heading, calculate robot course change to approach target position, and periodically update current position and distance to the target. Because of my familiarity with Microchip Technology’s 8-bit microcontrollers and instruction sets, the PIC16F627A is my choice for the microcontrollers (mostly because I have them in my inventory).

To this date, the four goals listed—in terms of algorithm development and code—are complete and are the main subjects of this article. Going forward, focus must now shift to the hardware side, including software integration to test beyond pure simulation.

A brief survey of ultrasonic ranging sensors indicates that most commercially available units have a range capability of 20’ or less. This is for a sensor type that detects the echo of its own emission. However, in this case, the robot’s sensor will not have to detect its own echoes, but will instead receive the response to its query from an addressable beacon that acts like an active mirror. For navigation purposes, these mirrors are located at three of the four corners of the playing field. By using active mirrors or beacons, received signal strength will be significantly greater than in the usual echo ranging situation. Further, the use of the active mirror approach to ranging should enable expansion of the effective width of the sensor’s beam to increase the sensor’s effective field of view, reducing cost and complexity.

Taking the former into account, I decided the size of the playing field will be 16’ on a side and subdivided into 3” squares forming an (S × S) = (64 × 64) = (26, 26) unit grid. I selected this size to simplify the binary arithmetic used in the calculations. For the purpose of illustration here, the target is considered to be at the center of the playing field, but it could very well be anywhere within the defined boundaries of the playing field.

Figure 1: Squarae playing field (Source: Larry Foltzer CC260)

Referring to Figure 1, the corners of the square playing field are labeled in clockwise order from A to D. Ultrasonic sonar transceiver beacons/active mirrors are placed at three of the corners of the playing field, at the corners marked A, B, and D.”

The issue in which this article appears will available here in the coming days.