RE: [Embedlets-dev] Re: JAPL part of specification

[James C. <ca...@vi...>]

Hi all,

My recommendation is that Teds idea of JAPL actually needs to be broken
into 2 layes, APT, JAPL where the APT layer is a completely abstract
interface of Abstract peripherals implemented by the platform and
created by the APT peripheral factory, ie the APT is a wrapper for the
proprietry libries into a common abstract peripheral toolkit. 

JAPL then is a shared device driver library that is built ontop of the
APT and so now the JAPL library is platform independent so all japl
devices can run on any platform that supports the APT framework.

I think the embedlet container implementation should provide an APT
PeripherFactory which is used by embedlets when creating JAPL components
which are implemented by APT components. 

If you look at the docs in the latest uVMDK,
http://www.muvium.com/uVMDK/uVMDK.htm, and the example shown there for
the SPIMaster and EEPROM you can see where I am going with this. 


James Caska
www.muvium.com
uVM - 'Java Bred for Embedded'



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Brill Pappin
Sent: Sunday, 30 March 2003 5:53 PM
To: emb...@li...
Subject: Re: [Embedlets-dev] Re: JAPL part of specification


Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
_______________________________________________


> >For instance... for a starter, I was working on the tini 8 bit 
> >port... a nice easy one to do... Anyway, I can set it to anything I 
> >like, but its meaningless unless connected to the outside somewhere.
> >
> >So... what I need to understand is how Outpost would be setting and
getting
> >attributes of a peripheral?
>
> It does appear that JAPL and its relationship with Embedlets needs to 
> be discussed more.  I am sure that Andrzej will have some more 
> thoughts on
this
> subject and I would also like to hear what Chris, Gregg and James have

> to
say
> about it too.

I'm thinking that they shouldn't have *any* relationship besides one
being able to talk to the other. The idea being the separation of the
two different APIs and their respective domains...

what I intuitively expect, is that I can instantiate a peripheral in an
embedlet, similar to the way I might for a servlet and use that
interface to get/set attributes of the peripheral, including finding out
what JAPL interface it is talking to/with (Port, Temperature etc).

You should be also to ask the Outpost container "what to you have" and
it should be able to tell you (this is outpost implementation, not
embedlet or JAPL)... you could then ask each embedlet what type of
interface it was controlling... however this would be implementation
specific to something like the wiring tool. Anyway, the embedlet would
tell your wiring tool that it controlled a Port... wiring already knows
what a port is because you have the API already on your system, or the
properties are coded etc. You would then make an embedlet request asking
the port to set it's state to "n". Also, the Port peripheral might be
able to generate events or interrupts (not on the TINI unfortunately,
but on other chips maybe) so you might tell the Port to report any
changes... it would create its own peripheral event listener, and if it
thought it should sent the embedlet event, it would then generate it
(i.e. as in temperature moving outside an alarm window, the peripheral
would get an event, but doesn't *have* to send it out to outpost)... It
could also report changes made by other application, so two remote
clients get change events from outpost when one or the other makes a
change (with the added benefit of confirming a change, if its allowed to
report and event like that back to the caller).

IMO - this is the *only* way to do it if you want to maintain the
separation (though I'm open to alternative ideas). Of course, you could
also integrate the JAPL into the embedlet api, but then you loose the
JAPL and it *becomes* the embedlet api... and I'm not willing to do
that, although your welcome to the code ;) my JAPL to Outpost
implementation is "Piccadilly" (some of you might understand the
reference) and that is what I'm trying to do with it.

I think I'm just missing how the IO in the embedlet world is done... I
haven't had a lot of time lately, but am still plugging away....

- Brill Pappin



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer