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

[Kevin Klues]

> What do you mean? I have used the implementation to do multiple I2C
> reads/writes between a given request/release pair. What I2C device are
> you testing against?

The issue wasn't making multiple I2C reads/writes between a
request/release pair.  It was constantly doing a request, write,
release, request, write, release.....
>
> Again, what I2C device are you testing against?

I wasn't using any device in particular.  I was using the test code
taht Max Cortiana sent out a few weeks ago.

> I believe the SPI is implemented this way too and has always been
> implemented this way ever since configure made it in to the interface.
> In my mind, checking whether the bus has been used by a different client
> or not is simply an optimization, and not fundamental to the functional
> operation of the module.

I wasnt suggesting that we should check whether the bus has been used
by anyone else.  But I also don't think that an unconfigure should be
a necessary step for getting the I2C up and running between subsequent
calls.  The configure should be able to take care of setting
everythiing up.... even resetting the USART before configuring it if
need be.

> Again, I don't believe there is a need to unconfigure between each
> read/write. If it did, we wouldn't be able to support repeated starts.

At least using Max's code, if the all we have is a single I2C client
that does the request, write, release combination over and over again,
the first one gets signaled with an error==FAIL, and the rest of them
succeed from then on.  That said, if the code in the unconfigure block
is commented out, only one write succeeds, and the system locks up
somewhere.

With all of this said, however, and after a few hours of digging, I am
actually not able to reproduce the original bug that Max brought up.
With or without the unconfigure/ResourceController.granted() events
inside the atomic block.  For me, both the I2C and the Send interfaces
seems to be interacting as expected.  The race condition he pointed
out was real, however, and for now the Arbiter has been updated to put
these events inside of the atomic block pending further discussion on
the need for unconfigure and the semantics of
requests/immediateRequests in general.  I think this is sufficient for
the release, as (I hope) all existing code should work despite this
change, and the race condition should be eliminated.

--
~Kevin