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

[Max CORTIANA]

Hi all

Just an update.
I've tried Kevin's code. It continuously posts 2 tasks in order to 
stress the shared SPI / I2C channel :

task 1 - sends I2C write
task 2 - sends a packet over the radio.

Guess what... it doesn't crash.

Anyway I see you have been discussing about the problem and I would like 
to know about any update :)

- Max

Kevin Klues wrote:
>> 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
>