[Embedlets-dev] Re: Device polling and timing

[Andrzej J. T. <an...@ch...>]

Chris said:

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

Makes a lot of sense to me.  One way to help determine where the 
responsibility lies is to look at whether the timing issue is hardware or 
application related.

If you are producing a stream of pulses on a pin, then the timing is hardware 
based, and likely should be handled inside of the JAPL implementation.  Or if a 
device needs regular attention to function correctly (eg not overflowing stream 
buffers).

If the application specifications say that you need to take a temperature 
reading every 5 minutes, this is an application requirement, and should be 
handled using an Embedlet and the Timer Service.  The JAPL driver should 
not be involved (except when it's API to get the temp gets called).

I'm sure there are some grey areas.....but most should fall into hardware of 
application requirements fairly easily, which will then point to where they 
should be implemented.

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.

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

Yup....and this would likely produce the symptom of infinitely growing event 
queues, so it could be detectable in some circumstances.  One of the 
drawbacks of event/message based systems is that the event queues are the 
"buffer" between processes that can run at different speeds, and if one of 
those processes becomes a bottleneck, all hell can break loose.  Tough 
problem to solve....but we can mitigate it by making the Event Manager 
configurable (eg. max event queue sizes.......warning levels and such).  But 
again, let's start simple and see where we end up.

Brill said:

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

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





Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com