[Tinyos-devel] improving FTSP interface

[Geoffrey Werner-Allen]

As a frequent FTSP user I would prefer a push event, similar to the
Counter.overflow() that Andreas suggested above.  I feel like having to poll
an interface is one more timer I have to maintain at higher levels.  In the
future it might make sense for FTSP to maintain a 48-bit timestamp directly
to allow for longer deployments.

In addition, I've already brought this up with Brano but I would have liked
the FTSP interface that was checked in to support a higher precision tag
(32kHz) on platforms the that support it (many, we concluded).  While I
expect that many applications will be happy with a millisecond clock of
known high accuracy, ones that need higher precision or that want to do
validation to detect errors or examine accuracy would benefit.  Thoughts?

Glad to see FTSP moved into the main T2 tree.  It's mighty useful.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner


On Thu, Aug 7, 2008 at 8:26 PM, Omprakash Gnawali <gnawali at usc.edu> wrote:

> On Thu, Aug 7, 2008 at 1:26 PM, Miklos Maroti <mmaroti at math.u-szeged.hu>
> wrote:
> >>> >>> so to make it easier for app developers, FTSP can provide
> >>> >>> isRollover(uint32_t current_time) command that implements this,
> right?
> >>> >>>
> >>> >>> one scenario, where rollover would be useful is when your
> application
> >>> >>> runs for a long time and doesn't query ftsp's global time very
> often.
> >>> >>> 33rd bit could flip twice without the app realizing it, while
> rollover
> >>> >>> bit would stay set. for 32khz clock (hopefully provided soon), this
> >>> >>> would mean 4.5 hours which is not totally unreasonable. ftsp could
> >>> >>> realize the rollover because it receives periodic timesync
> messages.
> >>> >>>
> >>> >>> brano
> >>> >> Another solution would be to provide an overflow "interrupt" like
> the
> >>> >> Counters.
> >>> >>
> >>> >
> >>> > Commenting on the interface - an interface such as this or the one
> >>> > that Brano suggested should work.
> >>> >
> >>> > It just does not make sense for an application to make indirect
> >>> > inferences which can be error prone.
> >>> agreed. especially - miklos's code is usually correct and very
> >>> efficient, but hard to understand. i bet only 50% of people will
> >>> understand what he proposed above, and less than 1% will understand the
> >>> comment that the code will always work (and the reason for it). :)
> >>>
> >>> any preferences on pull vs push? i'm personally on the pull side
> >>> (isRollover) - this allows you to check rollover of any timestamp at
> any
> >>> place in your code. as opposed to forcing everybody to wire yet another
> >>> event.
> >>>
> >>> brano
> >>
> >> Push has the advantage that you can maintain a 64 bit clock on top of
> >> it. Just my 2c.
> >>
> >>
> >
> > You need to have the last global time and current global time. So if
> > you want to have a command for this, then the user has to maintain the
> > last global time or you need to parametrize the interface. It should
> > be an event, then a single last global time (the FTSP already has
> > this) should be sufficient.
> >
>
> One other topic when we are trying to improve FTSP interface - Let's
> say, FTSP says the current time is 5 and later it says the current
> time is 10, do I know if 5 units of time have elapsed? We probably
> want another bit to tell if there was any desync/sync event since the
> last read.
>
> This is a nice lead into the push vs pull discussion. If there are a
> few bits like these that need to be read for each time reading then it
> probably makes sense to make it push.
>
> - om_p
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080807/76c596ec/attachment.htm