On Apr 5, 2007, at 3:16 AM, Xiaofan Jiang wrote:
Hi all,
I'm trying to communicate with a I2C device using MicaZ (MicaZ is
the master) but have encountered some strange problems as described
below. Does anyone have any ideas?
I wrote a very simple program that basically write a byte to the
I2C device (code shown at the end). The address for the I2C device
is 0x68. The behavior of this program is that I2CResource.granted()
happens (led0 turns on), but I2CPacket.writeDone() does not happen.
From the Atm128I2CMasterPacketP.nc file, I can see that the start
condition has been completed but it is stuck sending the address.
The state right after interrupt is I2C_STARTING, which changes to
I2C_ADDR; I2C.write is called with the correct address (0x68);
I2C.sendCommand() is also called. However, there is no more
interrupt after the address is sent, and therefore the state
I2C_DATA is never entered. This also corresponds to what I have
observed on the oscilloscope - I see the start condition, followed
by the first 4 bits of the address. Then the clk stalls at low
(this is where I don't understand). The strange thing is that there
shouldn't be anything weird during the middle of a byte since I2C
is a byte-oriented protocol. I have attached a snapshot of the
signals:
http://buzzing.cs.berkeley.edu/~xjiang/webfiles/I2C_signal.jpg
The top one is the clk and bottom is the data.
Another problem is that the optimization level of the compiler
changes the behavior. To even get the I2C to produce the start
condition and first 4 bits, I had to turn optimization off (-O0).
The default Os will result in data go low then immediately stall.
Any help is greatly appreciated.
It looks like the McuSleepC code is not paying attention to whether
the I2C is enabled or not; when I tested the I2C code, it was using
an early McuSleepC that never dropped below idle.
Megan Wachs is coming up with a fix, we'll check it in over the
weekend. You can probably figure out how to do it if that's too long
-- just check whether I2C interrupts are enabled in McuSleepC.
Phil
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
