[Tinyos-devel] Re: I2C and SPI sharing

[Kevin Klues]

The obvious easy fix is to move the unconfigure and granted calles
inside the atomic block, that way we are insured that the resource is
fully unconfigured and that the resource controller has full control
of the resource before leaving the atomic block.

The other approach would be to add a new state that blocked
immediateRequest from succeeding before the resourceController takes
control of the resource outside of the atomic block.

It is really a question of whether to make the atomic block longer
(unpredictably longer depending on the complexity of the
unconfigure/ResourceController.granted events) or to add complexity to
the state machine, possibly decreasing performance in other places.

Kevin

On 10/27/06, Kevin Klues <klueska at gmail.com> wrote:
> It;s not that it gets control of the resource after it has been
> unconfigured, but that it gets control of the resource before the
> ResourceController does, breaking the semanitcs of how it is supposed
> to operate.  I'm looking into it now... to try and figure out what the
> best fix is.
>
> Kevin
>
> On 10/27/06, Max CORTIANA <max.cortiana at st.com> wrote:
> > Hi all,
> >
> > after looooot of time, I got the problem.
> >
> > So. Let's analyze module ArbiterP.nc
> >
> > we have the command Resource.release.
> >
> >   async command error_t Resource.release[uint8_t id]() {
> >     bool released = FALSE;
> >     //call Leds.led0Toggle();
> >     atomic {
> >       if(state == RES_BUSY && resId == id) {
> >         if(call Queue.isEmpty() == FALSE) {
> >           reqResId = call Queue.dequeue();
> >           state = RES_GRANTING;
> >           post grantedTask();
> >         }
> >         else {
> >           resId = CONTROLLER_ID;
> >           state = RES_CONTROLLED;
> >         }
> >         released = TRUE;
> >       }
> >       call Leds.led0On();
> >     }
> >     if(released == TRUE) {
> >       call ResourceConfigure.unconfigure[id]();
> >       if(resId == CONTROLLER_ID)
> >         signal ResourceController.granted();
> >       call Leds.led0Off();
> >       return SUCCESS;
> >     }
> >     call Leds.led0Off();
> >     return FAIL;
> >   }
> >
> > For sake of simplicity, we could rewrite it like:
> >
> >    async command error_t Resource.release[uint8_t id]() {
> >     bool released = FALSE;
> >     atomic {
> >        ...
> >        manage the queue
> >        ...
> >     }
> >        ...
> >        unconfigure the resource
> >        ...
> >   }
> >
> > 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.
> >
> > - Max
> >
> > Philip Levis wrote:
> > > On Oct 19, 2006, at 10:22 AM, Max CORTIANA wrote:
> > >
> > >> After few days, the same problem appears..
> > >> The line in Msp430SpiNoDmaP.nc:
> > >> while( !call Usart.isRxIntrPending() );
> > >> is endless.
> > >>
> > >> It happens after a read operation on I2C is finished, Resource is
> > >> released and immediatly granted to SPI.
> > >
> > > Is there any update on this?
> > >
> > > Phil
> > >
> >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
>
>
> --
> ~Kevin
>


-- 
~Kevin