Pages: [1]   Go Down
Author Topic: Is I2C working correctly on 1.5.5??  (Read 472 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi,

I can't seem to figure out what the problem is.
I can't seem to get correct results using the Wire library in 1.5.5
I've read something about being a problem back in 1.5.1.
Is it still broken?
I seem to always get true when I can Wire.available() and I seem to get always something other than zero on Wire.endTransmission() even though the device is in the bus.
Any help would be appreciated.

Thank you,
RI
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Does anyone have any comments?
All posts I read date back to 1 year ago and I couldn't get Wire library work correctly yet.
Is there any alternative for I2C on Due board?
Logged

Earth
Offline Offline
Sr. Member
****
Karma: 13
Posts: 312
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It works fine so far as I know. I'm involved with a fairly large project that uses the Arduino core with a custom Due-like board (GEVCU - an ECU for electric cars). This project includes I2C connected EEPROM and it works fine. I'm using a custom wire library but the only difference is that I enlarged the buffer to something like 270 bytes so that I could send 256 byte EEPROM pages along with a header all in one shot. So, I'd say that the wire library for Due works fine.
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Here is a simple code to test:
Code:
#include <Wire.h>


int a;

void setup() {
  // put your setup code here, to run once:
  Wire.begin();
  Serial.begin(57600);
}

void loop() {
  // put your main code here, to run repeatedly:
  Wire.beginTransmission(0X4d);
  Serial.println(Wire.endTransmission());
  delay(100);
}
You can change the I2C address to whatever chip you have available.
This example always returns 1 whether the chip is found or not....
1 means data too long to fit in transmit buffer
It should be 0 for found and 2 for not found.
Attached are some screenshots to confirm the chip is responding correctly for both not found and found.




* found.png (9.01 KB, 524x272 - viewed 20 times.)

* not-found.png (7.36 KB, 396x268 - viewed 19 times.)
Logged

White River Junction, Vermont USA
Offline Offline
Full Member
***
Karma: 3
Posts: 103
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I'll chime in....  The last time I checked Wire.endTransmission() is still broken, and as a result, utilities like I2CScanner won't work, as well as repeated starts.

You can code around these issues.  Search this forum for solutions.

I have not looked at the latest builds, so I can't say for sure if the issues are still present there.  I suppose you should scan the release notes.

-Chris
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well, the endTransmission is the least of my problems... It's just something I found along the way of trying to find out why my code wasn't working...
So, here is the biggest issue I have:
Code:
#include <Wire.h>


int a;

void setup() {
  // put your setup code here, to run once:
  Wire.begin();
  Serial.begin(57600);
}

void loop() {
  // put your main code here, to run repeatedly:
  Wire.requestFrom(0X4d,2);
  if (Wire.available())
    Serial.println((Wire.read()<<8)+Wire.read());
  delay(100);
}
In this code, I get serial print all the time no matter if the chip is found or not.
It gets worse, if the chip is found, it correctly displays the results by reading the 2 incoming bytes, but if the chip is disconnected, it starts returning garbage. For example, it returns always 65321. If I connect and disconnect again, it returns a different number.
I scanned the bus and I can see the 2 bytes coming in when the device is plugged. See attachment.
But when the device is disconnected, I do see the correct response of the bus, which is exactly like the not found picture on the previous post.
So, the hardware is indeed responding correctly with a NACK, but the library is returning me garbage that I don't know where it came from. I think the problems really lies on the Wire.available() that is always returning true.


* incoming-data.png (8.41 KB, 398x270 - viewed 17 times.)
Logged

White River Junction, Vermont USA
Offline Offline
Full Member
***
Karma: 3
Posts: 103
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yes.
No NACK detection...

Examples/solutions in the forum.
Like:
http://forum.arduino.cc/index.php?topic=182727.0
From August, and links to posts from February of 2013.

-Chris
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Cool. Thanks.
I guess it is still broken even after 1 year smiley-sad
Did you ever send a patch or merge request to the arduino team with your changes?
It would help a ton of people if the library was fixed once and for all.
I'll try to change my libs too if I can wrap my head around the low level code.
Logged

Earth
Offline Offline
Sr. Member
****
Karma: 13
Posts: 312
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

In this code, I get serial print all the time no matter if the chip is found or not.
It gets worse, if the chip is found, it correctly displays the results by reading the 2 incoming bytes, but if the chip is disconnected, it starts returning garbage. For example, it returns always 65321. If I connect and disconnect again, it returns a different number.
I scanned the bus and I can see the 2 bytes coming in when the device is plugged. See attachment.
But when the device is disconnected, I do see the correct response of the bus, which is exactly like the not found picture on the previous post.
So, the hardware is indeed responding correctly with a NACK, but the library is returning me garbage that I don't know where it came from. I think the problems really lies on the Wire.available() that is always returning true.

Oh, yes, I do think that my project exhibits this sort of behavior. If the EEPROM is on the board and responding properly then the program can get and set data. But, if the chip isn't there it still "works" in the sense that it returns data. However, as you found, it returns garbage that seems to be either random or some artifact of the hardware or software state.
Logged

White River Junction, Vermont USA
Offline Offline
Full Member
***
Karma: 3
Posts: 103
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I just pretend to be a programmer (I'm actually a EE, the most dangerous type of coder).  

It is my sincere belief that the skills of the Arduino team far surpass my own.

In addition, this DUE project of mine is on indefinite-hold.  Testing any code at this moment is not possible.

-Chris
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Ok, I went ahead and took a jab at fixing this. I kind of needed it to work or my project would just end up down the toilet and I don't want this to happen after all the time, money and effort spent in developing prototypes and everything.
I only needed to modify the Wire.cpp file.
If anyone would kindly test it out to make sure it works, it would be great.
I was able to get Wire.available and Wire.endTransmission to behave as it was on the avr platform.
There may be other functions that can be improved too, but since I don't need them, they were not touched.
So, if you run the I2CScanner, it should work. Let me know if it doesn't.
Attached are the Wire.cpp and I2CScannerDue.ino that I used to test it.

* I2CScannerDue.ino (0.96 KB - downloaded 24 times.)
* Wire.cpp (10.45 KB - downloaded 32 times.)
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

NewHobby

I've been going crazy trying to get the Due to communicate with the UDA1380 audio board.   My Pro Mini could find it, but, the Due couldn't        Not with the existing SAM Wire.cpp library.     I don't have a scope,  yet,   so i had to wire up an Arduino Scope,   at least i could see there was activity on the SDA and SCL,   but,   couldn't tell if the data was correct.   

Finally,   after weeks - about to give up and go a different route,   finally your wire.cpp     at least the scanner program finds it - finally,   now on to seeing what changes you made and see if i can read and write to the registers in the UDA 1380.   
Once i get the i2c interface working,    then i've got to deal with the i2s interface....    receiving digitized audio into the Due from the UDA1380,   processing it, and sending it back out to the UDA1380 -     this project is going to take me forever,  but, you libraries finally allowing me to complete step 1...   After weeks and weeks of bald headed hair pulling.     Thank You

The Due has been around for some time,    why has this issue not been resolved.   I found one thread where someone said that the Wire library was one of the first to be ported to the Due,    it works for simple devices  - maybe,   but totally failed on others.   Now I'm wondering how many other libraries are totally off when it come to other processors, like the Due.
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 142
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Awesome!!!
Glad it worked out for you smiley
Logged

Pages: [1]   Go Up
Jump to: