Created Wed, 07 Mar 2012 19:21:16 +0000 by owendelong
Wed, 07 Mar 2012 19:21:16 +0000
I've got an adaFruit Chronodot attached to my I2C bus (pins 20/21) and am using Wire class to talk to it.
The following code:
unsigned long int getRTC_Chronodot(byte address)
{
// Expect Chronodot to be in UTC. TZ Compensation occurs elsewhere
byte hr, mn, sc, dow, dy, mo, yr;
unsigned long int ltime;
char s[5];
debug(9, "CD Wire.Begin");
Wire.begin();
debug(9, "CD Wire.Transmit");
Wire.beginTransmission(address);
debug(9, "CD Wire.write");
Wire.write((byte)0);
debug(9, "CD Wire.endTransmit");
Wire.endTransmission();
debug(9, "CD Wire.request");
Wire.requestFrom((byte)address,(byte)7);
debug(9, "CD Wire.reads");
sc = Wire.read();
mn = Wire.read();
hr = Wire.read();
dow = Wire.read();
dy = Wire.read();
mo = Wire.read();
yr = Wire.read();
debug(9, "CD Result");
}
Will freeze with Wire.EndTransmit displayed on the debug output. (indicating that the call to Wire.EndTransmission() never returned) the second time the function is called.
My best guess at this is that calling Wire.begin() a second time may be harmful to the library.
If the library developer for Wire or someone more familiar with the inner workings of the I2C library has a definite answer on this, it would be appreciated.
Wed, 07 Mar 2012 19:23:32 +0000
Suspicion confirmed... Moving Wire.begin() to setup() seems to have resolved the issue, but, I think the library should be more robust. A second initialization shouldn't cause a future endTransmission() to lock up the system.
Fri, 09 Mar 2012 09:33:12 +0000
Hi,
I have a problem quite similar with an I2C LCD. It is working well with arduino 022 but not anymore with arduino 023.
Which version are you working with ?