> The JAPL devices are abstract peripherals, not device drivers. Lets set
aside
> Robocode
> for the moment and discuss a JAPL UART because I think it is more typical
of
> what most JAPL devices will look like. A normal UART device driver can
a)
> configure the UART by placing data into its internal registers, b) query
the
> state of the UART by looking at its internal registers and c) the UART
can
> asynchronously notify its device driver that it needs to be serviced by
> asserting the interrupt line.
I've taken a slightly different approach to things like UARTS etc. in that
they are TransportLinks and not peripherals in them selves. the
configuration of a uart is really implementation dependant anyway.
The point being that a peripheral would be something that the uart was
attached to... using the org.japl.transport package allows the actual link
to a peripheral to be transparent and changeable... for instance (though not
implemented yet) the I2C/1-Wire/SPI/Serial device or even a specific
protocol like SLIP could talk over any TransportLink to any other device.
The way it works, is that the Links have a standard interface and are
wrapped in a Pipe, in the case of I2C it would be: I2CTransportPipe =>
I2CTransportLink => I2CPeripheral but it could be I2CTransportPipe =>
UartTransportLink => UartTransportLink => I2CTransportPipe.
the concept isn't fully flushed out, and because I haven't had much time
lately (and we just did a cleanup of our CVS tree) some things are not
implemented, or are partial... and a *lot* of debugging needs to happen.
- Brill
|