Java and the Train System

Interfacing the Existing Train System to Java

It would be possible to interface the existing train system, written in Interactive-C/MC68HC11 assembler to a Java application running in the host-computer (pooh or rabbit).

Write some software for the HandyBoard to allow it to receive (down the RS232 line) routing-table information and other messages of the Chootocol, and also to transmit messages about system state.
Write a Java application that can send Chootocol messages to the Handy Board, and receive status messages in an extended Chootocol.

Using Java as an Implementation Language

It strikes me that the most useful view of an embedded system composed of a lot of rather weedy processors such as the MC68HC11 is that one has a host machine, which is fully-Java-competent (that is it runs a fully-implemented JVM). Within this host machine, each processor appears as an instance of a class peculiar to that processor. For example, for the existing choo system, we might have a class HandyBoard, for which a constructor might take a Runnable object as argument. Thus

    HandyBoard(r1)

is a Java object that in effect loads the run method of a Runnable object r1 into a Handy Board Clearly, one could only have as many instances of the HandyBoard class as one had Handy Boards. This has the nice property that we get a kind of simulator for free. We could have a PseudoHandyBoard class for which the call

    PseudoHandyBoard(r1)

simply makes a Thread which runs r1. Now, typically for crisply exact real-time performance, much the behaviour of the HandyBoard is characterised by interrupt-routines. To deal with this we'd have another constructor:

    HandyBoard(r1,runnables)

where the array of runnables (or some other structure) is in effect an array of interrupt routines.

How might we implement this

On the face of it, implementing HandyBoard objects might seem to need a non-standard JVM. No doubt somebody could hack such a capability into Eliot's JVM. But portability would suffer. A different approach might be as follows:

Build a method extractor This utility converts a .class file for a class which implements Runnable into one which a code method has been added. That is to say, if r is a member of the modified class, then r.code("fred(I)F") evaluates to a string which is the JVM code for the method "fred" of the original class whose declaration would be float fred(int x).
It would also be necessary to make other attributes of the class visible in a similar manner.
Build a JVM code analyser: JVM code is strongly constrained, sufficiently so that it's quite easy to regard a code-sequence as a statement in a language in which most operators are explicitly typed. The major snag, from the point of view of micro-controllers, is that there are no 8- or 16-bit integer-types (except as array components). Everything on the stack or in local variables is at least 32 bits. Is it possible to ascribe narrower types to local variables and sub-expressions by diligently analysing JVM code?
Build a code-generator for the target architecture: Most of the improvement in performance over an interpreted JVM could be obtained by exploiting narrow types, if the analyser can deliver these.
It should be noted that instance-variables of the HandyBoard class become globals in these circumstances (for a given Handy Board is an instance of the class.
Build or adapt the necessary host-client interface