[Tinyos-devel] Request for comments: TEP-108

[Matt Welsh]

Thanks for the feedback!

On Wed, 2006-11-15 at 15:05 +0100, Jan Hauer wrote:
> > Correct me if I'm wrong (Jan, David, Gil), but sensorboard
> > implementations are built on top of the ADC resource which should
> > expose the Resource/ResourceRequested interfaces along with the
> > ReadNow interface from the ADC HIL.
> 
> The ADC HIL provides ReadNow with an instance of Resource, not with
> ResourceRequested. TEP 108 says "An arbiter SHOULD provide a
> parameterized ResourceRequested interface to its clients, but is not
> required to." The ADC does not (and we agreed it should not) specify
> which exact arbiter is used. Since the ADC HIL cannot expect that
> there is a ResourceRequested, it does not provide this interface.
> 
> Miguel, what about writing *one* component that provides you access to
> both sensors, built on top of the ADC HIL (the component keeps some
> state/timer about the current configuration and waits 10ms if needed;
> you might even use a power manager or can have a look at the reference
> voltage generator code for msp430) ?
> 
> Jan
> 
> > A sensorboard that uses an ADC
> > should connect through this HIL interface in order to implement its
> > SIDs interface.  Maybe the ADC HIL implementations haven't been
> > updated yet to expose this interface as it is still under discussion.
> > (I know that TEP 101 currently says that ReadNow is only provided in
> > conjunction with Resource, but maybe it needs to be updated....
> > again....).
> 
> > > > 1. check if isOwner(), proceed with ADC conversion if true and go (5).
> > > > 2. if not owner, request() resource.
> > > > 3. on granted(), start a 10ms timer.
> > > > 4. on timer's fired(), proceed with ADC conversion.
> > > > 5. do not release resource.
> > > > 6. on requested() event, call release()
> > > >
> > > > this way, every time the resource is changed between sensors i would
> > > > have the 10ms delay. consecutive reads to the same sensor do not need
> > > > to use the timer.
> 
> On 11/6/06, Kevin Klues <klueska at gmail.com> wrote:
> > These aren't so much comments on the contents of the TEP, but rather
> > on how to use the features it presents.  Implementations of Arbiters
> > according to the TEP exist in the development branch of cvs on
> > sourceforge, but not on the main branch.
> >
> > Correct me if I'm wrong (Jan, David, Gil), but sensorboard
> > implementations are built on top of the ADC resource which should
> > expose the Resource/ResourceRequested interfaces along with the
> > ReadNow interface from the ADC HIL. A sensorboard that uses an ADC
> > should connect through this HIL interface in order to implement its
> > SIDs interface.  Maybe the ADC HIL implementations haven't been
> > updated yet to expose this interface as it is still under discussion.
> > (I know that TEP 101 currently says that ReadNow is only provided in
> > conjunction with Resource, but maybe it needs to be updated....
> > again....).
> >
> > One thing to note, however, is that using the ResourceRequested
> > interface alone in order to decide when to release a resource is
> > discouraged for devices that wish to use the power management features
> > available with T2.  If clients only release resources based on a
> > ResourceRequested event, then the resource will never have the chance
> > to go idle and any power managers wired to the ResoruceController
> > interface provided by the resource's arbiter will not be able to power
> > it on/off automatically.  In the case of the ADC on the Msp430, this
> > means that the reference voltage generator never has the chance to go
> > off even though there are no users currently using the ADC (not sure
> > what the repercussions are for the atmel platforms).
> >
> > I think what is typically done is that the SIDs read interface is
> > implemented using the ADC HIL Read interface and the SIDs ReadStream
> > interface is implemented using the ADC HIL ReadStream interface so
> > that you don't have to worry about the details of dealing with the
> > Resource yourself unless it is specifically required for your
> > implementation (that's why the ReadNow interface exists).  The
> > sensorboard implementation thus takes care of configuring the ADC
> > correctly and then calling its respective Read and ReadStream
> > implementations....
> >
> > Kevin
> >
> > On 11/6/06, Miguel Freitas <mfreitas at gmail.com> wrote:
> > > Hi Kevin,
> > >
> > > On 11/5/06, Kevin Klues <klueska at gmail.com> wrote:
> > > > Dear TinyOS developer community:
> > > >
> > > > Matt Welsh sent out a request for comments on TEP 108 on October 20th.
> > > >  Until now no one has responded to this request, and the deadline
> > > > before  the TEP moves into final review is November 17th.
> > >
> > > I'm a newcomer here, so please take my comments with a grain of salt.
> > > I have replied Matt directly with both comments and questions, below
> > > is the email i've sent him.
> > >
> > > ---
> > >
> > > On 10/31/06, Miguel Freitas <mfreitas at gmail.com> wrote:
> > > > Matt,
> > > >
> > > > I'm investigating the porting of the mts300 sensorboard to latest
> > > > tinyos-2.0 standards, and resource arbitration is a key point.
> > > >
> > > > i have 2 sensors sharing a single resource (the same adc channel). to
> > > > make things more fun, the original mts300 code implemented a 10ms
> > > > delay after changing adc source as a matter of "stabilization" of the
> > > > signal.
> > > >
> > > > my plan for implementing this would be using the Resource /
> > > > ResourceRequested interfaces. for example:
> > > >
> > > > implementation of the command "read()" of one of the sensors:
> > > >
> > > > 1. check if isOwner(), proceed with ADC conversion if true and go (5).
> > > > 2. if not owner, request() resource.
> > > > 3. on granted(), start a 10ms timer.
> > > > 4. on timer's fired(), proceed with ADC conversion.
> > > > 5. do not release resource.
> > > > 6. on requested() event, call release()
> > > >
> > > > this way, every time the resource is changed between sensors i would
> > > > have the 10ms delay. consecutive reads to the same sensor do not need
> > > > to use the timer.
> > > >
> > > > the problem is: requested() event is only available from
> > > > ResourceController which is a single instance on arbiters. there is no
> > > > such thing called ResourceRequested on tinyos cvs.
> > > >
> > > > what should i do?
> > > >
> > > > is that TEP waiting for general agreement before ones starts coding
> > > > support for ResourceRequested?
> > > >
> > > > am i trying a wrong/bad/stupid solution for this problem?
> > > >
> > > > Miguel
> > > >
> > >
> >
> >
> > --
> > ~Kevin
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel