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