Phil,
Was the thread below ever resolved? I didn't see any follow-up posts.
Could you let me know what the status of the I2C code is for the MicaZ? In
other words, could I expect it to work with the current TinyOS 2.0.2
release?
Also, I was wondering why I cannot find any reference to Atm128I2CMasterC in
the source code documentation: http://
www.tinyos.net/tinyos-2.x/doc/nesdoc/micaz/
Regards,
Kurt
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
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
