Learning to find I2C addresses of sensors for Arduino Due

Rahim;

There are a couple of excellent tutorials on tronixstuff.com specifically about using I2C and Arduino.  It looks like you've already been to Adafruit, so no need to mention that.

http://tronixstuff.com/2010/10/20/tutorial-arduino-and-the-i2c-bus/

Here is a more general one on SparkFun: https://learn.sparkfun.com/tutorials/i2c

And the I2C/Wire library reference on the Arduino site: https://www.arduino.cc/en/Reference/Wire

When you're reading, the "Two-Wire" or "TWI" protocol is I2C.  Some refer to it as Two-Wire, understandably, as connections just require two wires: SDA (Data) and SCL (Clock).  A couple of gotcha's that you may or may not be aware of.  The Due is a 3V3 uC, unlike most Arduinos, which are 5VDC.  You'll need to reference (Include) the "Wire" library in your programming.  If you're using an IDE besides Arduino (Keil, Atmel Studio, etc.) then check Atmel's website for additional libraries required.

Arduino pins can sink 20mA of sustained current, or 40mA max.  Not a problem using I2C, but if you use other pins be aware of those limitations. 

Use a 9-12VDC/2A power source on the DC jack, when not using the USB port for power.  Any lower voltage and your uC may destabilize.  Much higher and the on-board voltage regulator will get too hot.  You can't really attach a heatsink as the VR is flush-mounted on the PCB.

Best of luck!

Thank you Brian Edwards!!! The link to tronixstuff is really putting things into a better prospective. Right now our team is doing its best to set up code to get the I2C sensors to Read and Write to the Arduino Due one at a time, but we are running into some issues that are holding us back from even getting one sensor to work. We know that there is a issue with the code, but we can not seem to pen-point what the issue is exactly.

So far, here is the code that we put together in bits and pieces down bellow...If you or someone else can help figure out what's wrong with the code it would be very much appreciated.

Thanks again.

Rahim M.

#include <Wire.h>

void setup()

{

   Serial.begin(57600);

   Wire.begin();

}

#define MPL3115A2_ADDRESS 0x60

void loop()

{

   Serial.println(IIC_Read(0x0C));

}

z

byte IIC_Read(byte regAddr)

{

  // This function reads one byte over IIC

  Wire.beginTransmission(MPL3115A2_ADDRESS);

  Wire.write(regAddr);  // Address of CTRL_REG1

  Wire.endTransmission(false); // Send data to I2C dev with option for a repeated start. THIS IS NECESSARY and not supported before Arduino V1.0.1!

  Wire.requestFrom(MPL3115A2_ADDRESS, 1); // Request the data...

  return Wire.read();

}

uint8_t I2CReadRegister(uint8_t I2CDestinationAddress, uint8_t Register)

{

   Wire.beginTransmission(I2CDestinationAddress);

   Wire.write(Register);

   Wire.endTransmission(false);

   Wire.requestFrom(I2CDestinationAddress, 1 );

   delay(200);

   return Wire.read();

}

void I2CWriteRegister(uint8_t I2CDestinationAddress, uint8_t Register, uint8_t Data)

{

   Wire.beginTransmission(I2CDestinationAddress);

   Wire.write(Register);

   Wire.write(Data);

   Wire.endTransmission();

}

You're welcome Rahim.

First question/observation - In your code what is 'z' in your loop?

void loop()

{

   Serial.println(IIC_Read(0x0C));

}

z      // What is this referencing?

byte IIC_Read(byte regAddr)

I'm not familiar with the Arduino [so view this as trying to help, but could well be wrong], but from the Arduino reference data you point to it looks like you aren't giving it time to do the I2C transfer.

Wire.requestFrom(MPL3115A2_ADDRESS, 1); // Request the data...

That says "go and read a byte from the I2C"

You then try to read the byte immediately with

return Wire.read();

You're working on the assumption that requestFrom blocks and execution doesn't continue until the data is in the buffer but that isn't necessarily true if the I2C stuff is running on interrupts in the background.

A quick and dirty test is to try inserting a delay(200), as in the example routine, before the return and see what that does. If that works, you can then look at how to do it properly using Wire.available, which seems to be your means to find out what's in the buffer.

Putting

do() while(Wire.available() == 0);  //loop doing nothing while there are no bytes in the buffer

before the return would be one way if you don't mind wasting the 20uS or 30uS that it would sit there.

[Hope I've got that right - I'm an old hardware engineer, so no expert with coding, though I can just about cobble together bits of C when I put my mind to it.]

If none of that works, I should put a scope on it and take a look at SCL and SDA [a scope is much the best way to debug firmware when there's hardware involved].

Good luck with your weather balloon project - sounds interesting and fun.

I'm not familiar with the Arduino [so view this as trying to help, but could well be wrong], but from the Arduino reference data you point to it looks like you aren't giving it time to do the I2C transfer.

Wire.requestFrom(MPL3115A2_ADDRESS, 1); // Request the data...

That says "go and read a byte from the I2C"

You then try to read the byte immediately with

return Wire.read();

You're working on the assumption that requestFrom blocks and execution doesn't continue until the data is in the buffer but that isn't necessarily true if the I2C stuff is running on interrupts in the background.

A quick and dirty test is to try inserting a delay(200), as in the example routine, before the return and see what that does. If that works, you can then look at how to do it properly using Wire.available, which seems to be your means to find out what's in the buffer.

Putting

do() while(Wire.available() == 0);  //loop doing nothing while there are no bytes in the buffer

before the return would be one way if you don't mind wasting the 20uS or 30uS that it would sit there.

[Hope I've got that right - I'm an old hardware engineer, so no expert with coding, though I can just about cobble together bits of C when I put my mind to it.]

If none of that works, I should put a scope on it and take a look at SCL and SDA [a scope is much the best way to debug firmware when there's hardware involved].

Good luck with your weather balloon project - sounds interesting and fun.

The do while like that is fine except if the call never works, it will loop forever. It would be advisable to add a timeout in the loop so you can exit if nothing comes back in a timely fashon

@peteroakes

Good point. That way they can report back the sensor failure if they have a radio link or log it with the data if not.

Your reminder about programming defensively got me wondering about how much the high altitude increases the possibility of soft errors. At the very least they need to have the processor's watchdog running and plan what they do if it triggers and resets the processor.

What other things could they usefully look at doing?

Well, low battery would be good, with high altitudes comes cold temperatures and batteries dont like that, the watch dog timer wont ctch that issue till the softare starts to fail, it would be good to detect these issues while you can do something about it

Insulating the enclusure for the core none sensing electronics will help alot in preventing condensation etc, but plan for it never the less

try prototypeing / testing by using the freezer at home for environmental concerns

That's a good thought Peter.  Any weather balloon I've seen (perhaps 300) has some type of heater.  NASA and NOAA use Nichrome elements, but I've seen homemade systems that successfully use Hot Hands.  Not only do the cells/batteries have problems with ambient air at 60-100F below zero, but most sensors will be pretty wonky.  Add condensation becoming ice and extremely low air pressure, and you've got a pretty hostile engineering environment.

Interestingly (at least to me) are the problems caused by cosmic radiation at 25+km altitude.  It's surprising how much damage they can do to an unhardened microcontroller.  I'm convinced that 3M developer liner-less rubber splicing tape as a substitute for metallic shielding.        Your idea of testing using the freezer is a great thought.

If I recall there were some balloon launch blogs here.

They only problem they seemed to have was the SD card falling out when the shock of the chute opened, which they cured by mounting sideways and supporting it.

If I recall they had a simple box that looked lined with no heating.

It was running a RPi so it di have more heat than other boards.

Mark