A promise of easier embedded-systems networking

Java-based microcontrollers have tremendous potential as embedded device controllers, providing easy network connectivity to a wide variety of home and industrial equipment. A versatile chipset in development at Dallas Semiconductor can help to realize this potential. The chipset, known as TINI (Tiny InterNet Interface), consists of a microcontroller with a multitasking operating system, a TCP/IP network stack, and a Java Virtual Machine that supports applications for equipment control and status reporting. The three-chip set will include a network controller and a variety of serial and parallel interfaces. By supporting a mini Web server written in Java, it will also allow users to interact with factory equipment over a network through familiar, versatile HTML and Java user interfaces. Work is also under way to reduce the chipset to a single chip and to allow it to host the Jini technology. This article will present methods for designing and deploying low-cost Java-based microcontrollers using TINI technology.

In the beginning

The need for embedded systems to collect and report manufacturing data on the corporate IT network existed at Dallas Semiconductor long before the advent of the TINI chipset. The silicon process equipment used at Dallas often costs in excess of million per unit and must be used continuously — and efficiently — to justify the investment. Thus, Dallas required accurate, real-time reporting of its equipment status to avoid buying new equipment when a more efficient use of existing equipment could be made. To this end, we developed an interface-device code named the Natural Bridge, which made it possible to translate, or “bridge,” the control and status indicators of many pieces of semiconductor-fabrication equipment to the company-wide network.

The Natural Bridge consisted of a small circuit board with a microcontroller, lithium-backed nonvolatile memory, an Ethernet interface chip, an RS232C interface, and an interface to the Dallas Semiconductor 1-Wire network. We also developed a cooperative, multitasking operating system for the Natural Bridge. The Bridge Operating System (BOS), written in native code, provided entry points that could be called to transfer data to and from equipment by means of the RS232 port and to communicate on the corporate network using User Datagram Protocol, or UDP.

Successful internal deployments of the Natural Bridge led us to consider what it would take to design a new version that we could deploy commercially on a large scale. We knew that the main limitations to widespread use of the original Natural Bridge were the proprietary OS, a limited network stack, and the necessity of developing all code in assembly language. Realizing that any OS that we developed or licensed would probably lack broad acceptance in the marketplace, we moved to a new design that employed an embedded Java programming environment.

That solved our two biggest problems. First, programmers would be able to program in the Java language instead of assembly. Second, they would be isolated from the details of the underlying OS. The new design also included a full TCP/IP stack, expanded I/O capabilities, and a higher-performance microprocessor. Once fully implemented, this approach promises to overcome all the deficiencies in the earlier design and open the door to widespread commercial use.

Java does Dallas

It was obvious that the Java language and the JDK’s object-oriented programming environment and strong networking capabilities would remove all the limitations of our original system. However, when we considered using the Java language and runtime in a small, embedded environment, we had to address the troublesome question of performance. Can a small microcontroller run Java applications in an efficient manner? The overhead due to bytecode interpretation is typically high, and common solutions, such as JIT (just in time) compilation, are often impossible in a memory-constrained device.

Thus, this use of Java technology would make computationally intensive applications far too slow to be practical. However, the target applications in this environment are I/O — and not computationally intensive. Their strength lies in their ability to perform I/O operations efficiently and at a low price point. Since all physical I/O is performed efficiently by native code, applications typical of the space can still achieve a high level of performance.

As a practical example, consider the typical flow of a small Web-server application written in Java. The server usually spends a lot of time blocking in native code, waiting for a connection request from a remote client. After a connection has been established, control is returned very briefly to the Java application to create an input stream from which to read the raw request.

The read request is again serviced by native code. After the caller’s buffer has been filled with the raw request data, control returns to the server to parse the request. Let’s assume the request was a get — that it requests data collected over time and stored in a log file. The server would fulfill the request by reading the file in reasonably sized blocks and again leveraging the efficient native code to write the data to the client.

In this application, parsing the raw request represents the bulk of the work performed with the Java language and JDK. That is typical of many TINI applications that collect data from one or more physical I/O ports, manipulate it using the Java language, and write to another I/O port. The more data manipulation required by the application, the more care one must take to maintain reasonable performance.

One obvious solution to the problem is to create a native library to improve the performance of such tasks. Though a library reduces portability, it is still the correct solution for some applications.

While we make no hard claims about realtime performance, we have made every attempt to avoid long delays in program execution. Also, since most of the I/O is interrupt driven, it usually runs reasonably quickly regardless of other system delays such as task scheduling and garbage collection.

The TINI hardware

The TINI chipset consists of three chips: a microcontroller, a ROM containing the firmware, and an Ethernet controller. At the heart of the TINI platform is the Dallas Semiconductor DS83C390 microprocessor. The DS83C390 has several peripherals integrated on the same chip with the CPU core. These peripherals include serial, parallel, and 1-Wire ports, as well as two onboard CAN (Controller Area Network) controllers and several spare port pins to control miscellaneous devices such as relays and indicator LEDs. The high level of integration drastically reduces the target system’s component count and, therefore, its cost. Future versions of TINI will further integrate the network controller and ROM to the TINI microcontroller.

TINI’s controller is capable of addressing up to 4 MB of RAM and 512 KB of ROM. During the boot, the I/O manager will detect the memory configuration and CPU clock rate and locate optional hardware interface chips such as the Ethernet controller and CAN bus interface. This offers system-level hardware designers flexibility when they choose memory densities and speeds, as well as the physical I/O they wish to support. For example, the designer of a cost-sensitive system without high memory or performance requirements would most likely choose a lower clock rate and use inexpensive, low density, slow memory.

Note that most of TINI’s I/O capability is aimed at interfacing with other devices or machines, though a liquid crystal display and perhaps a keypad can be added to the parallel port to provide a minimal local human interface. If a more powerful human interface is needed, a remote computer with a Web browser or other graphical display provides it.

TINI software

TINI’s ROM houses both the native code, which implements the OS, the JVM (Java Virtual Machine), and the Java API classes. This section describes the components in more detail.

TINI OS

TINI OS is very small and provides a file system, memory, I/O managers, and basic services such as task scheduling. Unlike most small embedded-controller operating systems, TINI OS is designed to switch heavyweight tasks. Specifically, it can switch between multiple executing instances of a Java bytecode interpreter, thus providing a foundation for running multiple Java applications. The task scheduler is a simple round-robin scheduler that provides constant 4-millisecond time slices. With the exception of the garbage collector, all tasks driven by the OS are Java applications. The OS manages multiple native/kernel processes through cooperative multitasking and is therefore subject to tight execution time requirements.

The Java Virtual Machine and API

TINI’s ROM provides support for java.lang, java.net, java.io, java.util and javax.comm. The javax.comm package has been extended to provide access to TINI’s additional I/O capabilities. Additional packages contained within the com.dalsemi package provide access to the command shell, the 1-Wire net, and many system parameters. Other packages can of course be downloaded into RAM as a part of an application.

TINI shell (slush)

TINI includes a small command shell (slush) that provides access to remote hosts. This Java application starts during the last phase of system initialization. During construction, slush creates threads that maintain server sockets to listen for and accept client requests for FTP and Telnet connections. When TINI is used without a network controller, or when there is no network configuration information, access to slush is obtained through a TTY login.

An instance of slush uses very little CPU bandwidth until a client requests a Telnet or FTP connection. After a successful login, the remote user can execute Unix-style shell commands to manipulate the file system, set or get configuration information, and start or stop other Java applications. Slush is also extensible. User applications may add and remove commands to slush by invoking methods on an instance of the shell’s base Java class.

The garbage collector

Typical batch garbage collectors halt the execution of an application while they traverse the entire heap looking for and freeing any unclaimed memory, often causing long execution delays. To avoid that problem, TINI’s garbage collector is incremental and compacting. It runs as a separate OS task and, under normal circumstances, will not execute for more than a few milliseconds at a time. There are two exceptions to this rule. First, if an “out of memory” error occurs, the collector will run until it has freed enough memory to fulfill the “new” operation’s request. Second, if all other tasks are suspended pending I/O, the collector will run until the entire heap has been traversed or a task becomes ready.

TINI meets Jini

Dallas Semiconductor and Sun engineers developed a demonstration of their technology and presented it at the January Jini launch in San Francisco. Since TINI is based on the Java 1.1 API definition, the demonstration required a proxy to allow the appliances to become part of the Jini system. Ultimately, the goal of the TINI platform is to fully support Jini technology without the use of a proxy.

Our most recent efforts are focused on upgrading TINI to support the Java 2 API specification, including the packages required for Remote Method Invocation (RMI). This upgrade will render TINI capable of running Jini technology-enabled applications. Once TINI is Jini-technology enabled, its JVM can act as a proxy for any of the devices connected to it, allowing them to join the Jini-capable network communities.

Conclusion

We have described a new platform designed to provide system designers and application developers with a simple and flexible means to connect a wide variety of devices to corporate and home networks. The robust Java programming environment empowers programmers to quickly create applications that provide not only local control of, but also global access to, attached devices. TINI’s networking capability extends the reach of any attached device by allowing interaction with remote systems through standard networking applications such as Web browsers.

The next generation of the TINI platform, capable of running Jini technology, will provide a straightforward way for these devices to interact by allowing them to join the Jini technology system without proxies. As the TINI platform evolves, improvements will center on increasing performance and making TINI practical for an even broader range of networking applications.

The TINI technology also complements work being done by engineers at Sun Microsystems on the Micro Edition of the Java 2 platform (J2ME), and it appears likely that future solutions for networking embedded systems will incorporate the best features of both technologies.

The combination of Jini and Java on the low-cost TINI chipset can greatly reduce programming and deployment costs, freeing developers to create applications with strong security and improved code safety. Future articles will include code samples and small applications that run on the TINI board.