RE: [Embedlets-dev] RE: repost of JAPL question...

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

Hi All,

Well I am coming out of hibernation also!

Having just cleared a contract.. so I am cashed up and ready to burn
some muvium and embedlet hours 24x7 for at least the next 6 months so
get ready for the final onslaught.

I want to jump back into this JAPL conversation because I have the whole
time held a slightly different opinion to the breakup of the JAPL layer
and I think it is important for my goals with muvium to converge nicely
on the Embedlet layers.

Now that I have completed the port to the 18F family ( you heard it here
first ) you get up to 64k program space on the 18F8720 and when you
think about what squeezes on the 8K uvm-877A that's A LOT of code - more
than enough to host a serious embedlet container.. Especially when I
throw in extended mode with a 32K external RAM for heap.. So muvium is
certainly going to be embedlet capable.. 

Also of note will be the embedlet container running in Virtual
Breadboard/ muvium emulation.. Which means virtual circuits (with nice
graphics for Ted) with all sorts of moving robots and stepper motors all
controlled from an embedlet container emulation. Excellent way for
people to learn about/develop for/contribute to the embedlets codebase
without having to even touch a real chip or wire a real robot or blow
anything up! I think this is a very important step.. The convergence of
Virtual Breadboard with muvium real-time emulation, and any Embedlet
containers compliant JVM's, .. May even make a special type of
breadboard that you can drop wireable components to create
applications.. Lot's of scope.

The implementation of the embedlet container itself for muvium is
something I will implement in assembler so it needs to be pretty clear
what I am building before I build it as assemblers a bitch so that's why
they invented java :-)

Well, just a heads up really. I am moving (again) this weekend to
(another) new homebase in Holland this time so once I am settled in it
will be full stream ahead! (pun intended)

Cheers all,

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Thursday, 29 May 2003 11:54 PM
To: emb...@li...
Subject: [Embedlets-dev] RE: repost of JAPL question...


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

I am in the process of jumping back into Embedlets 'hot-and-heavy' again
(details to follow) but I would like to work through the JAPL Wrapper
issue first.  The following is a repost of my latest question on this
issue and I still really want to be convinced that using a JAPL Wrapper
to only receive messages from a JAPL device and using an Embedlet to
only send messages to a JAPL device is a good idea.

Ted


</repost>

Andrzej,

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

Well, we are getting there but I still have some more questions so I
hope you will bear with me!  ;-)



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


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

Well, I am trying to understand how the Embedlet registering itself as a
listener for Events coming from a JAPL peripheral it already has a
reference to makes the JAPL peripheral at all dependent on the Embedlet
code base?  My approach was to have the JAPL library contain an
interface like the following:

package org.japl;

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

and then the Embedlet would implement this interface and then register
itself as a JaplEventListener just like any other JAPL client would.  If
the Embedlet already has a dependency on the JAPL peripheral, what is
the harm of allowing it to have a further dependency on a JAPL
interface?

My thought was that for any given JAPL peripheral, one Embedlet in the
application would be used to wrap around it and then all the code needed
to perform the semantic impedance matching with this JAPL device would
be isolated inside of this single Embedlet (including messaging code and
JAPL event handling code).


>1) Hold direct references to JAPL peripherals.
>2) Accept interrupt events from these peripherals.
>3) 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 ) ).

I am still trying to understand what the benefit is of allowing an
Embedlet to send sub-application-semantic-level messages directly to a
JAPL peripheral but to have sub-application-semantic-level  asynchronous
events coming from the JAPL peripheral to be broadcast to an arbitrary
number of Embedlets via the Embedlets event mechanism?

I think you are going to say that the JAPL wrapper will convert between
the I/O level semantics of the JAPL peripheral and the application-level
semantics of the application but I still can't see why all of this
impedance matching is not happening in one place (either all in one
Embedlet or all in the JAPL wrapper)?

From my perspective, this is the kind of situation that is confusing me:

- A SerialTerminalEmbedlet instantiates a JaplUart peripheral and
initializes it to 9600,8,N,1 in its initialize() method using I/O level
semantics.

- All application-semantic-level data that is sent to the terminal's
screen by other Embedlets in the application is sent via Embedlet events
to the SerialTerminalEmbedlet because it is the only piece of software
in the application that has a reference to the JaplUart and so can send
messages to it.


- As asynchronous I/O level semantic data comes in from the JaplUart, it
is routed through the JAPL wrapper and then published to the Embedlet
event system.  As posted in earlier emails, only application level
semantics should be sent through the Embedlet event system so the JAPL
wrapper would need to convert the I/O event semantics into application
level semantics before publishing to the application.

So, why does all of the outgoing Embedlet/JAPL impedance matching happen
in an Embedlet and all of the incoming JAPL/Embedlet impedance matching
happen in a completely separate and unrelated piece of software (the
JAPL wrapper)?  Why not let one Embedlet handle impedance matching in
both directions since having an Embedlet implement something like the
JaplEventListener interface completely prevents JAPL peripherals from
having dependencies on Embedlets?


Again, my main goal here is to completely understand the reasoning
behind the decisions being made in this part of the architecture so
please bear with me because I am having a tough time with it!  ;-)

Ted

</repost>

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer