Go Down

Topic: i2c + DUE don't talk!! (Read 7491 times) previous topic - next topic

psycho82

Hi, I can not use the GY-521 sensor on Arduino Due. I followed this i2cScanner example sketch (http://playground.arduino.cc/Main/I2cScanner. Uxy1uPl5PuN) without results, the device is not recognized. I connected the sensors (SDA-SCL) 20-21. With Arduino Uno I have not encountered any problems.
Someone who has already used the i2c with Arduino Due can help me?

chriskner

#1
Mar 10, 2014, 07:33 pm Last Edit: Mar 10, 2014, 07:34 pm by chriskner Reason: 1
psycho82,

I2CScanner does not work with the DUE.  Search this forum for alternatives.

Also, there's a big warning about the GY-521 I2C pull-ups.  
http://playground.arduino.cc/Main/MPU-6050#
Be careful with low-valued pull-up resistors and the DUE board, as it's easy to burn up the DIO.  The DUE already has 1k pull-ups on the I2C lines.

Good luck,

Chris

psycho82

My sensor has 2 pull-up resistors of 4K7 on SDA and SCL as UDOO on pin 20-21. On schematics I see that SDA1 and SCL1 (pin 9-10 on J21 HEADER 10F) has no resistors. I need to use those pins for mi sensor. With Arduino Due, SDA1 and SCL1 are used through the Wire1 of the Wire.h library.
For example if i want use i2cscanner for SDA1 and SCL1:

Code: [Select]

/*MORE CODE*/
void setup()
{
  Wire1.begin();

  Serial.begin(9600);
  Serial.println("\nI2C Scanner");
}
/*CODE CODE CODE*/


Is this right?

My sensor i powered by 5V, but it have a built-in voltage regulator that produce high logic values ??at 3.3v. The led on board (of my sensor) blinks but my sketch does not recognize it. I doubt that I can not use SDA1 and SCL1, but that is using SDA and SCL.

noteforsteve

#3
Mar 17, 2014, 01:02 am Last Edit: Mar 17, 2014, 03:34 am by noteforsteve Reason: 1
Wire on DUE is broken.  The DUE hardware works correctly, the Wire implementation is the problem.  There are many problems, so a one line fix is not possible.  I know this because I experience problems with Wire / I2C communication on the DUE hardware.  I have a working piece of code after reading the Atmel SAM3X datasheet.  Unfortunately my code is not Wire interface compatible.  When it is ready for prime time I will share.    

Palliser

psycho82,
I think your GY-521 is the same MPU-6050. Am I right? Thus, you shouldn't have problems using GY-521 with 3.3V. It should be useful if you post the whole code you are using.

The whole Wire (I2C) code of DUE is clean and handles both Wire(I2C) peripherals inside SAM3X8E. I ran several tests the past weeks with three gyros (none of them MPU-6050) and all of them ran OK with both DUE's I2Cs. The team Atmel/Arduino did a good job.

A couple of things to be considered when using gyros with DUE:
1. Use pull-up resistors only for the TWI1 (SCL1/SDA1). And like Chris said, you don't need pull-up resistors with TWI0 (20-21).
2. Maximium I/O voltage is 3.3v

One of my gyros tests: Parallax Gyroscope Module 3-Axis L3G4200D.

PIN CONNECTION:
DUE--------- GYRO
3.3V----------VIN
GND-----------GND
SDA(20)-------SDA
SCL(21)-------SCL

Here the code I used for the L3G4200D.

Code: [Select]
#include <Wire.h>

#define CTRL_REG1 0x20
#define CTRL_REG2 0x21
#define CTRL_REG3 0x22
#define CTRL_REG4 0x23

int Addr = 105;                 // I2C address of gyro 0x69
int x, y, z;

void setup(){
  Wire.begin();
  Serial.begin(9600);
  writeI2C(CTRL_REG1, 0x1F);    // Turn on all axes, disable power down
  writeI2C(CTRL_REG3, 0x08);    // Enable control ready signal
  writeI2C(CTRL_REG4, 0x80);    // Set scale (500 deg/sec)
  delay(100);                   // Wait to synchronize
}

void loop(){
  getGyroValues();              // Get new values
  // In following Dividing by 114 reduces noise
  Serial.print("Raw X:");  Serial.print(x / 114); 
  Serial.print(" Raw Y:"); Serial.print(y / 114);
  Serial.print(" Raw Z:"); Serial.println(z / 114);
  delay(500);                   // Short delay between reads
}

void getGyroValues () {
  byte MSB, LSB;

  MSB = readI2C(0x29);
  LSB = readI2C(0x28);
  x = ((MSB << 8) | LSB);

  MSB = readI2C(0x2B);
  LSB = readI2C(0x2A);
  y = ((MSB << 8) | LSB);

  MSB = readI2C(0x2D);
  LSB = readI2C(0x2C);
  z = ((MSB << 8) | LSB);
}

int readI2C (byte regAddr) {
    Wire.beginTransmission(Addr);
    Wire.write(regAddr);                // Register address to read
    Wire.endTransmission();             // Terminate request
    Wire.requestFrom(Addr, 1);          // Read a byte
    while(!Wire.available()) { };       // Wait for receipt
    return(Wire.read());                // Get result
}

void writeI2C (byte regAddr, byte val) {
    Wire.beginTransmission(Addr);
    Wire.write(regAddr);
    Wire.write(val);
    Wire.endTransmission();
}
teI2C (byte regAddr, byte val) {
    Wire.beginTransmission(Addr);
    Wire.write(regAddr);
    Wire.write(val);
    Wire.endTransmission();
}


Regards,
Palliser

Palliser

psycho82,
I tested a MPU-6050 (borrowed) with Arduino DUE (TWI0) using one example of Jeff Rowberg library (MPU6050_DMP6) and it worked OK. I only had to comment the following line:
Quote
//TWBR = 24; // 400kHz I2C clock (200kHz if CPU is 8MHz)


Again, I can bear witness to the fact that the Wire library for DUE works OK with four different gyros. If you still having troubles, post your code, schematics, etc.

noteforsteve

That is great folks are finding Wire works for them on the DUE hardware.  This was not the case for me, and after reading a number of forum threads related to I2C on the DUE hardware I realized I was not the only one.  So I dug deeper.    Studying the Atmel SAM3X datasheet showed me why my I2C was not working with the Wire implementation.   That is why I indicated in my last post that Wire is broken on DUE.  It is possible other folks are not running into the same issues.     



chriskner


That is why I indicated in my last post that Wire is broken on DUE.  It is possible other folks are not running into the same issues.     


If I can chime in here... I2C on the DUE is not exactly broken... It's just not complete.  The way that the SAM chip handles the I2C registers (at the hardware level) is different than the other Arduino's.  This breaks some of the default functionality of the Wire library.

I suspect that it became too much work (with too little time) to make the entire default library work, so they hobbled it, to make it function at a very basic level (with no warnings about its short-comings).

The end-result: one needs to dig a bit to determine if the I2C hardware that they wish to use will work with the lame default wire library.  Some will work, some will not.  These limitations have been listed, discussed, and fixed by members of/in the forum.

However, I believe that the default & official wire library has still not been updated.

The ghosts, my friends, are in the details.

Regards,

Chris

peter224722

I2C works with me , unless you need to use the error returns form Wire.endTransmission(), But the main part works .

chriskner


I2C works with me , unless you need to use the error returns form Wire.endTransmission(), But the main part works .

Yes... If I remember correctly, anything that relies on a NACK detection will fail.  NACK is not only used by the I2C spec as a means to detect an address that is not responding, but it is also used for certain protocols (like repeated starts..).  This is not as unusual as it sounds (many ADC's and DAC's use this type of protocol).  One simply must check the datasheets carefully to see what's required by your I2C device.

So, we're currently in a situation where some I2C devices work on most other flavors of Arduino's, but perhaps not on the DUE.  This is where much of the confusion over I2C with the DUE comes from.

So, simply saying that the wire library works, or doesn't, isn't enough.  The I2C protocol is just not fully supported with the current default library for the DUE.  This is not necessarily an awful thing.  However, it can be disappointing (and a little warning would have been nice).

-Chris

Palliser

The inherited TWI DUE library offers some good functions who can be used as 'breakpoints' to 'debug' the code. For example, TWI_ByteReceived and TWI_ByteSent allow you to see if a byte has been received/sent or TWI_TransferComplete to see if the transmission is complete. I have used them few times. I prefer Atmel Studio with SAMICE. A logic analyzer or a scope can also be useful to check the clock(SCL). In other words, like I say, DUE is a monster and sometimes you need more than a whip and a chair to tame it.

peter224722

When I was using the Uno I had a alternative I2c library for avr chips, But I guess that is the problem with arm based arduino`s limited libraries.   

Heievacheza

Hi everybody,

Sorry...There are so many forums regarding Arduino Due secondary I2C pins problem. I don't know where exactly I should post my problem. I have tried of them so far, but no reply.

I'm trying to connect three MPU6050 sensors to Arduino Due to read raw acceleration and angular velocity. I connected two of my sensors to SDA and SCL (pins 20 and 21) and got both of them to work. I mean I can read data from both of them simultaneously using primary I2C pins of Aruino Due and it works well.

However, for the third sensor, I have used secondary I2C (SDA1 and SCL1) pins but it always shows 'MPU6050 connection failed'.
I don't know what to do. For the sketch ('MPU6050_raw' written by Jeff Rowberg) I have replaced all wire....() with wire1....() but it is still not working. I also used pull up resistors, but no success!

On the other, when I use 'address scanner' sketch on SCL1 and SDA1, the Arduino Due recognizes the address of third sensor. It means that they can communicate with each other. But I don't know why I can read data!

I will be grateful if somebody helps me with this.

Michael Myers

This is probably of little help, but I wound up writing my own "mini-wire" library. But only after a great deal of study of twi.c and related code files in samlib. Note well that wandering around in samlib is not for newbies.

A relatively simple example:

Code: [Select]
boolean i2c_send( uint8_t address, byte *buf, int len )
{
  TWI_ConfigureMaster( TWI1, 400000, VARIANT_MCK);
  TWI_StartWrite( TWI1, address, 0, 0, buf[0]);
  TWI_WaitByteSent( TWI1, 100000);
  int sent = 1;
  while (sent < len)
  {
    TWI_WriteByte( TWI1, buf[sent++] );
    TWI_WaitByteSent( TWI1, 100000 );
  }
  TWI_Stop( TWI1 );
  TWI_WaitTransferComplete( TWI1, 100000 );
 
  return true;
}

sterks

I'm looking for an update on the Due TWI library "completeness".  Anyone out there know if anyone is working on this???

For now I am working around the problem with not being able to use the I2C (both main or alternates) DUE interfaces to my OV7670 camera module by using an extra UNO board's I2C to configure the camera (with level converters - ugh).  But eventually I would like to eliminate needing the extra uC board and circuitry in my design.

I cant seem to find the post I saw back in Sep-Oct where a hopeful poster said he would post a "complete" wire library for the DUE when he got it done -- If you are out there, please help all us DUE folks who happen to have bought a DUE which is not compatible with the latest wire library in 1.5.8.
 

Go Up