Workers at a factory in Dallas get the chance to interact with a special kind of vending machine. It dispenses soda without accepting money. Instead, thirsty patrons touch a special ring to the front of the device where a sensor resides. When the machine delivers up a pop can, it makes note of the fact on its own Web page, available for anyone to see over the Internet.
The Web page doesn’t just note individual sales. It keeps track of how many cans the machine still has in stock. It also records how cold the cans are. Finally, it automatically debits the account of each soda buyer through a secure transaction. If the machine was more than just a demonstration, all this information could conceivably go into logistical plans for restocking and dispatching service personnel.
This display of capabilities takes place on the prem-ises of Dallas Semiconductor Corp. It is meant to point up the benefits provided by a new class of single-chip processor designed to provide a familiar Java programming environment.
Attendees at June’s JavaOne conference in San Francisco were able to see similar capabilities in demos of a Web-based weatherstation and dimmable fluorescent light controls that generated temperature readings on a Web page. Such developments are interesting because they show how easy it may become to give embedded computer controllers access to the Internet for monitoring purposes. The idea of building Java into machine controllers seems to be picking up steam. The reason is that Java is an object-oriented language that is not as complicated as C++, the current language of choice for sophisticated control applications. The use of objects lets developers reuse code, design better systems, and more easily build in communication facilities between applications and systems.
There are other advantages as well. For example, Java programmers need not specify specific memory pointers, as do those working in C. This reduces program complexity and the potential for bugs. Moreover, Java retains some of its original allure for program portability across dissimilar computer architectures, though it is not clear just how portable embedded Java programs might turn out to be.
Java board
Dallas Semiconductor’s Java-based processor currently takes the form of a three-chip set called Tini (for Tiny Internet Interface). The company plans ultimately to shrink it onto a single IC. The processor is one that has evolved from the well-known Intel 8051 architecture, though “it is getting pretty far removed from Intel’s original design,” says Dallas Semiconductor’s Director of Software Engineering Steve Curry. For example, the Java processor sports a 24-bit address bus. The address bus is not bank switched, as on the original 8051. The new chip also operates at about 60 MHz.
The other two chips in the Dallas Semiconductor set consist of a read-only memory and an Ethernet interface. The ROM holds a half megabyte of Java code. Developers can also add up to another 4 Mbytes of memory externally.
Static RAM designed for use with the Tini board carries a lithium battery built into its package. This makes the memory nonvolatile, so it retains information in the absence of external power. It is also a key factor that lets the chipset be practical for embedded Java. The reason: The running of a Java program invokes a process called garbage collection that makes numerous memory reads and writes. There is no limit on the number of read/write cycles that Dallas Semi’s battery-backed RAM can accommodate.
In contrast, other nonvolatile memory technologies such as flash memory eventually wear out after a finite number of read/write cycles. Their write cycles also tend to be relatively slow, a factor that works against their deployment in any kind of Java-based control system.
Compiled and interpreted
The issue of garbage collection is one of the topics getting intense scrutiny from developers of both Java chips and Java compilers aimed at real-time applications. Garbage collection is the term used for Java’s automatic reclamation of memory for reuse. This relieves the programmer of responsibility for this task. But the automatic reclamation process can consume a lot of processor time because it involves periodically examining memory to determine if any of it is unused and can go back on the free-memory list.
Periodic garbage collection, if not handled adeptly, can take up enough processor time to severely hamper response to real-time events as in machine control. Real-time Java processors and Java compilers now employ a variety of techniques to keep garbage collection from interfering with control.
For example, the Tini chip set uses precise, incremental, compacting garbage collection. This technique eliminates the long pauses in execution normally associated with reclaiming memory. And Sun Microsystems has defined a special processor architecture it calls picoJava which deals with garbage collection by using a “write barrier” for active memory. This essentially relegates garbage collection to a background function that cannot interrupt real-time processes. Additionally, there are several other techniques based wholly in software that work around the limitations associated with garbage collection.
Java has other difficulties handling real-time tasks as are common in machine control. Most of these stem from Java’s relatively slow execution. A Java program executes more slowly than one written in a compiled language such as C or Fortran. Java has a structure that is called semi-interpreted. Java source code first goes through a compiler that produces an intermediate version called byte code. The byte code then executes line-by-line in a way roughly analogous to an interpreter running a program in Basic.
In general, vendors trying to apply Java in real-time applications are devising ways of speeding up the line-by-line execution process. One technique is to compile Java for execution on a particular machine rather than using a software interpreter. This strategy defeats the original intent of running the language on different platforms, however. But the benefits of native execution seem to outweigh the loss of platform portability. Eliminating the interpreter eliminates the need to store it in memory, ordinarily a 1 to 10-Mbyte requirement. Experts say that Java compiled into machine instructions will perform comparably to other compiled languages.
Java’s attractiveness for real-time use has resulted in the founding of a Real-time Java Working Group. Members include well-known companies such as Hewlett-Packard and Siemens. They aim to develop real-time extensions to the language that will be made publicly available.
How a real-time Java program executes The JVM takes compiled Java byte code and transforms it on the fly into hardware-level instructions that the processor can execute. In addition, Java class libraries that make up the standard API (application programming interface) for programs also load dynamically. Thus it is the JVM that must be tailored for individual processor architectures. It creates what is called a run-time environment. The run-time environment can be embedded either in the operating system or in some other program such as a browser, or it can be a separate program. The term “applet” is reserved for small Java programs that work through a Web browser containing a JVM. (This explains why older versions of Netscape and Internet Explorer get flummoxed by Web pages written in Java. Early browsers do not contain a JVM.) Applets tend to be small because they are designed to be downloaded. They also tend to be oriented toward screen graphics. A clickable button on a Web page, for example, can be an Applet. Java was also designed specifically for network computing. For example, it simplifies the task of designing applications that use both local and remote resources. The programmer can hide the fact, if need be, that part of a Web page application runs on a server. |