Re: [Embedlets-dev] Re: JAPL versus Embedlet integration....

[Brill P. <bri...@ro...>]

> >Maybe I am misinterpreting what JAPL does. If all it provides is a
> >thin generalization layer for specific classes of peripherals,
> >then we may need a Device Driver level of code layered on top of that.
>
> The understanding of JAPL peripherals that I have been working under is
that
> they are generic, standardized interfaces for any kind of peripheral I/O
> circuits from simple I/O ports through medium complexity devices like
UARTs and
> up to highly sophisticated I/O systems like a RobotScanner.

See my message (March 29, 2003 1:36 AM) with the subject "Re:
[Embedlets-dev] Re: JAPL part of specification".

I have attached the current API docs for JAPL (not including the docs for
the platform-tini, which is separate).

the layout your interested in is:
org.japl.peripheral <= contains the generic interfaces
org.japl.peripheral.<name> <= contains concrete implementations of some
devices (mostly I2C).
The device drivers are platform independant, and will run on any platform
implementation (e.g. the platform-tini impl).

>  My working definition of what a device driver means in the context of
> Embedlets is that it is the piece of software that is responsible for
doing the
> impedance matching between the I/O level semantics of the JAPL peripheral
and
> the application level semantics of the Embedlet based application.
>
> For example, if a cannon were attached to bit 3 of a JAPL I/O port, then
an
> event like "fire forward cannon" from the FireControl Embedlet would
eventually
> get translated into something like JaplPort.setBit(3, true);

Thats what I'm asking about ;) I think we're all on the same wavelength,
jhust struggeling to understand the different APIs.


- Brill Pappin