Without watching the bus itself it is very hard to tell what is going wrong.

The original TinyOS I2C drivers as far as I know were developed without
looking at the bus traffic.

I've rewritten the I2C drivers for the x5 series of chips (msp430f5438a,
6xxx, etc) and have verified under various circumstances the proper
functioning of the driver using a logic analyzer observing the bus with the
driver talking to various i2c devices that I'm using.

The rewrite also includes the implementation of the I2CReg interface which
provides a non-interrupt driven interface to accessing i2c devices that
implement a register symantic.  Non-interrupt because for short
transactions the overhead of interrupts isn't worth it.   Also because of
the h/w structure of the i2c h/w, interrupts seriously complicates the
proper functioning of the interface.   (The data path is double buffered,
but the control path isn't, not sure what they were thinking when they
designed that, but it is what we've got).

I sorted out the various issues with the data and control paths using the
less complicated I2CReg code then applies what I learned to building a
robust interrupt driven I2CPacket code.  However, there are probable race
conditions in a heavily loaded system that presents systemic problems for
the interrupt code because of the fundamental h/w issues with double
buffered data and single buffered control paths.   So I've fixed I2CPacket
(interrupt driven) as far as I could and added a robust I2CReg interface
that should always work.


This driver is in the tos/chips/msp430/x5xxx/usci-v2 directory of the
tp-master branch (default) of
gh:tp-freeforall/prod(tp-master)<https://github.com/tp-freeforall/prod>
.


Porting the usci-v2 driver to the x2 chips should be reasonably easy.
Porting to x1 (1611) will be more difficult.   See
tos/chip/msp430/{00_Chip_Notes,01_Dependencies,02_Serial} for details about
differences.




On Tue, Feb 12, 2013 at 8:03 PM, He Dajiang (I2R) <[email protected]>wrote:

> Hi again,
>
> I used the following method to change a register value:
>
> buff[0] = registerAddr;
> buff[1] = value;
>
> call I2CPacket.write(I2C_START | I2C_STOP, deviceAddr, 2, buff);
>
> The I2CPacket.writeDone is triggered and error_t is SUCCESS.
> Somehow, after writing, when I read from that register, the value is still
> the old one.
> What could be the reason? Thx.
>
> Institute for Infocomm Research disclaimer:  "This email is confidential
> and may be privileged. If you are not the intended recipient, please delete
> it and notify us immediately. Please do not copy or use it for any purpose,
> or disclose its contents to any other person. Thank you."
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>



-- 
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to