Java-Based Solutions

Over the past 10 years there has been a move to make software, particularly application
layer software (sometimes called platform operating software), easier to write.
Java is one example. Originally introduced in 1995 as interoperative middleware for
set-top boxes, Java compiles high-level code into Java byte codes.
Developers write a version of the Java Virtual Machine in their own hardware’s
instruction set to run the byte codes. The advantage is that this makes the code fairly
portable both between devices and applications. The disadvantage is that you do not
have much backward compatibility and you can find yourself using rather more code
(memory space and processor bandwidth) than you had originally intended. You
would normally run Java on top of an existing real-time operating system.

Over the past 3 to 5 years, microcontroller architectures have been introduced that
are specifically designed to support Java byte code execution. However, performance
still tends to be hard to achieve within a small processor and memory footprint. ARM
(Advanced RISC Machines) has a product known as ARM926EJ-S that supports accelerated
Java execution. The byte code processing runs alongside the 32-bit (and reduced
16-bit) instruction set, which means the hardware resources are multiplexed. However,
there is insufficient code memory space to directly execute all the Java byte code
instructions, so only 134 out of 201 instructions are executed in hardware; the remainder
are emulated. The decision then has to be made as to which byte codes should be
chosen for direct execution.
ARC, Infineon, and Hitachi have similar Java-friendly microcontroller architectures,
but essentially the trade-off is always cost and power budget against speed of execution.
Returning to our seven-layer model (see Figure 10.1), we can say that platform software
in the application layer is flexible but unpredictable in terms of execution delay
and execution delay variability. As we move down the protocol stack, software performance
has to become faster and more predictable, and it becomes increasingly attractive
to use hardware to meet this performance requirement.
This continues to be a challenge for Java-based software in embedded applications.
The portable byte code instruction set can be implemented in hardware, but this
requires processor bandwidth, memory bandwidth, and power�"usually rather more
than an embedded processor has available. The byte code instruction set can be emulated,
but this absorbs memory and is rather inefficient and slow. The answer is to integrate
a Java Virtual Machine onto a dedicated processor or coprocessor, but this again
absorbs precious space and power resources. Limiting the Java classes installed helps
but results in less application flexibility (and a rather inconsistent user experience
when less-often-called Java instructions are used).

Presently efforts are being made to implement a complete Java machine on a smart
card supporting J2SE (Java2 Standard Edition) shoehorned into 55 kb on an 8-bit
microcontroller. Future 16- and 32-bit smart card microcontroller architectures will
make Java-based smart cards easier to implement.
So with Java we are effectively paying a price (cost, processor overhead, and memory/
code space) for the privilege of device-to-device and application-to-application
portability. We have to convince ourselves that the added value conferred exceeds the
added cost. Microsoft offers us similar trade-offs, but here the trade-off tends to be
backward compatibility (a privilege that implies additional code and memory space).
Both Java and Microsoft claim to be able to support soft and hard real-time operation,
but in practice, exposure to interrupts (a prerequisite for flexibility) destroys
determinism, and it is hard to deliver consistent predictable response times because of
the wide dynamic range of the applications supported. This is why you often still find
a standalone RTOS looking after critical real-time housekeeping jobs like protocol stack
execution.