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

[Jonathan Hui]

Where in the msp430 I2C driver does it unconfigure/configure between 
each read/write? Are you referring specifically to Max Cortiana's code? 
That would make more sense.

To effectively test the I2C code, you need to have an I2C device 
attached with pull-ups on the SCL and SDA lines. Otherwise, when the 
msp430 is not driving the line low, then it's just floating. I2C is a 
significantly different protocol from SPI.

--
Jonathan Hui
jhui at archrock.com


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
>