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

[David Gay]

On 10/27/06, Vlado Handziski <vlado.handziski at gmail.com> wrote:
> On 10/27/06, Max CORTIANA <max.cortiana at st.com> wrote:
> > Suppose a module is using I2C and it release it at the end.
> > Suppose you are totally unlucky and the radio BackOff timer fires while
> > the release is in the atomic session. BackOff procedures will run at the
> > end of the atomic block.
> > When the atomic quits, the BackOff Timer calls the ImmediateRequest
> command.
> > ouch, it gets the control even if the resource is unconfigured.
> >
> >
>
> Yes, there is a race there that needs to be fixed. However, I personally
> think that clients should not rely on the previous owner properly
> unconfiguring the resource for proper operation. The configurations after
> granted should be self contained. That is why I was opposed to the changes
> Jonathan did in his last commit where the USART is reset in the unconfigure
> calls, making the success of SetModeXXX depend on the previous unconfigure
> call.
>
> I guess, I am having second thoughts about the need of "unconfigure" in
> general. Assuming that the resource unconfiguration to a safe, low-power
> consuming state is memory-less (not depending on the way it was configured
> by the current owner), such an unconfigure can be done in the configuration
> step of the ResourceController. Do we have examples in the current code base
> for which this is not true?

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

David