[Tinyos Core WG] Re: [Tinyos-devel] Re: I2C and SPI sharing

[Kevin Klues]

So, I'm trying to break this problem down and figure out what the best
solution is.  So far I've come to notice two things worth noting...

1) If unconfigure is not called between subsequent I2C calls (with or
without the radio/SPI taking over in between), then the whole stack
breaks.
2) The very first I2C write always returns a writeDone with error==FAIL

Is there any specific reason this is happening?  Why does the I2C bus
depend on it being configured/unconfigured on every request/release,
even if no one else has taken over in between.

Also, the fact that the  very first write fails suggests to me that
the unconfigure code should actually be located at the beginning of
the configure code, ensuring that it is always called before the
current configure code, thus eliminating the dependence on the
unconfigure call between subsequent I2C writes.

The issue still remains with the race discoverd by Max for the BackOff
code and I'm formulating the proper solution now.

Kevin

On 10/27/06, Vlado Handziski <handzisk at tkn.tu-berlin.de> wrote:
> On 10/27/06, David Gay <dgay42 at gmail.com> wrote:
> > My motivation for unconfigure was powering off a sensor: the basic
> > sensor board sensors don't have a separate arbiter, instead they
> > piggyback on the ADC's arbiter and rely on configure/unconfigure to
> > power the sensor on and off. If you don't have unconfigure, you can't
> > do this. I.e., what you're proposing (relying on other configure
> > calls) only works if all clients of the arbiter are controlling the
> > exact same set of resources (and that you're using a power manager to
> > switch the thing off).
> >
> >
>
> You are right. The proposed approach will not work for "tunneled"
> arbitration. Having the unconfigure here helps, but its semantics can become
> confusing in more complicated cases where there is n:1 mapping instead 1:1.
>
> Vlado
>
>
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
>


-- 
~Kevin