Ask embedded programmers what tools they use, and you'll usually find a common thread: C/C++, an integrated development environment (IDE) or their favorite editor/debugger, and a standard library or platform like Microsoft .NET.
These tools work for most applications. But what happens when the situation turns into hammering a nail with a screwdriver? The screwdriver gets a good workout. Programmers who are more adventurous or enlightened look for a new tool.
SCRIPTING LANGUAGES Programmers often overlook scripting languages in embedded applications. Usually, they lack the speed of C, and their runtime framework is large. These issues aren't a problem on a PC with lots of horsepower, gobs of memory, and hard disks that hold hours of movies. But they can be limitations in an embedded environment. Processing power and memory capacities continue to grow, though, especially with the advent of low-cost 32-bit microcontrollers.The base code size typically is the issue for most scripting systems because they're often designed to be feature-rich. In some cases, it's possible to strip down a system to its minimum components, so developers only have to pay the space price for the features they require. This is similar to how developers must already prune a real-time operating system and runtime libraries for C applications. Also, the result application is often smaller since the runtime generally handles the heavy lifting.
Scripting languages have many advantages, like a more flexible type system and better text handling functions that will benefit some applications. It's very easy to write simple applications quickly, and they're apt to be more portable than C code. They also tend to be more dynamic, as some languages support runtime compilation. This is handy for debugging, but it's also useful for making a device more flexible or customizable.
Also, scripting languages are readily available and well supported. Perl, PHP, Python, Ruby, TCL, and Javascript are used in a range of applications, from Web services to server management. Of course, Web-based solutions lead to some interesting tradeoffs for embedded applications.
For example, many embedded network devices implement a Web server and generate HTML pages that are viewed using a Web browser that usually runs on a powerful PC. What happens if that PC could be used to handle some of the chores normally done by the embedded device?
USING AJAX This can be done in a variety of ways. One method that's becoming more common is AJAX (Asynchronous JavaScript Technology and XML). In this case, an embedded device would deliver information and possibly the Javascript code via its Web server. The code runs on the PC that then interacts with the embedded device using XML formatted messages instead of having the embedded device create complete HTML pages.This approach is not only more dynamic, it also can be significantly more responsive since the PC handles user interaction, not the embedded device, which is typically less powerful. Likewise, the source of the data is the embedded device. But the source of the Javascript program can be anywhere from a server to a gateway to the PC itself. It's an interesting way to distribute the load and simplify the embedded device. A completely new user interface can be constructed without modifying the embedded device.
Considering different alternatives like scripting languages and AJAX is a significant step. Luckily, most scripting systems are available as open source and can be readily evaluated. Some, like Javascript, are standards already within applications like Web browsers and servers.
Developers looking to be even more daring might consider non-mainstream possibilities such as Scheme, a variation on Lisp. A number of Scheme platforms such as Per Bothner's Kawa Scheme generate Java bytecodes, making them scripting systems that can coexist with Java applications.
Are you using a scripting system in your embedded application? Let me know at [email protected]. They might make a great Design Brief.