RE: [Embedlets-dev] Re: JAPL Events

[Christopher S. <cs...@oo...>]

My sugesstion here would be to define the functionality boundary between
Embedlets and JAPL as those which are portable between hardware platforms
and those that are not.

So a UART with an IO address, Interrupt vector and setup registers should be
interfaced through JAPL. Communication through the interface would be
available to an Embedlet either directly or through an intervening service
that provides access for multiple Embedlets.

Interrupts would be translated into Embedlet events at a point that
abstracts the hardware interface to a common standard for the media. In this
case character(s) received not individual bits. The JAPL would have to
buffer the character streams and operate on a separate thread to accomodate
the difference between the synchronous nature of the hardware interface and
the asychronous none deterministic nature of Embedlets.


The best example of this division is the comm interface provided by Sun. You
can access a comm device on a wide range of hardware devices using the same
code with only minor configuration adjustments. The device/VM vendor
provides the implementation that manages the underlying hardware, interrupt
handling and character buffering.

Using this criteria would, I feel, would reduce the discussion to a tangible
baseline with little gray area.

Chris

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