embedlets-developer — Outpost Embedlet container developer list

Re: [Embedlets-dev] Re: JAPL Events

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

> >The JAPL devices are abstract peripherals, not device drivers.
>
> The aproach I am taking is that JAPL are drivers and the APT is the
> Abstract Peripherals

Don't get me started on this again! ;)

JAPL = Java Abstract Peripheral Library
I'd love to take a look at your APT though... I wondering if we can
incorporate all those interfaces you (may) have written into the JAPL.
If your interested, take a look at those javadocs I sent to the list... the
contracts would go in "org.japl.peripheral" and there are a few in there
already.

Most of the JAPL contains drivers as well as the JAPL contracts (I found I
had to do that to maintain a clean library) so Cork has become the platform
implementation for a particular processor.

BTW - If any of you TINI guru's out there want to give me a hand with the
TINI impl. I'd be very glad for the help.
My TINI experience is limited... I'm also finding the TINI not well thought
out when it comes to simple things like control of its port, you can set it,
and get it, but that's it! no direction settings, no polarity settings
etc... now likely you could skip the TINI port interface, ad use native
calls, but I'm not familiar enough yet to try that.

Anyway, I've written the OneWireTransportLink for the Tini, but haven't be
able to test it yet.

- Brill Pappin

Re: [Embedlets-dev] Re: JAPL Events

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

> >Let me repeat that:  though the Embedlet can have a reference to the
> JAPL
> >device, the JAPL device should NOT have a reference to an Embedlet!
>
> An embedlet should be able to register itself as a listener to a JAPL
> event generator

Yes, but the API's don't have to intermingle here... it would be fairly easy
to create an embedlet event proxy that implemented the JAPL EventListener
and/or EventGenerator... so it's really implementation dependant, and not
part of ether API.

- Brill Pappin

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

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

> > The JAPL devices are abstract peripherals, not device drivers.
>
> Whatever....I'm using the term interchangeably in my posts.  I see the
> abstract peripheral API's as being just a generic version of a specific
> device driver.

The distinction is pretty blurry ;) I tend to think of the peripherals as
contracts to drivers if I have to separate them contextually, so a
peripheral could look the same, but be implemented in several different way
in the "driver" code.

- Brill Pappin

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

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

> I thought that JAPL was going to be a separate specification, since it
> would/might have applicability outside of an Embedlet container?

So did I; I still do ;)

> > So... what I need to understand is how Outpost would be setting and
getting
> > attributes of a peripheral?
>
> An Embedlet would have a reference to the JAPL device and would use
whatever
> API the JAPL device exposed to set/get any attributes the device had
exposed.

Thats exactly what I though should happen, but when I went to take a look at
the Embedlet to extend it, there didn't seem to be any way for IO to happen.

[...]

> > What I don't understand is how the embeled talks to the JAPL device.
> > What is looked like, extending Embedlet is that the embedlet receives
events
> > from the system... now I assumed that I would do something different
depending
> > on the event code.
>
> Assuming that the JAPL stuff is intended to be independent of the Embedlet
> container (something we talked about a long time ago), here is the way I
> think you should consider linking the two:
>
> 1) Create your JAPL drivers with an exposed API.  The JAPL device should
NOT
> have a reference to any Embedlets, nor be dependent on ANYTHING in the
> embedlet spec (eg. no imports of org.embedlet or org.outpost packages).

Ok, good so far... done.

[...]

> 1) JAPL device gets an interrupt.
> 2) JAPL device does a callback into the JAPL "Proxy" Wrapper.
> 3) The wrapper takes the interrupt data, puts in in an Embedlet Event and
> sends it (note: it does not know who the consumers are going to be).
> 4) An Embedlet (registered as a consumer for that particular event type)
> receives the event and then does something with it (possibly issuing JAPL
API
> calls against the originating device, setting/getting attributes).

[...]

Ok, so the IO does happen with events... How does the external caller
request data from JAPL device? I assume that in that case the external
"listener" would just have a proxy "event generator" that sent events out
into the system... and the "JAPL control embedlet" would be registered as a
listener?

> Make sense?  Do I need to write an example to show you how this is
intended
> to be implemented?

Well, I'll eventually figure it out anyway (key factor is my time is taken
with money making at the moment) ;) but I don't think a very simple example
could go wrong especially as outside parties begin to take interest. Anyway,
I've been using our Outhouse impl for the moment.

- Brill Pappin

RE: [Embedlets-dev] Re: JAPL Events

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

Yes, but the catch 22 of this is that if you make JAPL dependent on
embedlets then the enourmous effort required to build the JAPL library,
which is actually an absolutely massive library, dependent on the
embedlet event scheme. I think it makes sense for embedlets to talk to
other embedlets in an embedlets container but why constrain everything
else to use the embedlets framework? No JAPL has a very valuable life of
its' own independent of the embedlets container actually so I don't
agree that JAPL drivers mandatorially use the embedlet container event
handler.

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Andrzej Jan Taramina
Sent: Monday, 31 March 2003 3:14 AM
To: emb...@li...
Subject: [Embedlets-dev] Re: JAPL Events


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

James says:

> An embedlet should be able to register itself as a listener to a JAPL 
> event generator

I strongly disagree.  This couples JAPL and Embedlets too much and
bypasses 
the Embedlet Event scheduling and control mechanisms.  Bad idea.  If you
are 
doing that, then why bother with a container?  Just write straight Java
code 
and be done with it.

Better bet is to create a JAPL wrapper class that registers itself to a
JAPL 
event generator and then "translates" JAPL events into Embedlet Events
which 
are sent further upstream.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com



-------------------------------------------------------
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

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

[Gregg G. W. <gr...@sk...>]

>> I would also like to hear what Chris, Gregg and James have to say
>> about it too.
>
>Me too.  Where are ya guys?  You were hot to trot so I filled the CVS 
>repository and then....silence!  

Unfortunately, I am having to deal with some other things right now to make 
cash flow, and will be able to get back to this shortly I hope!

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-dev] Re: JAPL part of specification

[Andrzej J. T. <an...@ch...>]

Brill says:

> '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...

Exactly my thinking.  Which leads to the need for a "mediation" layer, like 
the JAPL Wrapper class that I have proposed as a "best practice" programming 
paradigm when using both Embedlets and JAPL together.  It allows for clean 
separation of the two layers.

> 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).

Yup.....Embedlets would instantiate the JAPL stuff in their initialize() or 
start() lifecycle methods and keep a reference to the JAPL peripheral (if 
they needed to) so they could get/set attributes of the peripheral as needed. 
However, the JAPL peripheral would not know anything about Embedlets or even 
if it is running in a Container or not.  Maximum reuse of JAPL code that way.

> 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)... 

It does that already.  You can get some Container level info in the current 
Outpost API (version, etc.).

> 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. 

It would be based on the XML Config files and maybe properties at runtime.  I 
don't want to put much if any dynamic config information into the runtime 
system since that will be a strain on less capable platforms.  Many Embedlet 
containers will be "pre-compiled" with their components to fit on smaller 
platforms like TINI or uVM.  Don't count on having a runtime dynamic 
interface for wiring.  Not a big deal since the wiring tool is a "build time" 
activity and would have access to the config information (out of the XML 
files) in other ways.

> 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).

Exactly my thinking on what the JAPL Wrapper class should do!

> 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 ;) 

I agree.  They need to be kept decoupled.

> 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'm feeling dense....what is the reference to?

> 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....

IO to peripherals would be through the JAPL API's (and using JAPL Wrappers 
where needed for async/interrupt driven stuff).  Other IO would be done 
through Container Services (events, logging, persistence, etc.) or through 
appropriate Adapters that link to the outside world.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] Re: JAPL Events

[Andrzej J. T. <an...@ch...>]

James says:

> An embedlet should be able to register itself as a listener to a JAPL
> event generator

I strongly disagree.  This couples JAPL and Embedlets too much and bypasses 
the Embedlet Event scheduling and control mechanisms.  Bad idea.  If you are 
doing that, then why bother with a container?  Just write straight Java code 
and be done with it.

Better bet is to create a JAPL wrapper class that registers itself to a JAPL 
event generator and then "translates" JAPL events into Embedlet Events which 
are sent further upstream.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] Re: JAPL part of specification

[Andrzej J. T. <an...@ch...>]

Ted says

> 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

Funny you should say that. ;-)

> I would also like to hear what Chris, Gregg and James have to say
> about it too.

Me too.  Where are ya guys?  You were hot to trot so I filled the CVS 
repository and then....silence!  

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

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

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

>I thought that JAPL was going to be a separate specification, since it 
>would/might have applicability outside of an Embedlet container?

With my recommendation, the APT PeripheralFactory upon which everything
sits is provided by the Embedlet Container implementation but it can
also be provided elsewhere - for example the UVMRunnable provides it
already. Which means the JAPL library can be used outside of the
Embedlet container also.


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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Andrzej Jan Taramina
Sent: Monday, 31 March 2003 1:07 AM
To: emb...@li...
Subject: [Embedlets-dev] Re: JAPL part of specification


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

Brill asks:

I thought that JAPL was going to be a separate specification, since it 
would/might have applicability outside of an Embedlet container?

> So... what I need to understand is how Outpost would be setting and 
> getting attributes of a peripheral?

An Embedlet would have a reference to the JAPL device and would use
whatever 
API the JAPL device exposed to set/get any attributes the device had
exposed.

> > Can you give a bit more information about the idea behind these Type

> > IDs?

Embedlet Event Types are just a string, which is tokens separated by
periods. 
Something like my.event.id.  or device.id.eventtype.  The first token
should 
not be emb or outpost, and don't use *'s in the type (those are used for

pattern matching), other than that, no real restrictions.

> I started Piccadilly (what I'm calling the Outpost/JAPL combo) by 
> extending Embedlet... the methods are fairly easy to understand.

You should not need to (and I feel shouldn't anyway) extend Embedlet to 
support JAPL devices.  See below.

> What I don't understand is how the embeled talks to the JAPL device. 
> What is looked like, extending Embedlet is that the embedlet receives 
> events from the system... now I assumed that I would do something 
> different depending on the event code.

Assuming that the JAPL stuff is intended to be independent of the
Embedlet 
container (something we talked about a long time ago), here is the way I

think you should consider linking the two:

1) Create your JAPL drivers with an exposed API.  The JAPL device should
NOT 
have a reference to any Embedlets, nor be dependent on ANYTHING in the 
embedlet spec (eg. no imports of org.embedlet or org.outpost packages).

2) Create an Embedlet (application logic that wishes to use a JAPL
device) 
that receives Embedlet Events that will originate from a JAPL device
somehow. 
The Embedlet can have a reference to the JAPL device if it needs it (or
it 
can be passed in as part of the Embedlet Event it receives) so that it
can 
make calls against the exposed API of the JAPL device.

3) Create a "proxy" wrapper for the JAPL driver that extends 
org.embedlet.EventProducer and which takes JAPL events (interrupts) and
then 
creates/sends an appropriate Embedlet Event.  Note that this wrapper
does NOT 
extend Embedlet (it doesn't have to), just EventProducer and that the
JAPL 
driver can have a reference to the wrapper (if needed) for interrupt
driver 
events (in which case the wrapper should implement a callback interface 
defined as part of the JAPL device API for such callbacks). The JAPL
wrapper 
should NOT have a reference to any Embedlets.  All this wrapper does is 
convert internal JAPL information into an Embedlet Event, acting as a 
"bridge" between the two worlds.

A polling scenario doesn't need the wrapper (an Embedlet would use the
Timer 
Service to poll the JAPL device), so let's look at an interrupt driven
JAPL 
device.  Here is what the flow would look like:

1) JAPL device gets an interrupt.
2) JAPL device does a callback into the JAPL "Proxy" Wrapper.
3) The wrapper takes the interrupt data, puts in in an Embedlet Event
and 
sends it (note: it does not know who the consumers are going to be).
4) An Embedlet (registered as a consumer for that particular event type)

receives the event and then does something with it (possibly issuing
JAPL API 
calls against the originating device, setting/getting attributes).

This approach follows best practices (per my earlier email), and is
preferred 
for the following reasons:

1) Coupling between the Embedlet and JAPL layers is reduced (and kept
uni- directional, from Embedlet to JAPL only).

2) The use of a wrapper class means JAPL code can be used without change

outside of the Embedlet Container environment (a good thing).

Make sense?  Do I need to write an example to show you how this is
intended 
to be implemented?

Anyone else out there?  Gregg?  Chris?  You guys got any opinions?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com



-------------------------------------------------------
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

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

RE: [Embedlets-dev] Re: JAPL Events

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

>The JAPL devices are abstract peripherals, not device drivers. 

The aproach I am taking is that JAPL are drivers and the APT is the
Abstract Peripherals

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Saturday, 29 March 2003 3:58 PM
To: emb...@li...
Subject: Re: [Embedlets-dev] Re: JAPL Events


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

Andrzej,

>If you think about the robocode application, the interrupts should be 
>handled
by a JAPL device driver, which in this case is a robocode "virtual"
device.
>[...]
And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

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.

The Architecture document gives an Embedlet 2/3 of the capabilities it
needs to serve as a JAPL UART device driver because it allows the
Embedlet to have a direct reference to the JAPL UART and so enables it
to do 'a' and 'b' above. 
As for the UART interrupt, in all the conventional low level device
drivers I have written, the interrupt is always channeled directly into
the device driver that is also responsible for doing 'a' and 'b' for any
given device and it is always a one-to-one bidirectional binding.  No
other piece of code besides the peripheral's device driver should be
interested in the interrupt.

But you are saying that Embedlets should not be used as device drivers
either (see below).



>And that robocode JAPL driver should convert the interrupts
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

Again, a JAPL peripheral is just a peripheral, not a device driver.
Besides this, the JAPL peripheral can't convert its interrupts into
Embedlet events or any other specific system's events because the JAPL
is a generalized, system neutral technology.



>Therein lies the fallacy of your approach, Ted.  This is not a 
>symmetric
situation.  A one way reference from Embedlet to JAPL is fine, and in 
fact, was intended to be used all along.  It's the reverse reference
that 
is a bad idea since it breaks encapsulation and couples things too 
tightly.
>
>A calling program can depend on a subroutine/method.  But a
subroutine/method should not depend on the caller.  Async relationship!

Same with Embedlets versus JAPL drivers.

If an Embedlet is being used as a device driver for a JAPL device then I
would say that device drivers commonly have bidirectional references to
the devices they are controlling.  My current thinking is that routing a
peripheral's interrupt only to the device driver that is directly
responsible for it maintains complete encapsulation but allowing this
interrupt to be arbitrarily routed to other pieces of software in the
system breaks it.

What I hear you saying, though, is that Embedlets should not be used as
JAPL device drivers and I can certainly go along with this philosophy if
Embedlets are blocked from having direct references to JAPL peripherals.
If an Embedlet is being constrained as only operating as a high level
piece of code then how can it be ok to give it a direct reference to a
low level peripheral like a UART?  

Assuming that a JAPL peripheral can not be its own device driver and if
Embedlets are not permitted to be device drivers, then we still need
some kind of a device driver that is part of the Embedlet framework that
can do the
following:

1) Hold direct references to JAPL peripherals.

2) Accept interrupt events from these peripherals.

3) Convert Embedlet events into method calls on the peripheral.

4) Convert the peripheral's interrupt events into Embedlet events.

The current Adapter might be suitable for this purpose and if not the
Adapter then perhaps an Embedlet Container DeviceDriver?


Anyway, I am going to hold off doing more work in this area until we get
this JAPL issue resolved.  Actually I have been hitting JGraph fairly
hard during the past week in preparation for beginning work on the
Wiring Tool and so I have plenty to keep me busy. ;-)


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


-------------------------------------------------------
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

RE: [Embedlets-dev] Re: JAPL Events

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

>Let me repeat that:  though the Embedlet can have a reference to the
JAPL 
>device, the JAPL device should NOT have a reference to an Embedlet!

An embedlet should be able to register itself as a listener to a JAPL
event generator


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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Andrzej Jan Taramina
Sent: Saturday, 29 March 2003 4:56 AM
To: emb...@li...
Cc: tk...@ya...
Subject: [Embedlets-dev] Re: JAPL Events


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

Ted:

Sorry 'bout the delay in replying.  This new contract is keeping me 
pretty busy and I've been too fried in the evenings to do much else.  
Settling in now, so hopefully I can do some embedlet work in my spare 
time.

> In the case of RoboCode, the model is definitely interrupt driven.  In

> addition to this, the RoboCode event objects contain rich semantics 
> that need to be dealt with.  For example, the 
> robocode.ScannedRobotEvent contains these methods:
> 
>     double getBearing()
>     double getBearingRadians()
>     double getDistance()
>     double getEnergy()
>     double getHeading()
>     double getHeadingRadians()
>     double getLife()
>     String getName()

Each interrupt event should be mapped onto an Embedlet event.  Note that

using the User Data area of the Embedlet Event you can just append the 
robocode event, and not have to copy any data around.

> Before I posted my initial question I thought about this one a great 
> deal and what I came up with is that this would require another type 
> of software entity to be added to the Embedlet framework besides a 
> Adapters, Transports and Embedlet.  Before going this route I thought 
> that we should discuss it and probably at least try to solve the
problem another way.

Actually....it doesn't!  If you think about the robocode application,
the 
interrupts should be handled by a JAPL device driver, which in this case

is a robocode "virtual" device.

> Apart from this, it appears that the JAPL peripherals are well suited 
> to use method calls for commands being sent to them and simple 
> callbacks for any interrupts/events that they might generate.

Exactly.  And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

> I am all for going with whatever makes sense here and my thinking so 
> far on this topic is as follows.  The Architecture document already 
> shows Embedlets having direct references to JAPL objects and so far my

> RoboCode experiments confirm that this is a good idea.  If an Embedlet

> has a reference to a JAPL peripheral then it is already closely 
> coupled with it and in my opinion this is not a problem because the 
> JAPL's abstract nature already provides the required level of
decoupling.

That is incorrect Ted!  Just because an Embedlet has a reference to a 
JAPL device does NOT imply that the reverse is OK.  Higher order 
components can have references to lower order (or more detailed, closer 
to the iron) ones.  However, the point of using an Event-driven model is

to avoid the reverse, where more detailed components should not have to 
know about the consumers of the events.

This is very analagous to good programming practice where a subroutine
or 
method should typically have NO knowledge of the caller.  Breaking this 
rule is what leads to tight coupling and inflexible application code.

Let me repeat that:  though the Embedlet can have a reference to the
JAPL 
device, the JAPL device should NOT have a reference to an Embedlet!

Let me put this another way:  if I can figure out a way to prevent JAPL 
devices from getting Embedlet references I will do so in the Outpost 
implementation. ;-)

The JAPL driver should be the interface to the device....in the robocode

example, the code that handles the interrupts.  If higher level 
components need to know about this, then you should post an Embedlet 
Event.

The beauty of doing this using only events (not callbacks) is that later

you can add other event consumers that add new functionality and your 
JAPL code remains blissfully unaware (as it should be) that other 
Embedlets are now consuming the events and performing even more complex 
battle plans.

> The only thing we are missing now is a way for a JAPL peripheral to 
> send asynchronous information back to the Embedlet that has a 
> reference to it and using a simple callback for this purpose seems to 
> solve this problem adequately.

NO!  NO!  NO!]

Have the JAPL peripheral post an Embedlet Event.  You can attach the 
robocode interrupt data to the Embedlet Event...and the Producer ID
let's 
you tie this back to a particular JAPL peripheral (or include a
reference 
to the producing JAPL driver in the event).

That is how components should communicate using the Embedlet standard.  
Using callbacks from lower components to higher ones is against the 
spirit of the Embedlet spec and is also considered a very bad
programming 
practice for the reasons given.

> If there is then a need to propagate this information to the reset of 
> the components in the Embedlet container then the Embedlet that 
> contains the JAPL peripheral can then translate the JAPL event it 
> received into an Embedlet event and send it to the container.

Do this in the JAPL driver.  This gives you more downstream flexibility 
and is the way that Embedlets were supposed to work.

> It is starting to look like there are going to eventually be thousands

> of JAPL peripherals and it is going to be normal for developers to 
> create them 'on-the-fly' just like I am doing with the RoboCode I/O 
> systems. Since most of a developer's effort will probably be focused 
> on the Embedlets anyway it also seems like it might be a good idea to 
> have the JAPL related development be confined to the Embedlets too.

I'm not sure what you mean by that.

> If this line of thinking is followed to its logical conclusion then 
> JAPL peripherals are completely encapsulated inside of Embedlets and 
> showing them attached to the periphery of the Embedlet container is 
> not an accurate depiction.

I disagree.....the whole point of the event model is to allow this 
decoupling.  This way you can write a single embedlet that can manage 
multiple (similar) JAPL devices very easily.  Longer term application 
maintenance and expansion is also facilitated without needing to rewrite

any JAPL driver code if you take my approach from day one.

> I suppose that the 'Embedlets having direct references to JAPL 
> peripherals' model that is shown in the Architecture document is 
> either a good idea or it is not a good idea.

-1:  JAPL drivers having references to Embedlets
+1: Embedlets having references to JAPL devices
-1: Using callbacks from lower order components to higher order ones
+1: Using events to pass stuff from lower order components to higher 
+ones

> If it is a good idea then I do not
> see a problem with completing the connection by allowing the JAPL 
> peripheral to send callbacks to the Embedlet that contains it.

Like I said, if I can figure out a way for the Outpost implementation to

prevent this, I will! ;-)

> If it is
> not a good idea then this implies that Embedlets should not contain 
> direct references to JAPL peripherals at all and then we will need to 
> come up with another way to solve this problem.

Therein lies the fallacy of your approach, Ted.  This is not a symmetric

situation.  A one way reference from Embedlet to JAPL is fine, and in 
fact, was intended to be used all along.  It's the reverse reference
that 
is a bad idea since it breaks encapsulation and couples things too 
tightly.

A calling program can depend on a subroutine/method.  But a 
subroutine/method should not depend on the caller.  Async relationship!

Same with Embedlets versus JAPL drivers.

> At this point I would vote for exploring the callback model and see 
> how it plays.

Don't do it Ted!  Stay away from the dark side.  Do it the "right way".

Use event generation in your JAPL driver.

> Well, am I correct in assuming that the container only instantiates 
> one conventional instance of each Embedlet and that the 
> ComponentContext objects are then used to hold the state of multiple 
> Embedlets?

Nope.  Something I discussed with Chris.  To allow caching of 
ComponentContext data Outpost instantiates an Embedlet object for each 
Embedlet that is needed (unlike servlets).  But that may just be a 
container implementation decision, so may not be consistent across other

Embedlet Container implementations in the future.  

Use Events Ted....stay away from callbacks!

...Andrzej

Chaeron Corporation
http://www.chaeron.com




-------------------------------------------------------
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

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

[Andrzej J. T. <an...@ch...>]

> The JAPL devices are abstract peripherals, not device drivers.  

Whatever....I'm using the term interchangeably in my posts.  I see the 
abstract peripheral API's as being just a generic version of a specific 
device driver.

> 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.

The JAPL API for a UART should provide get/set methods for the internal 
registers, but suitably "abstracted" so that you don't see the metal (actual 
registers) from the other side of the API.  In other words, the JAPL API 
should be functional in appearance, not tied to the specific hardware 
implementation of the functions. For example:

japl.setFlowControl( true );
japl.setParity( false );

are much better than more "hardware oriented" stuff like:

int	flags = 0x01 | 0x04 	// eg. Flags for flow control and Parity
device.setFlags( flags );

As for the asynchronous notifications (interrupts basically), see my last 
post about using a JAPL Wrapper class as a mediation layer that converts such 
an async callback into an Embedlet Event.  There is MASSIVE benefit to using 
such an approach....the principal one being keeping the JAPL and Embedlet 
layers nicely decoupled and flexible (so that JAPL can be used outside of an 
Embedlet Container).

> The Architecture document gives an Embedlet 2/3 of the capabilities it needs
> to serve as a JAPL UART device driver because it allows the Embedlet to have a
> direct reference to the JAPL UART and so enables it to do 'a' and 'b' above.

That is true.  And assembler code could do the same, but that does not mean 
you should use that technique even though you could.  And Embedlets were 
always intended to be where you put your "application logic", not driver 
logic.  Driver stuff should be performed (and hidden/encapsulated, eg. how do 
you talk to a device at a low level) in the JAPL layer.  Application stuff 
should be in an Embedlet (eg. what you do when something happens...a temp 
sensor flips, process bytes that have been read by a UART).

Architecturally, the better way is to integrate Embedlets and JAPL 
peripherals is to use a JAPL wrapper to "bridge" the gap per my other email.

> As for the UART interrupt, in all the conventional low level device drivers I
> have written, the interrupt is always channeled directly into the device
> driver that is also responsible for doing 'a' and 'b' for any given device and
> it is always a one-to-one bidirectional binding.  No other piece of code
> besides the peripheral's device driver should be interested in the interrupt.

We're in violent agreement here, Ted!  Kewl!  The JAPL Wrapper approach I 
have outlined resolves this, since the Wrapper class is more a part of the 
JAPL layer than the Embedlet layer, even though it does bridge those two 
worlds.  So the combo of the JAPL driver/peripheral code and the Wrapper 
perform all of a/b/c in your example.  The Embedlet doesn't do any of these 
operations.  The Embedlet reacts in an application-specific way to an 
Embedlet Event that the wrapper may or may not send as a result of an 
interrupt. (note:  an interrupt may not always generate an Embedlet 
Event....if a switch state didn't change, or you are buffering I/O in the 
JAPL layer, then events are not always sent when an interrupt arrives).

> But you are saying that Embedlets should not be used as device drivers either
> (see below).

EXACTLY what I am saying.  JAPL should implement the device driver level and 
Embedlets should know NOTHING about that.  Use a JAPL Wrapper class to 
translate hardware driver level events of interest into an Embedlet Event 
that will be propagated throughout the Outpost container.

One of the benefits of this approach is that you can easily and transparently 
add additional Embedlets that are interested in a particular Embedlet Event 
originated by a JAPL device.  You can add a logging Embedlet that streams out 
JAPL status info across an HTTP connection to the outside world without 
having to touch one line of your JAPL code or your other application-specific 
Embedlets, if you use this architectural model.

> Again, a JAPL peripheral is just a peripheral, not a device driver.  

From some perspective, I see the JAPL peripheral as doing a lot of low level 
device driver types of things and exposing a higher level API (see example of 
what I mean by this above).  So in that sense, JAPL is a device driver to a 
great degree.

> Besides this, the JAPL peripheral can't convert its interrupts into
> Embedlet events > or any other specific system's events because the JAPL is
> a generalized, > system neutral technology. 

I should have explained myself more fully in my first response (but was 
hoping that everyone would figure it out).  Use a JAPL Wrapper class to 
bridge the two worlds and all is wonderful! ;-)

> If an Embedlet is being used as a device driver for a JAPL device then I would
> say that device drivers commonly have bidirectional references to the devices
> they are controlling.  My current thinking is that routing a peripheral's
> interrupt only to the device driver that is directly responsible for it
> maintains complete encapsulation but allowing this interrupt to be arbitrarily
> routed to other pieces of software in the system breaks it.

But an Embedlet should NOT be used as a device driver....it is intended to be 
used for application specific code.  Not low level hardware interfacing 
stuff.

Design patterns to the rescue....use a JAPL Wrapper class.

> What I hear you saying, though, is that Embedlets should not be used as JAPL
> device drivers and I can certainly go along with this philosophy if Embedlets
> are blocked from having direct references to JAPL peripherals. 

Grasshoppa....you are missing the point.  Embedlets can and have to have 
references to JAPL peripherals.  They need to do get/set properties on JAPL 
devices (using a higher level device API that JAPL exposes).  It's the 
reverse that is verbotten....the JAPL device is NOT allowed to have a 
reference to an Embedlet.  The Wrapper approach resolves this impedence 
mismatch.

> If an Embedlet
> is being constrained as only operating as a high level piece of code then how
> can it be ok to give it a direct reference to a low level peripheral like a
> UART?  

For the same reason that a higher level routine can reference lower level 
subroutines/methods to do it's work.  However, the reverse is considered a 
very bad practices.

Higher level components can employ lower level components to do their work.  
The reverse is not a good idea.

Keep in mind that the data coming in on the UART is typically application 
specific, (medical data?  shop floor sensors?  engine sensors?) and so at 
some level has to be processed by app-level code....meaning an Embedlet.

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.  But I see that as still 
in the JAPL domain, and not part of the Embedlet container, and you still 
need a wrapper approach to bridge the two worlds.  If such a Device Driver is 
needed on top of JAPL, it should also be independent of the Embedlet 
Container so that it can be used in non-embedlet based code.

> Assuming that a JAPL peripheral can not be its own device driver 

Why not?  In fact, there are a lot of good reasons for the JAPL peripheral to 
act as it's own device driver.  Maybe we are just using different definitions 
of what a device driver is/does?

> Embedlets are not permitted to be device drivers, then we still need some kind
> of a device driver that is part of the Embedlet framework that can do the
> following:

I believe such a driver should be part of the JAPL layer and not the Embedlet 
layer.

> 1) Hold direct references to JAPL peripherals.
> 2) Accept interrupt events from these peripherals.
> 4) Convert the peripheral's interrupt events into Embedlet events.

The combination of the JAPL peripheral (and any "device driver code) and the 
proposed JAPL wrapper approach nicely handle all of the above situations.  
But an Embedlet can hold a reference to a JAPL peripheral (so as to issue API 
method calls on it to get it's work done.  eg.  japl.setSwitch( true ) ).

Keep in mind that what Embedlet Event(s) an interrupt is mapped to is 
application specific, so it does not belong in the JAPL peripheral/driver 
code.

> 3) Convert Embedlet events into method calls on the peripheral.

That is not required since it presumes that low level devices understand 
Embedlet Events which they have no need to.  There is nothing wrong with an 
Embedlet doing method calls on a peripheral as requried.

I think some of the problem is that we had a stated design goal of keeping 
JAPL independent of Embedlets.  If we drop that requirement, then sure, we 
can create a new Embedlet-level component (eg. DeviceDriver) that understands 
Embedlet Events (both as producer and consumer), but then that code would not 
be useable outside of the container.

> The current Adapter might be suitable for this purpose and if not the Adapter
> then perhaps an Embedlet Container DeviceDriver?

Adapters are specifically intended to be used for integration of external 
systems/communications, not attached devices.

> Anyway, I am going to hold off doing more work in this area until we get
> this JAPL issue resolved.  Actually I have been hitting JGraph fairly hard
> during the past week in preparation for beginning work on the Wiring Tool
> and so I have plenty to keep me busy. ;-) 

Have my explanations of the use of a JAPL Wrapper class helped resolve this?

Glad to hear that you are pushing down the Wiring road.  Kewlness!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] Re: JAPL part of specification

[Andrzej J. T. <an...@ch...>]

Brill asks:

I thought that JAPL was going to be a separate specification, since it 
would/might have applicability outside of an Embedlet container?

> So... what I need to understand is how Outpost would be setting and getting
> attributes of a peripheral?

An Embedlet would have a reference to the JAPL device and would use whatever 
API the JAPL device exposed to set/get any attributes the device had exposed.

> > Can you give a bit more information about the idea behind these Type IDs?

Embedlet Event Types are just a string, which is tokens separated by periods. 
Something like my.event.id.  or device.id.eventtype.  The first token should 
not be emb or outpost, and don't use *'s in the type (those are used for 
pattern matching), other than that, no real restrictions.

> I started Piccadilly (what I'm calling the Outpost/JAPL combo) by extending
> Embedlet... the methods are fairly easy to understand.

You should not need to (and I feel shouldn't anyway) extend Embedlet to 
support JAPL devices.  See below.

> What I don't understand is how the embeled talks to the JAPL device.
> What is looked like, extending Embedlet is that the embedlet receives events
> from the system... now I assumed that I would do something different depending
> on the event code.

Assuming that the JAPL stuff is intended to be independent of the Embedlet 
container (something we talked about a long time ago), here is the way I 
think you should consider linking the two:

1) Create your JAPL drivers with an exposed API.  The JAPL device should NOT 
have a reference to any Embedlets, nor be dependent on ANYTHING in the 
embedlet spec (eg. no imports of org.embedlet or org.outpost packages).

2) Create an Embedlet (application logic that wishes to use a JAPL device) 
that receives Embedlet Events that will originate from a JAPL device somehow. 
The Embedlet can have a reference to the JAPL device if it needs it (or it 
can be passed in as part of the Embedlet Event it receives) so that it can 
make calls against the exposed API of the JAPL device.

3) Create a "proxy" wrapper for the JAPL driver that extends 
org.embedlet.EventProducer and which takes JAPL events (interrupts) and then 
creates/sends an appropriate Embedlet Event.  Note that this wrapper does NOT 
extend Embedlet (it doesn't have to), just EventProducer and that the JAPL 
driver can have a reference to the wrapper (if needed) for interrupt driver 
events (in which case the wrapper should implement a callback interface 
defined as part of the JAPL device API for such callbacks). The JAPL wrapper 
should NOT have a reference to any Embedlets.  All this wrapper does is 
convert internal JAPL information into an Embedlet Event, acting as a 
"bridge" between the two worlds.

A polling scenario doesn't need the wrapper (an Embedlet would use the Timer 
Service to poll the JAPL device), so let's look at an interrupt driven JAPL 
device.  Here is what the flow would look like:

1) JAPL device gets an interrupt.
2) JAPL device does a callback into the JAPL "Proxy" Wrapper.
3) The wrapper takes the interrupt data, puts in in an Embedlet Event and 
sends it (note: it does not know who the consumers are going to be).
4) An Embedlet (registered as a consumer for that particular event type) 
receives the event and then does something with it (possibly issuing JAPL API 
calls against the originating device, setting/getting attributes).

This approach follows best practices (per my earlier email), and is preferred 
for the following reasons:

1) Coupling between the Embedlet and JAPL layers is reduced (and kept uni-
directional, from Embedlet to JAPL only).

2) The use of a wrapper class means JAPL code can be used without change 
outside of the Embedlet Container environment (a good thing).

Make sense?  Do I need to write an example to show you how this is intended 
to be implemented?

Anyone else out there?  Gregg?  Chris?  You guys got any opinions?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

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

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

> >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

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

[Ted K. <tk...@ya...>]

Brill said:

>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.

Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Embedlets-dev] Re: JAPL Events

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

> 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

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

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

I've attached the javadocs for the current cork-japl library, so you can see
how things are going... and describes the event system you where talking
about.

You will notice that I have several I2C driver already, which where ported
from the old lib... I just finished the OneWireTransportLink and Pipe for
TINI, but it hasn't been debugged yet.

Also, I've only got 3 JAPL interfaces so far Pin, Port, Temperature... and I
have yet to implement those on all the drivers I ported over.

> >Is there a list of Type ID's? Or can I use a JAPL event/action id
instead?
>
> Can you give a bit more information about the idea behind these Type IDs?

This may be something I'm misunderstanding. I've been extram.ly busy with
new work, and have only had a few hours a week to try and get this
integration thing happening.

I started Piccadilly (what I'm calling the Outpost/JAPL combo) by extending
Embedlet... the methods are fairly easy to understand.

What I don't understand is how the embeled talks to the JAPL device.
What is looked like, extending Embedlet is that the embedlet receives events
from the system... now I assumed that I would do something different
depending on the event code.


> >So, I need to know if the event I've received is a polarity, direction
> >or value event.  Also, how would the port be read? I can receive an
> >event telling the port to change its value, but how would the remote
> >app request the value from the embedlet? (it looks to me as If I would
> >have to receive a "get value" event, then generate my own event listing
> >the value.
>
> The architecture document shows Embedlets having direct references to JAPL
> peripherals so sending or obtaining information from a JAPL peripheral
should
> be done by just calling some methods on it.  I think that giving JAPL
> peripherals the ability to receive events seems like it would become messy
> fairly quickly because then the JAPL peripheral would need to accommodate
a
> wide number of client event schemes.

Oh, I'm not saying you have to do it that way ;) I can do all sorts of
things agains the device in the embedlet, but it would be isolated.

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?

- Brill

Re: [Embedlets-dev] Re: JAPL Events

[Ted K. <tk...@ya...>]

Andrzej,

>If you think about the robocode application, the interrupts should be handled
by a JAPL device driver, which in this case is a robocode "virtual" device.
>[...]
And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

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.

The Architecture document gives an Embedlet 2/3 of the capabilities it needs to
serve as a JAPL UART device driver because it allows the Embedlet to have a
direct reference to the JAPL UART and so enables it to do 'a' and 'b' above. 
As for the UART interrupt, in all the conventional low level device drivers I
have written, the interrupt is always channeled directly into the device driver
that is also responsible for doing 'a' and 'b' for any given device and it is
always a one-to-one bidirectional binding.  No other piece of code besides the
peripheral's device driver should be interested in the interrupt.

But you are saying that Embedlets should not be used as device drivers either
(see below).



>And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

Again, a JAPL peripheral is just a peripheral, not a device driver.  Besides
this, the JAPL peripheral can't convert its interrupts into Embedlet events or
any other specific system's events because the JAPL is a generalized, system
neutral technology.



>Therein lies the fallacy of your approach, Ted.  This is not a symmetric 
situation.  A one way reference from Embedlet to JAPL is fine, and in 
fact, was intended to be used all along.  It's the reverse reference that 
is a bad idea since it breaks encapsulation and couples things too 
tightly.
>
>A calling program can depend on a subroutine/method.  But a 
subroutine/method should not depend on the caller.  Async relationship!  
Same with Embedlets versus JAPL drivers.

If an Embedlet is being used as a device driver for a JAPL device then I would
say that device drivers commonly have bidirectional references to the devices
they are controlling.  My current thinking is that routing a peripheral's
interrupt only to the device driver that is directly responsible for it
maintains complete encapsulation but allowing this interrupt to be arbitrarily
routed to other pieces of software in the system breaks it.

What I hear you saying, though, is that Embedlets should not be used as JAPL
device drivers and I can certainly go along with this philosophy if Embedlets
are blocked from having direct references to JAPL peripherals.  If an Embedlet
is being constrained as only operating as a high level piece of code then how
can it be ok to give it a direct reference to a low level peripheral like a
UART?  

Assuming that a JAPL peripheral can not be its own device driver and if
Embedlets are not permitted to be device drivers, then we still need some kind
of a device driver that is part of the Embedlet framework that can do the
following:

1) Hold direct references to JAPL peripherals.

2) Accept interrupt events from these peripherals.

3) Convert Embedlet events into method calls on the peripheral.

4) Convert the peripheral's interrupt events into Embedlet events.

The current Adapter might be suitable for this purpose and if not the Adapter
then perhaps an Embedlet Container DeviceDriver?


Anyway, I am going to hold off doing more work in this area until we get this
JAPL issue resolved.  Actually I have been hitting JGraph fairly hard during
the past week in preparation for beginning work on the Wiring Tool and so I
have plenty to keep me busy. ;-)


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

[Embedlets-dev] Re: JAPL Events

[Andrzej J. T. <an...@ch...>]

Ted:

Sorry 'bout the delay in replying.  This new contract is keeping me 
pretty busy and I've been too fried in the evenings to do much else.  
Settling in now, so hopefully I can do some embedlet work in my spare 
time.

> In the case of RoboCode, the model is definitely interrupt driven.  In
> addition to this, the RoboCode event objects contain rich semantics that
> need to be dealt with.  For example, the robocode.ScannedRobotEvent
> contains these methods:
> 
>     double getBearing()
>     double getBearingRadians()
>     double getDistance()
>     double getEnergy()
>     double getHeading()
>     double getHeadingRadians()
>     double getLife()
>     String getName()

Each interrupt event should be mapped onto an Embedlet event.  Note that 
using the User Data area of the Embedlet Event you can just append the 
robocode event, and not have to copy any data around.

> Before I posted my initial question I thought about this one a great deal
> and what I came up with is that this would require another type of
> software entity to be added to the Embedlet framework besides a Adapters,
> Transports and Embedlet.  Before going this route I thought that we should
> discuss it and probably at least try to solve the problem another way.  

Actually....it doesn't!  If you think about the robocode application, the 
interrupts should be handled by a JAPL device driver, which in this case 
is a robocode "virtual" device.

> Apart from this, it appears that the JAPL peripherals are well suited to
> use method calls for commands being sent to them and simple callbacks for
> any interrupts/events that they might generate.

Exactly.  And that robocode JAPL driver should convert the interrupts 
into Embedlet Events before posting them so that upstream Embedlets can 
do their battle planning.

> I am all for going with whatever makes sense here and my thinking so far
> on this topic is as follows.  The Architecture document already shows
> Embedlets having direct references to JAPL objects and so far my RoboCode
> experiments confirm that this is a good idea.  If an Embedlet has a
> reference to a JAPL peripheral then it is already closely coupled with it
> and in my opinion this is not a problem because the JAPL's abstract nature
> already provides the required level of decoupling.  

That is incorrect Ted!  Just because an Embedlet has a reference to a 
JAPL device does NOT imply that the reverse is OK.  Higher order 
components can have references to lower order (or more detailed, closer 
to the iron) ones.  However, the point of using an Event-driven model is 
to avoid the reverse, where more detailed components should not have to 
know about the consumers of the events.

This is very analagous to good programming practice where a subroutine or 
method should typically have NO knowledge of the caller.  Breaking this 
rule is what leads to tight coupling and inflexible application code.

Let me repeat that:  though the Embedlet can have a reference to the JAPL 
device, the JAPL device should NOT have a reference to an Embedlet!

Let me put this another way:  if I can figure out a way to prevent JAPL 
devices from getting Embedlet references I will do so in the Outpost 
implementation. ;-)

The JAPL driver should be the interface to the device....in the robocode 
example, the code that handles the interrupts.  If higher level 
components need to know about this, then you should post an Embedlet 
Event.

The beauty of doing this using only events (not callbacks) is that later 
you can add other event consumers that add new functionality and your 
JAPL code remains blissfully unaware (as it should be) that other 
Embedlets are now consuming the events and performing even more complex 
battle plans.

> The only thing we are missing now is a way for a JAPL peripheral to send
> asynchronous information back to the Embedlet that has a reference to it
> and using a simple callback for this purpose seems to solve this problem
> adequately.  

NO!  NO!  NO!]

Have the JAPL peripheral post an Embedlet Event.  You can attach the 
robocode interrupt data to the Embedlet Event...and the Producer ID let's 
you tie this back to a particular JAPL peripheral (or include a reference 
to the producing JAPL driver in the event).

That is how components should communicate using the Embedlet standard.  
Using callbacks from lower components to higher ones is against the 
spirit of the Embedlet spec and is also considered a very bad programming 
practice for the reasons given.

> If there is then a need to propagate this information to the
> reset of the components in the Embedlet container then the Embedlet that
> contains the JAPL peripheral can then translate the JAPL event it received
> into an Embedlet event and send it to the container.

Do this in the JAPL driver.  This gives you more downstream flexibility 
and is the way that Embedlets were supposed to work.

> It is starting to look like there are going to eventually be thousands of
> JAPL peripherals and it is going to be normal for developers to create
> them 'on-the-fly' just like I am doing with the RoboCode I/O systems. 
> Since most of a developer's effort will probably be focused on the
> Embedlets anyway it also seems like it might be a good idea to have the
> JAPL related development be confined to the Embedlets too.

I'm not sure what you mean by that.

> If this line of thinking is followed to its logical conclusion then JAPL
> peripherals are completely encapsulated inside of Embedlets and showing
> them attached to the periphery of the Embedlet container is not an
> accurate depiction.

I disagree.....the whole point of the event model is to allow this 
decoupling.  This way you can write a single embedlet that can manage 
multiple (similar) JAPL devices very easily.  Longer term application 
maintenance and expansion is also facilitated without needing to rewrite 
any JAPL driver code if you take my approach from day one.

> I suppose that the 'Embedlets having direct references to JAPL
> peripherals' model that is shown in the Architecture document is either a
> good idea or it is not a good idea. 

-1:  JAPL drivers having references to Embedlets
+1: Embedlets having references to JAPL devices
-1: Using callbacks from lower order components to higher order ones
+1: Using events to pass stuff from lower order components to higher ones

> If it is a good idea then I do not
> see a problem with completing the connection by allowing the JAPL
> peripheral to send callbacks to the Embedlet that contains it.  

Like I said, if I can figure out a way for the Outpost implementation to 
prevent this, I will! ;-)

> If it is
> not a good idea then this implies that Embedlets should not contain direct
> references to JAPL peripherals at all and then we will need to come up
> with another way to solve this problem.

Therein lies the fallacy of your approach, Ted.  This is not a symmetric 
situation.  A one way reference from Embedlet to JAPL is fine, and in 
fact, was intended to be used all along.  It's the reverse reference that 
is a bad idea since it breaks encapsulation and couples things too 
tightly.

A calling program can depend on a subroutine/method.  But a 
subroutine/method should not depend on the caller.  Async relationship!  
Same with Embedlets versus JAPL drivers.

> At this point I would vote for exploring the callback model and see how it
> plays.

Don't do it Ted!  Stay away from the dark side.  Do it the "right way".  
Use event generation in your JAPL driver.

> Well, am I correct in assuming that the container only instantiates one
> conventional instance of each Embedlet and that the ComponentContext
> objects are then used to hold the state of multiple Embedlets? 

Nope.  Something I discussed with Chris.  To allow caching of 
ComponentContext data Outpost instantiates an Embedlet object for each 
Embedlet that is needed (unlike servlets).  But that may just be a 
container implementation decision, so may not be consistent across other 
Embedlet Container implementations in the future.  

Use Events Ted....stay away from callbacks!

...Andrzej

Chaeron Corporation
http://www.chaeron.com

[Embedlets-dev] Re: JAPL part of specification

[Ted K. <tk...@ya...>]

Brill,

>Is there a list of Type ID's? Or can I use a JAPL event/action id instead?

Can you give a bit more information about the idea behind these Type IDs?



>So, I need to know if the event I've received is a polarity, direction 
>or value event.  Also, how would the port be read? I can receive an 
>event telling the port to change its value, but how would the remote 
>app request the value from the embedlet? (it looks to me as If I would 
>have to receive a "get value" event, then generate my own event listing 
>the value.

The architecture document shows Embedlets having direct references to JAPL
peripherals so sending or obtaining information from a JAPL peripheral should
be done by just calling some methods on it.  I think that giving JAPL
peripherals the ability to receive events seems like it would become messy
fairly quickly because then the JAPL peripheral would need to accommodate a
wide number of client event schemes.

Having the JAPL clients conform to standard JAPL mechanisms is different,
however, because then the JAPL peripheral represents a single standard that all
clients must adhere to.  For example, in order to receive asynchronous
information back from a JAPL peripheral I am currently leaning towards using a
simple callback by having the Embedlet (or any other JAPL client) implement the
following interface:

package org.japl;

public interface JaplEventListener
{
    void receiveJaplEvent(Object japlEvent);
}//end method


This uses the standard 'message out, notify in' pattern and so far it has
worked well in the Robocode experiments I have been doing.

This is definitely an area that will need to be discussed and nailed down
before we can proceed much further though...

Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Embedlets-dev] JAPL callback experiment update

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

For an embedlet event;

Is there a list of Type ID's? Or can I use a JAPL event/action id instead?

For instance, I've got a TiniPortEmbedlet which controls the 8 bit Port on a
tini. Unfortunately the Dallas implementation is not very good and it have
no direction, polarity etc... however you can set it's value :)

So, I need to know if the event I've received is a polarity, direction or
value event.

Also, how would the port be read? I can receive an event telling the port to
change its value, but how would the remote app request the value from the
embedlet? (it looks to me as If I would have to receive a "get value" event,
then generate my own event listing the value.


- Brill Pappin

----- Original Message -----
From: "Ted Kosan" <tk...@ya...>
To: <emb...@li...>
Sent: Thursday, March 27, 2003 1:48 AM
Subject: [Embedlets-dev] JAPL callback experiment update


> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> I have continued experimenting with having a JAPL peripheral use a simple
> callback to send information asynchronously back to the Embedlet that has
a
> reference to it and here is what I have come up with so far.
>
> 1)  Have the Embedlet use a class variable to hold a reference to each
JAPL
> peripheral that it is interested in.
>
> 2)  Have all JAPL event listeners implement the following interface if
they are
> interested in receiving JAPL events:
>
> package org.japl;
>
> public interface JaplEventListener
> {
>     void receiveJaplEvent(Object japlEvent);
> }//end method
>
> 3)  Create an inner class inside of the Embedlet called JaplListener and
have
> it implement the JaplEventListener interface.  Have the Embedlet hold a
static
> singleton reference to this JaplListener.
>
> 4)  Place public static setters and getters inside of the Embedlet so that
the
> JAPL peripherals can be set and obtained and also so that the JaplListener
> singleton instance can be obtained.
>
>
> The main difficulty that I have encountered so far is when to pass in the
> instances of the JAPL peripherals to the Embedlet (and also getting a
reference
> to the Embedlets JaplListener singleton so that it can be placed in the
JAPL
> peripheral's listener list).  Right now I am kind of hacking this part
together
> by doing this after the outpost container has been started but this is
> definitely risky and a better technique must be available.
>
> Anyway, for the most part, the above configuration seems to work well and
I
> currently have a JaplScanner peripheral sending events into a
ScannerEmbedlet
> using a callback and then the ScannerEmbedlet controls the firing of the
tank
> cannon using a JaplCannon peripheral (right now the SittingDuck test robot
that
> comes with RoboCode is getting the snot knocked out of it by my
EmbedletBot!).
>
> My next step is to have the ScannerEmbedlet do some processing on the JAPL
> robot scanned event and then to publish this information into the
container.  A
> FireControllerEmbedlet will then be created which will subscribe to this
event
> along with a ManeuversEmbedlet.  More Embedlets should follow from here...
>
> RoboCode is certainly turning out to be a great way to exercise the
Embedlet
> Container in an intense, easily-deployed-to realtime environment.
>
>
> Ted
>
>
> PS, after looking through the Outpost code is it clear that each Embedlet
> receives its own conventional Embedlet instance along with its own
> ComponentContext object.
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>
>
> -------------------------------------------------------
> 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
>

[Embedlets-dev] JAPL callback experiment update

[Ted K. <tk...@ya...>]

I have continued experimenting with having a JAPL peripheral use a simple
callback to send information asynchronously back to the Embedlet that has a
reference to it and here is what I have come up with so far.

1)  Have the Embedlet use a class variable to hold a reference to each JAPL
peripheral that it is interested in.

2)  Have all JAPL event listeners implement the following interface if they are
interested in receiving JAPL events:

package org.japl;

public interface JaplEventListener
{
    void receiveJaplEvent(Object japlEvent);
}//end method

3)  Create an inner class inside of the Embedlet called JaplListener and have
it implement the JaplEventListener interface.  Have the Embedlet hold a static
singleton reference to this JaplListener.

4)  Place public static setters and getters inside of the Embedlet so that the
JAPL peripherals can be set and obtained and also so that the JaplListener
singleton instance can be obtained.


The main difficulty that I have encountered so far is when to pass in the
instances of the JAPL peripherals to the Embedlet (and also getting a reference
to the Embedlets JaplListener singleton so that it can be placed in the JAPL
peripheral's listener list).  Right now I am kind of hacking this part together
by doing this after the outpost container has been started but this is
definitely risky and a better technique must be available.

Anyway, for the most part, the above configuration seems to work well and I
currently have a JaplScanner peripheral sending events into a ScannerEmbedlet
using a callback and then the ScannerEmbedlet controls the firing of the tank
cannon using a JaplCannon peripheral (right now the SittingDuck test robot that
comes with RoboCode is getting the snot knocked out of it by my EmbedletBot!).

My next step is to have the ScannerEmbedlet do some processing on the JAPL
robot scanned event and then to publish this information into the container.  A
FireControllerEmbedlet will then be created which will subscribe to this event
along with a ManeuversEmbedlet.  More Embedlets should follow from here...

RoboCode is certainly turning out to be a great way to exercise the Embedlet
Container in an intense, easily-deployed-to realtime environment.


Ted


PS, after looking through the Outpost code is it clear that each Embedlet
receives its own conventional Embedlet instance along with its own
ComponentContext object.

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

[Embedlets-dev] RE: [Embedlets-dev][muvium] Re: proposed JSimm.uVM board

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

I agree it would be incredibly useful and I think a common design
pattern to have these java platforms all working together like this.

One of the reasons I am so bullish about java is the way it is a 'stack'
from PC, all the way down to uVM.. You can use java all the way down.
One skill..

I love the idea of uVM plugging into TSTICKS/Jsticks HUBS and want to
make this as doable as possible.

Right now, it would be possible(I haven't done it) to take the uvmp
programming software - the source is in the uVMDK and run it on a
Jstamp! Which means you could right now program devices attached to the
jstamp over the uVM UART.

Now.. The next question is.. What about other programming conduits..
I2C, SSP!.. Well of course this can happen. I am really keen on the the
SLIP connector for programming also. 

It's all about priorities. I want to create something of a uVM proxy
class that makes the access to the external uVM devices transparent..
Basically make them into abstract peripherals.. Part of the APT. When I
put out the new version of VBB this weekend hopefully, it will have an
APT compliant emulation which as you will come to understand is the
basis for everything that sits ontop of it.

If someone who is really skilled in Jstamp will put their hand up I
would like to work with them to build a APT compliant framework - based
on the PC apt framework from virtual breadboard, for the Jstamp ie Agile
processors in general and/or for the TINI.. What will then mean is when
we build JAPL ontop of APT it will run on all platforms.. uVM, VBB,
Jstick, Tini. 

Anyone?

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Wednesday, 26 March 2003 3:18 PM
To: emb...@li...
Subject: [Embedlets-dev] Re: proposed JSimm.uVM board


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

Bruce said:

>In the spirit of this effort I'd be willing to create such a board
>and sell it to early users at a loss. (We won't be able to recoup 
>our engineering costs in the first few hundred units, so if we sell 
>at a price of components plus out of pocket assembly, we're really 
>subsidizing the effort).
>
>So my point in sending this is to see what interest there is in us
>doing so, and what the features should be.

I think that having a uVM on a JSimm backplane would be a very useful
device to have.  For Embedlets, its looking more and more like these
type of devices would be very useful for implementing JAPL peripherals
and also giving these peripherals realtime capabilities.

One question I have is what it would take to be able to program one of
these devices through either the SPI interface or the I2C interface?  It
would be very nice to be able to plug a TStik into a JSIMM backplane to
provide Ethernet and large memory capabilities and then to plug a few
uVM JSIMM cards into the backplane in order to meet any realtime needs.

It would be great if the TStik could then provision the uVM JSIMMs as
needed without needing to use the serial ports.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


-------------------------------------------------------
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