Just hooked up the MPU-9255 that has a BMP180 on board as well. First run only showed the accel/gyro address. Wasn't sure it was going to pick up the mag since its a pass thru to the accel/gyro core. It didn't pick up the pressure sensor either.

I went ahead and loaded my version of the FreeIMU lib and it read the magnetometer no problem

I then reloaded the I2CScanner and guess what - it picked up all three sensors - accel/gyro, magnetometer and pressure. Here is a shortened version of the results:

If I had to make a prediction i would not make any guarantees on the reliability of the I2C bus. Definitely think there is a problem with the I2C library. Could be related to the outstanding pull request. Wish our moderator would jump in.

Never had a problem with any other board - and not noticed it any other forum but then I never really looked. Arduino 101 is a new board and looks like they are still working out the bugs. Not sure they really did a lot of testing the way some makers would use the board. There is definitely a wearable flavor to the whats out there but that is probably because the Curie was meant for the wearable environment - I THINK.

I had a similar problem with the Intel Galileo when it first came out, I2C issues, but I think that is because of the way they implemented the I2C bus in hardware, don't think its the same design though. Haven't really used it much because of that - maybe with the libs for it the problem is fixed.

Mike

UPDATE: Ok. Did a little search and found the Due had similar I2C issues. Heres the link: http://forum.arduino.cc/index.php?topic=146802.15. Other boards seem to have the similar problems like Leonardo and all related back to the twi or wire or I2c libs.

UPDATE2 - 3/9/16. Last night it all worked fine. Now today I had to run the scanner three times to find the accel/gyro and pressure sensor. Never picked up the magnetometer. The new core did not include facchinm bug fix request. Need this fixed now.

I just did another post to try and bring it to the forefront but have not heard anything. Like you said will have to wait and see if they ever get around to fixing it. For now think I will just have to put the 101 on the side and work on something else.

Hello. I am new to this forum. Tinkering with a couple of OSEPP Uno R3+ Arduino compatible boards and several sensors/shields for the past 3 months has been great fun. So I picked up an Arduino 101 last week to check out a real certified Duino.

During comparison tests yesterday and today, I noticed a significant difference between the Uno and 101, and suspect that I2c communication speed may be the cause.

For the comparison tests, I used an Adafruit MCP4725 DAC Breakout Board that arrived in the mail yesterday. It's my first and only external I2C device, so my ability to test I2C communications is limited. The breakout is hard-wired directly to the Arduino board separately for each comparison test. Both Arduinos were powered by USB during testing (board voltages confirmed by DMM). But plugging a 9v battery into the barrel jack gives same results. As far as I can tell from the Arduino IDE, I have the latest board/core drivers and relevant libraries. Also, the following results are equivalent with IDE ver. 1.6.7 yesterday, and IDE ver. 1.6.8 today.

This MCP4725 breakout does establish communication with both Arduino boards. That's not a problem. The issue appears to be communication speed. The Uno board appears to communicate roughly 7 times faster over I2C than the 101 board. At least, that's one possible explanation for the following observations. Using Adafruit's MCP4725 library and example codes, I measured sine and triangle wave signal frequencies at the DAC's output (no load) using a reliable Fluke 298 DMM. Unfortunately, I don't have an oscilloscope to analyze the signals further. Here are the results:

Uno/101 ratio: 6.8 6.8___________________________________*Triangle wave frequency with the 101 appears to be too slow or signal is too erratic for the DMM to report Hz, so I measured and averaged three peak-to-peak cycle times (8.4sec) and calculated Hz).

Test results for both wave types are the same whether the DAC breakout is connected to the Arduino's 3.3 or 5v pins, and are also the same whether the breakout is connected to the 4/5 or SCL/SDA pins, as you'd expect.

It's interesting that my Uno results are approximately twice what Adafruit anticipates for the TWBR tweak. Maybe there's a reason for a doubling of the effect in this test application.

Given that the Quark/Curie processor is advertised to be more full-featured and faster, my assumption is that process speed isn't the issue here. Two possible explanations come to mind:

1) I2C communication speed. Is it possible that coding magic in Adafruit's MCP4725 library that's reported to increase the Amtel's I2C communication speed from 100 to 400 kHz (TWBR = 12;// 400 khz) may work for the Uno's microprocessor, but not for the 101's? If so, is there a related command for the Intel chips' I2C communication rate?

2) I2C conflicts. As far as I know, the Uno has no on-board I2C devices. The MCP4725 uses default address 0x62. I haven't reviewed documentation for the 101's Bluetooth and accelerometer/gyro devices. Might they conflict with the MPC4725, and/or might they occupy some I2C buss time? If so, is it possible to turn off Bluetooth and accelerometer/gyro when not in use?

I'm a long-term consumer/fan of Intel processors, and understand that Quark chip documentation may be available soon (this month). My questions may need to wait til then. Meanwhile one or more of you might have suggestions and/or alternative interpretations.

For further detail about the MCP4725 breakout board, Adafruit's tutorial is available at: https://learn.Adafruit.com/downloads/pdf/mcp4725-12-bit-dac-tutorial.pdf, including a link to their library and example sketches at the bottom. The triangle wave sketch (the shorter of the two) is repeated below. Obviously, please observe Adafruit's copyright and license for library and sketches).

This is an example sketch for the Adafruit MCP4725 breakout board ----> http://www.Adafruit.com/products/935

Adafruit invests time and resources providing this open source code, please support Adafruit and open-source hardware by purchasing products from Adafruit!*//**************************************************************************/#include <Wire.h>#include <Adafruit_MCP4725.h>

Adafruit_MCP4725 dac;

void setup(void) { Serial.begin(9600); Serial.println("Hello!");

// For Adafruit MCP4725A1 the address is 0x62 (default) or 0x63 (ADDR pin tied to VCC) // For MCP4725A0 the address is 0x60 or 0x61 // For MCP4725A2 the address is 0x64 or 0x65 dac.begin(0x62);

Great analysis. Think it points out that there really is an issue with I2C implementation.

Check out the first post on page 2 of this thread. It discusses changing the I2C bus speed from 100 Hz to 400Hz.

The Curie IMU should not be interfering with the I2C bus since they have it hooked up to the internal SPI bus = but I can not be 100% sure of how it is all implemented

There is another post that discusses the I2C bus speed - how to change. Just in case you want to retry.

As for the bus speed - not sure if that is the issue but I do not know enough about how this all works - it may be more of an issue on how I2C is implemented on the 101 vs the Uno. In other posts it is becoming clear that there is a lot more development work that is needed on the 101.

Thank you for your quick reply, Mike, and for those two scoops about Arduino 101 I2C bus speed changes. I obviously missed them while searching around. Will check them out and report back whether it improves results with my test setup.

Would enjoy hearing your experience with the MCP4725. There are a few options available on the net. This is a 12-bit. Others, I think are 8 or 10. My initial though was to try it out as an analog feed feed into a low power audio amp chip, but I'm a bit apprehensive after seeing how slow I2C communication is. I've read that the Due's DAC's have been used for that purpose, but have also read that an external DAC might work better.

Maybe we should start a MCP4725 thread if there is enough interest. There doesn't appear to be one yet on this forum, but there's a lot of info at other sites.

The i2c.c patch in your http://forum.arduino.cc/index.php?topic=371827.0 post had no effect on my Arduino 101 setup; communication rate remained miserably slow for both Adafruit codes. Tried to report that yesterday, but lost my draft twice due to internet connection glitches and gave up. I figured out how to turn on auto-save today.

Will give your latest Wire.h and i2c patches a try and report back.

Someday when you have time, I would enjoy hearing how you think IDE uses Intel's core libraries while compiling code, and whether IDE detects and over-rides Arduino library features that aren't compatible with the Intel core.

just posted this in another thread and re=posting here for reference: .....................................................

I modified my libraries per your post today. Could not find "i2c.cpp". Did you mean "i2c.c"?

Will test this on Uno and Arduino 101 setups with Adafruit MCP4725 breakout obard and sketches. Will your changes conflict with or overlap the TWBR adjustment in Adafruit_MCP4725.cpp lines 67 through 70? I'm wondering if this might block my test setup from showing a difference with your mods to Wire and Intel's i2c libs.

Yes you are correct for the Arduino 101 the file is i2c, my mistake - just real use to working with c++ files

The corelibs for the Uno and other AVR boards are totally different. The code snippet that you reference is for the AVR boards so there should be no affect. Also, its set up so that you have to define the TWBR somewhere in your code or the library - not familiar with the adafruit library so you would have to verify if the defined it in the library itself or you need to define it - my guess is that you can define it in the .h file of the library.

Here is a snippet of code that is used in the FreeIMU library as an example - works for AVR and Teensy:

Glad you got it somewhat working. I finally broke down and bought a cheap USB scope and just finished running some tests with it. SDA you can see a difference and the trace makes sense even though not great - probably need to reduce the pullups to 2k2 from 4k7.

SCL at either speed just doesn't look right to me. It just looks like the clock is messed up. The scope can't even get a good frequency reading. But then again I am not sure how to use a scope