Re: [Embedlets-dev] Re: Device polling and timing

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

> If certain device operations are resource intensive (per Brill's comment),
then
> this should be documented clearly for the particular JAPL/Device
> implementation.  I'm not sure it will make sense to complicate the initial
> implementations by having the device driver level try to manage such
> restrictions.  Let's keep it simple at first, and then see how it evolves.

I think you have to assume that *all* devices are resource intensive... of
course, this also depends on your definition of "resource intensive".
What I'm talking about, is that no matter how you slice it, if you talking
(over 1-wire for instance) to a peripheral, the whole 1-Wire system will be
tied up intil that comm is done.. and multiple requests can only happen in
sequence.
To me, thats resource intensive.

> One key issue I see is that stringent device level timing will invariably
require
> threads to manage.  Bit of a problem on platforms that do not provide
threads.
> Using interrupts might be a potential workaround in some cases.

The Embedlet architecture should not know or care about how the underlaying
system manages its resources. It may use interrupts, or threads, or whatever
else it has to complete the tasks requirested of it by an embedlet.


> > In the case of a timer, of course the embedlet system is going to do the
> > configuration, however it will *not* have direct control over the
timer...
> > it must control the timer through the JAPL contract.
>
> The key question here is whether the device/JAPL implementation should
> manage a timer or not.  Unless it's absolutely necessary (due to stringent
> hardware requirements) I would say that JAPL devices should not implement
> any internal timers in most cases.  See comments above.  If they do need
an
> internal timer then of course this should be managed through the JAPL
> API/Contract.

the JAPL impl might manage the timer, but the embedlet system will have no
say in how its done, except to configure it though the JAPL. Remember, JAPL
is simply a contract, not an API of executable code. The embedlets *can't*
know how to manipulate some proprietary timer (or other resource) on the
processor, unless the embedlet it's tied to the specific processor (which I
think we're trying not to do).
Also, I don't think you can specify what internal resources the JAPL impl
will be using... a lot of things *need* the hardware timers. For instance, a
lot of bit-banged protocol impl's use the timers, and/or interrupts.

> > Oh, I don't mean to say the the JAPL has to do this.. it only need to
know
> > the contract that will allow it to configure the system, listen for
events
> > etc.
>
> Not sure what you mean by "events" in this context, Brill?  If you mean
> hardware events (interrupt, receive buffer full, etc.) then I have no
problem
> with this.  However, JAPL devices should not know anything about Embedlet
> events and should not be listening for such.

I mean that the JAPL, and its underlying code don't need to listen for
Embedlet event... however an embedlet might want to listen for JAPL events.

I think its vital to separate the low level stuff from the embedlet stuff...
a good example is a server... you may have a very robust servlet engine
running on it, but the servlet engine doesn't get a whole lot of say in how
the server manages its resources. We have the same situation here, and the
"Peripherals" simply become Objects that the embedlet can use to do its job,
based on the JAPL contract it knows about (which is common to all JAPL
implementations).

- Brill