|
|
|
|
| Abstract: We have implemented an embedded-Java web-camera using the NS486 and a common $250 Connectix Color QuickCam. The NS486 is a new `single-chip' embedded system version of the common 486 PC architecture. A custom operating system for embedded systems, the Java Nanokernel (JN), has been implemented specifically to support embedded-Java. A Java server has been written that allows camera servlets to be downloaded on-the-fly to control the camera. The design, implementation, and status of this embedded web-camera, the JavaCam, is described. JavaCam is an example of an embedded Internet sensor in which executing Java applications can be dynamically altered. |
| Keywords: Java, Web, Camera, Internet, operating-systems, embedded-systems, real-time, thin-OS, National Semiconductor , NS486SXF . |
The embedded system lab at UCSC is evaluating the practicality of using the Java programming language for embedded system applications. We are gaining first-hand experience with the real-time operating system functionality required to support Java in embedded systems and are investigating Java performance and size on two highly-integrated 32-bit embedded processors. The lab is also interested in thin-OS support for high-performance network components and is studying novel concurrent system programming techniques.
To make this research concrete and relevant, it was decided to port the Java Virtual Machine (JVM) to a new 32-bit embedded CPU, the National Semiconductor NS486SXF . The NS486 contains many of the I/O devices commonly found on a PC's motherboard on the CPU chip itself, thus supporting near `single-chip' embedded-PC solutions. In this paper the term JVM refers to the Java Interpreter and its entire run-time, that is, the complete body of code required to execute Java programs. The JVM was available, for research purposes, from Sun (the JavaSoft business unit of Sun now handles Java research and development).
The port of the JVM required implementing a custom operating system, the Java Nanokernel (JN), as this work was started before JavaSoft's JavaOS became available. To demonstrate embedded-Java Internet applications, it was decided to implement a set of Java programs that would provide network access to a cheap PC camera. This required adding a TCP/IP stack to JN, resulting in an embedded Internet computer which allows access through Java to the camera. We call this system the JavaCam.
The resulting system can be used as a Java-enabled Internet security camera or embedded Internet sensor.
This section briefly describes the NS486 chip, the JN kernel, the TCP/IP stack, our modifications to the JVM, and the original web server that evolved into the JavaCam server which provides primary control of the embedded system.
The following diagram shows the major JavaCam software components on the NS486:
|
||||
| JN APIs: Threads, Monitors, Files, Exceptions, Sockets | ||||
| JN Nanokernel | ||||
| Drivers: clock, calendar, UART, Ethernet, Camera |
The JavaCam server provides overall control of the camera via Java native methods using the camera driver. The camera driver uses the NS486 bidirectional parallel port. Internet support is provided via the KA9Q TCP/IP stack and the Ethernet driver. The JN APIs (Application Program Interface) support both the Java Virtual Machine interpreter (the JVM) and the TCP/IP stack.
The NS486SXF is intended to be a `single-chip' 32-bit 486 PC core providing minimum motherboard part count [Draeger 97]. Incorporated directly on-chip are a PCMCIA controller, a UART serial port, an enhanced (bidirectional) parallel port, an LCD display controller, infrared serial control, a real-time clock/calendar, a watchdog timer, programmable interval timers, 2 peripheral interrupt controllers, a serial high-speed synchronous interface (Microwire), a degree of power management, a DMA controller, a DRAM controller, and a bus interface unit. The bus interface unit can control the standard PC ISA bus or the PC/104 embedded system variant of ISA.
The programmer has considerable control over the configuration of resources and the layout of NS486 I/O space. For instance, the programmer can specify the location of device control registers and the interrupt IRQ levels for many of the above on-chip controllers, unlike many current systems which require manually setting DIP switches on PC controllers or motherboards.
To make space for these peripherals on the same silicon as the CPU, the NS486SXF eliminates the floating point unit, does not have virtual memory or associated page tables (it does have segmentation, however), and does not support Virtual 8086 Mode or 16-bit Real Mode. Thus, the NS486 cannot run 8086 code and cannot run DOS or a standard PC BIOS. The NS486 boots in flat 32-bit Protected Mode and is intended to be used for embedded control applications using conventional commercial real-time operating systems.
Additional NS486 information can be found at:
| NS486 Overview [http://www.national.com/appinfo/ns486/prdbackg.html] |
|
Odin
: A National reference design for a NS486-based web browser that costs $200.
[http://www.national.com/news/1996/9611/emb96006emco.html] |
| NS486 Home page [http://www.national.com/ns486/index.html] |
| NS486 Core Architecture (slide show). [http://www.national.com/appinfo/ns486/hotclast/sld001.html] |
The JVM requires an underlying operating system. Thus, we designed and implemented an OS, the Java Nanokernel (JN), specifically to support the JVM [Montague 96a |Montague, et al.] . JN may have been the first OS, other than Sun's JavaOS, designed explicitly to support Java. JN is a conventional event-driven soft-real-time system implemented in C. The JN API was determined by removing the Unix multi-threading run-time to which Java had originally been written. The missing entry points were then replaced with JN APIs. Determining the JN API was performed, for the most part, without a detailed examination of the code of the existing Unix multi-threading run-time. As the API and functionality of the JavaSoft multi-threading run-time had not been documented, our document describing the JN API became the basis of the corresponding JavaSoft specification [Montague 96b].
JN is a nanokernel with the following characteristics:
The only services that JN implements are those that are mandatory to support Java (the JVM) or the TCP/IP package, KA9Q. JN has a simple file system that manages persistent storage located on a PCMCIA battery-backed RAM card. This file system provides hierarchical directories, as file directory structure is visible within Java source code.
JN currently supports clock, calendar, serial UART, bidirectional parallel port, PCMCIA, and Ethernet drivers. Except for the Ethernet, all the controllers for these devices are located on the NS486. The Ethernet controller is on a PC/104 card. PC/104 is an embedded system variant of the standard ISA bus. The Connectix QuickCam, used by JavaCam to obtain images, uses the parallel port interface.
To run Java programs using Internet sockets, we ported a widespread PC TCP/IP package, KA9Q, to JN. KA9Q source is freely available to universities for research purposes. As part of this port, JN was extended to support the KA9Q threading API. KA9Q normally runs TCP/IP threads on top of DOS using the non-preemptive KA9Q kernel. The KA9Q kernel was removed and JN APIs written to provide this functionality.
Implementing the Ethernet driver was the most difficult task in the entire system implementation. Implementing and testing this driver was as much work as implementing the rest of the JN system, and this driver is probably still the weakest system component.
This section discusses significant issues which occured while implementing camera support using Java.
Java currently uses 10 priority levels, priority 1 through 10. Ready threads with larger priority run before those with smaller priority. The JVM assumes an underlying concurrent programming environment in which each high-level interpreted Java thread corresponds to a low-level `system' thread. The low-level threads provide context for asynchronous activity, for instance, I/O completion or alarm management.
JN originally supported 10 priority levels, exactly matching Java. We originally ran TCP/IP threads at a high priority within this range. However, the JVM garbage collector disables thread scheduling when it runs, to assure unrestricted access to the heap.
We did not want to disable TCP/IP for long periods while the garbage collector was running. This was a particular problem when performing lengthy debugging activity in the midst of the garbage collector code path. Thus, we added another 6 priority levels to run TCP/IP threads at a level higher than any Java thread. The TCP/IP threads are typically independent of Java. However, care must be taken that buffers in the Java heap are marked so as to preclude the garbage collector from moving or discarding them if they are being used for Java TCP/IP I/O. Additionally, since each Java TCP/IP connection maintains 5 pinned objects in the Java heap due to native network code, excessive TCP connections may lead to Java heap fragmentation, as the garbage collector will be unable to make significant progress.
The JDK 1.0.1 Garbage Collector, part of the JVM run-time library, was modified in two ways [Baldwin]. Since the NS486 does not support virtual memory, the Java heap cannot expand beyond its original size, as it would in other versions of Java. All code pertaining to expansion of the heap was removed. The JN Java heap currently stays fixed at 1.5 Mbytes. If the collector is unable to reclaim sufficient heap space to satisfy a given request, it fails and halts the system.
Because of the critical need for efficient garbage collection, and the soft-real-time requirements of JavaCam, we are currently experimenting with a modified version of the original garbage collection algorithm. The new garbage collector makes a single pass over the heap, as opposed to the multiple passes of the original collector. The new algorithm forces compaction and executes finalize methods during each collection cycle, whereas the original algorithm might not compact or execute finalize methods if it managed to satisfy the single current request. Although this new single pass may take longer than the original `lazy' method of garbage collection, it collects space more efficiently and, in the long run, results in fewer calls to the collector.
Asynchronous garbage collection is not currently enabled.
| JN |
|
|||||||||
| TCP/IP | 19K | |||||||||
| Hardware Test/Initialization | 8K | |||||||||
| TOTAL | 45K |
Our current system, with the JVM included, requires some 400-500K of uninitialized memory, 400-500K of initialized memory, and around 500K of PCMCIA storage. The PCMCIA storage is almost entirely Java class files. This is a minimum system. In practice, we run Java with a heap of 1.5 Mbytes. The code and static data size of the 17K LOC that constitute JN is around 85K.
We keep considerable debugging and development support in the system. There is a very large event log, numerous structure formatting routines for debug output, and around 60 simple test programs that we keep linked into the system.
This section describes JavaCam [Allen]. JavaCam consists of a Connectix QuickCam attached to the parallel port of the NS486, a JN device driver which sends commands to the camera and receives image data at the lowest level, and a set of Java classes which use the device driver.
JavaCam is an example of a remote network sensor, controlled by Java, that is fully programmable over the network without ever shutting down the sensor. Java provides remote execution mechanisms which can support dynamic software updates and dynamic system reconfiguration. These mechanisms are similar to the mechanism that makes possible Java applets, which are the primary source of interest in Java by the Internet community.
Java applets are programs (technically portions of programs) that are loaded from remote servers onto local machines and then executed inside of another program that contains the Java Virtual Machine. Java provides mechanisms for a program to safely execute unknown applets without fear of compromising the security of the local machine. Using these same mechanisms, it is possible for a locally executing program to send program fragments to a remote machine, and have the remote machine execute the fragments by incorporating them into a remotely running Java program. The remotely running program can thus be updated with new versions of existing capabilities, or provided with new capabilities not originally configured into the system.
The camera driver provides the basic interface to the camera. It allows higher-level programs to send commands to the camera and provides a simple interface to receive images. The driver communicates with the camera over the NS486 parallel port.
The driver presents three basic functions to the higher-level code as an API:
|
|
These functions are implemented in C as Java native methods. Function qc_initalize() resets the camera to a known state with all settings set to default values. It also terminates any camera operation already in progress.
The qc_send_command() function sends a command and argument to the camera. Each command to the QuickCam consists of two bytes - a command and an argument to the command. The camera echos the command and argument back to the driver, in order to verify command reception.
The function qc_take_picture() obtains an image frame from the camera. It has 3 arguments: a buffer in which to place the image pixels; a bitmask representing the camera mode (specifying color scheme and decimation level); and the length of the expected image in bytes. Presumably, the program has already sent the other parameters to the camera via qc_send_command(). Note that the pixels returned in the buffer will be in the Java color scheme, which is 32 bits, and not the QuickCam's 24-bit color scheme. The buffer needs to be big enough to reflect this space requirement.
JavaCam provides two distinct ways to access the camera at the Java level: the applet method and the servlet method.
The applet approach works as shown
in
Figure 1
.
The
applet method starts by running an HTTP server on the NS486.
When a WWW browser such as Netscape issues a GET
command to the HTTP server, it
hands back a page containing a Java applet.
This Java applet, called
the QuickCamApplet, communicates
back across the network and
contacts another server running on the NS486, the
QuickCamServer.
The QuickCamApplet
sends parameters to the QuickCamServer, and then
makes a request for an image.
The QuickCamServer contains native methods
that call the JN camera driver routines. The native
methods fill in the image
buffer and hand the buffer back to the
QuickCamServer. The server then sends
the data over the network back to the
QuickCamApplet, to be
displayed inside the
user's browser.
The servlet approach works as shown in Figure 2 . In servlet mode, the ClassLoaderServer on the NS486 listens on a particular Internet port for requests to load servlets to control the camera. A servlet is akin to an applet; it is a Java class which implements a specific Java interface. However, like an applet, it is not an entire program. It requires another program to instantiate and fill out the missing parts of its expected run-time environment. An applet is downloaded from a server to a local application in order to extend the functionality of that application. A servlet is sent from a local application to a server in order to extend the functionality of that server.
In order to control the QuickCam on the NS486, a class must implement the CameraControl interface. A CameraControl servlet, if authorized, is instantiated and given a reference to a Camera object, which provides access to the QuickCam JN device driver. The servlet is also given a socket providing a connection back to the client which provided the servlet. Once instantiated and started, the CameraControl servlet can perform any desired processing of camera data before sending data back to the client. Like an applet, the servlet runs within a SecurityManager class, which checks its operations to make sure that it does not misbehave by trying to access the file system, open arbitrary network connections, and the like.
The following Java classes thus exist supporting the QuickCam:
There are numerous things to be done.
We are now beginning to embellish the basic JavaCam functionality by adding floor-control, investigating camera and network performance enhancements, and are evaluating the portability of the system by porting it to a second embedded CPU architecture, the National CR32.
We expect to completely replace the current garbage collector with the our new garbage collector. This effort will also result in the ability to readily replace JavaCam garbage collectors, thus facilitating research in real-time garbage collection.
Our system is based on an early JVM, JDK 1.0.1. This version of the JVM cannot unload classes. Classes (such as servlets) that are downloaded to the NS486 are not stored in the Java heap but are placed in normal system memory which is never freed. We anticipate being able to unload classes in the near future.
We expect to perform additional work to determine minimum memory requirements of embedded-Java environments. We are extremely interested in being able to specify via a `sysgen' just the needed JavaCam software components required to support a particular Java application or application suite. We are also interested in investigating issues associated with real-time embedded system subsets of Java.
With respect to the camera application, JavaCam servlets could implement novel compression algorithms, return only selected portions of the image, return images periodically, perform local filtering, or collect data on the images and never return the actual image data. One extreme example would be a servlet that only sends a message back to its originating host when the image changes, indicating motion.
Because we have implemented our own embedded operating system, custom designed to run Java, we are now in a position to investigate Java performance, Java soft-real-time functionality, real-time Java garbage collectors, and ways to decrease the size of Java applications. Work such as this will enable Java to become an appropriate language for programming some embedded systems [Nilsen |Nilsen 96] .
