RE: [Embedlets-dev] Device polling

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

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Re: Outpost_ArchitectureDiscussionDocument_13.pdf
> Page: 12 (bottom)
>
> I'm a little concerned about allowing "device polling and timing" to be
> entirely in the domain of the embedlet service(s), if in its
> domain at all.
>
> I think it would be better if the embedlet service(s) *requested* specific
> polling "properties" from the JAPL, however polling is something
> that can be
> device and processor dependant (sometimes in the extreme).
>
> A processor or JAPL implementation should be allowed to define it's own
> polling rates etc... for instance, most temperature sensors
> require quite a
> bit of time to show any significant changes... the JAPL
> implementation will
> know how fast a device responds, and can tailor itself accordingly.
>
> I think what might be a slightly better approach (though I have
> not entirely
> thought it through) is if the embedlet service(s) could tell a
> JAPL impl. to
> notify it through an event when a change occurred... so for
> instance in the
> Temperature sensor example, the embedlet container would be able
> to give the
> sensor a change window, and receive an event when the actual JAPL
> implementation determined that it was warranted.
>


> In the case where the state of the peripheral was requested from
> the remote
> system, it would be a fairly simple task for the outpost module
> to store the
> last state and return that. Some devices of course should not be event
> driven, but most I can think of off the top of my head would best be
> implemented that way.
>
> What this means, is that the embedlet service(s) have no control over the
> polling or timing rates etc... which is the opposite of the current spec.
> discussion (and why I bring it up).
>
> Thoughts?
This is the classical 'who has control' discussion that goes on in any
architecture. My recomendation would be to break the pieces down to a little
lower level so that you have fine-grain, descrete functional blocks that can
provide both functional requirements:

1. A sample timer (Embedlet) that issues timer events
1. I/O (JAPL or Embedlet) that just gets the data when told. Then issues a
'done' event
3. A theshold sensor that receives the 'done' event checks upper/lower
bounds and issues an 'out-of-bounds' event.

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.

>
> - Brill Pappin
>   Rogue Robotics
>   www.roguerobotics.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>