Embedding Java doesn’t always equate mobiles. Nor does it necessarily mean stuffing it into a rover on Mars. Introducing new possibilities is sometimes just a question of putting it on a small card hooked up to your printer.
Axis, a well-known creator of print servers, network cameras etc has done just this. They took one of their print servers and added Java for a big time printer manufacturer in Japan. How did they do it? And what did they learn? I teamed up with three of the people – Jens Johansson, Kristofer Johansson and Stefan Andersson – behind this Java enabled print server to get more of the gory details.
The Start
The project started around four years ago with a prototype after some seven months. The release onto the market was roughly one and half years ago. The first step, however, was to assess the feasibility of it. Could they perform to their customer’s demands? What type of handling of Java classes should they use just in time (JIT) or ahead of time (AOT) compiling? Even the choice of hardware wasn’t given from the start. Should they use third party chip dedicated to running Java or do it themselves? The former would have meant a bus and shuffling data in between the main chip and the Java chip.
Not interesting. Ten man-years later, here’s what they
ended up with.
A schematic view of the print server and its different parts. The functionality is extended by uploading Java classes as a normal jar file.
The Box
First off they had to decide which road to travel – base it on a hardor software? Roll their own or go third part?
Buying an ASIC block doing the Java and integrating it on their chip architecture would have been very expensive and wouldn’t have resulted in a cost effective system. Buying a third-party chip? That would have meant hooking it up on the system bus and making the whole system rather complex. In the end they settled on a software solution and doing it themselves.
Basically they took the Axis ETRAX 100LX chip, added more memory and used software to implement the Java support. The ETRAX 100LX systemon-chip is a 32 bit, 100 MHz RISC CPU. The design then uses the Java 2 Platform, Micro Edition (J2ME) with the CDC and Foundation profiles. This resembles the abilities of a PDA or a set top box on your TV.
The Java foundation classes reside in a separate memory and are loaded by the print server before any uploaded jar files from the file system on the board are run. The memory is divided into a 16 MB file system and 16 MB for all the executable code including the Java Foundation classes. Add to this a 64 MB RAM that houses the system, of which approximately 13 MB is used for Java. This is considerably more than the standard print server that typically has 4 MB of memory.
The operating system is Axis’ own proprietary RTOS for embedded systems. The unit consumes a sparing 0.3 W.Add to this a USB port and you get a pretty good idea of this competent little circuit board.
You change the function of the print server by uploading an ordinary Java jarfile. These compiled classes are then run on the print server and have access to the various ports and, of course, to its printer.
There is even a remote call possibility (RMI) to query the server for its status et al.
The result
Even though there were apprehensions at the start of the project about the performance, the result speaks for itself. CaffeineMark 3.0 is a Java benchmark. It is used to measure the speed of a Java Virtual Machine (JVM) running on a particular hardware platform. The test is calibrated to return a score of 100 running on a Pentium 133 MHz using Windows 95 and Sun’s JDK 1.1 interpreter. Even though this feels like an old PC, it does give you a good reference point for embedded solutions.
Axis’ print server landed on an impressive 60. This result is even more to write home about since the entire floating-point math is done in software.
The Lessons Learned
As with most projects, there were problems to overcome. In this case the floating-point library proved to contain bugs. The TCP stacks used at Axis were different compared to the Sun version. There were compiler issues going from Java to C. As coup de grace they needed the Java logo and that meant going through a grueling TCK test (Technology Compatibility Kit). This is a suite of tests, tools, etc that provide a way of testing an implementation for compliance with a Java.
”This has been among the most complex printer projects we’ve done ”, says Jens Johansson with a weary smile. However, the Java portion worked without any major problems as soon as the foundation classes were in order. ”For one and half year we haven’t had any Java related bugs”, explained the tech lead Kristofer Johansson.
They chose AOT compiling to implement the foundation classes, but this meant a large code base and it took time to implement. Hindsight is one of the best visual aids: might it have been better to use JIT instead?
Possibilities
So techno stuff is all just fine, but what can we do with this Java enabled print server? Ever forgot about an important printout that shouldn’t lie around? Well, why not a simply hook up a card reader? Once you arrive at the printer you swipe your card and, presto, your pulp stack pops out. Authentication and authorization could be done against an LDAP server.
Still too simple. Why not implement a distributed load-balancing scheme for printers – next available printer pulls a job from a print queue somewhere. Need more power? Just hook up another printer to the network. Could I combine the print server with a web camera and motion detection? Add something to sample the temperature and we get surveillance, fire detection and printing to go.
Puleeze Axis, can I get a couple of print servers to try out?
Originally published in JayView.
Tags: java
Tumblelight 
Leave a Reply