RE: [Embedlets-dev] Device polling

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
> > In this way the system can be built up from mix-and-match
> components that
> > may come from different vendors and no one component has
> disproportionate
> > 'control'.
> >
> > This also gives you the flexibility to have local independent loops that
> run
> > at different rates if that is a requirement. You (the Embedlet
> user) gets
> to
> > determine who is in control! You (the Embedlet designer) do no have to
> > accommodate multiple, mutually exclusive requirements.
>
> Control is good... but there are situations (a lot of them) where
> you really
> don't want users to be able to mess with the internals... I guess the
> embedlet user does need to be able to take some control, but I think it
> should be limited to what the environment deems "safe" or efficient... for
> instance, if the embedlet container wants to poll temperature every 500uS,
> the JAPL implementer is not going to allow the container to force
> me to make
> a call to actually read the temperature that often (depending on the
> granularity and speed of the sensors etc.) because it takes up resources I
> need for other functions, and that I don't really want to give up to the
> embedlet container.

I was not suggestng the the container provide fixed timing control, rather
that timing embedlets provide that function and get wired to the inputs and
outputs as required for polling operations. This provides for multiple local
timing loops that can accommodate the particular sensor or system
requirements.

>
> So, I guess my point is that though you can delegate some control to the
> embedlets, in a lot of circumstances, the underlying JAPL impl.
> *must* keep
> control over itself, and prevent the embedlet(s) for putting it into an
> unstable or inoperative state.

Agreed, if there are time critical activities that need to have
uninterrupted attention, such as receiving bits from a serial stream, then
the JAPL needs to maintain timing control for the duration of the critical
event. At a higher level where the output of the JAPL needs to integrate
with other processes, the embedlet(s) should have the to option to control
the timebase of the system. It is only at the embedlet level that the
overall timing requirements are defined. This may be based on the minimum
Nyquist sampling/update rate of other inputs or the outputs OR client
application reporting requirements. It could be on a timeframe of
milliseconds to days or weeks. In this case the JAPL may be the resource hog
if allowed to run on at a fixed, high rate.

The embedlet/JAPL timing specifications will need to be carefully considered
in any mix-and-match design. If one embedlet is demanding resources or
performance beyond those available the system is likely to fail at some
point regardless of whether a particular JAPL or embedlet manages all of its
internal timing needs.

>
> - Brill Pappin
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>