I am looking to increase the I2C clock speed for better I2C throughput.
I see lots of posts about how to do this for the various arduino variants. It appears that some Wire libraries have a Wire.setClock() function that works, while others suggest changing twi.h file in the library to increase the speed.
None of these seem to apply to the 101 though.
I looked in C:\Users\xxxxx\AppData\Local\Arduino15\packages\Intel\hardware\arc32\1.0.4\libraries\Wire
and found Wire.h file.
There does not seem to be any reference to a clock speed in the file.
Hi,
the Wire library ported to 101 doesn't contain a setClock() function; you can change the interface speed by navigating to Intel\hardware\arc32\1.0.4\cores\arduino\i2c.c -> function i2c_openadapter() and change
i2c_cfg.speed = I2C_SLOW;
into i2c_cfg.speed = I2C_FAST; (400khz)
I'll open an issue on github to add that function and it will probably be included in next core update. Thanks for the report!
You can see a scope trace here, with the clock in red. It is now around 317 kHz, and appears to have some capacitance as it isn't very square wavey, and doesn't make it all the way to 3.3V.
I hooked the same slave up to a raspberry pi, and used its I2C decoding. It must have different pullup resistors, as the clock trace looked much better.
I performed the initial test without any load and the signals looked good.
Adding a peripheral shows the issue you are experiencing; by adding an external 4K7 pullup resistor to both SDA and SCL lines I was able to get a nicer (and faster) signal.
Hope it helps!
For slow i2c clock just use wire.begin() or wire.begin(false).
For fast i2c_clock just use wire.begin(fast)
It compiles with no problem but not 100% sure its taking. I don't have a scope so I can not test. Hope someone can verify and maybe we can get them to incorporate it.
Mike,
I've tried implementing your Wire.cpp, Wire.h, i2c.h and i2c.c changes in .....1.0.5\Libraries\ and ......1.0.5\cores\ on two Win7 PCs. In both cases, the IDE sketches (including the blank sketch) will not compile. Error message: "exit status 1 Error compiling for board Arduino/Genuino 101".
Hoping to figure this out and see if my DMM's frequency counter will confirm a speed change at SDA and SCL pins with 4k7 pull-up resistors per facchinm's Jan 19 post. Please check your instructions.
Just checked and the changes look correct. If you scroll up in the compile window there should be a more detailed message on where the error is, I hope.
Mike
PS Just to recap the changes::
In wire.h you should have the following two lines for wire.begin():
void begin();
void begin(bool i2c_speed);
In wire.cpp it should read for the TwoWire.wire.begin functions:
First, I hadn't noticed IDE's compile window scroll-up feature. It's very useful to know.
Second, with your help, I located the library recoding problem: i2c.c line 102 needed to change from i2c_openadapter(void) to int i2c_openadapter(bool i2c_speed).
Once the modified i2c and wire libs were compiling, I tried replacing TWBR references with wire.begin() and wire.begin(fast) in Adafruit's library for the MCP4725 DAC breakout. This produced two error messages:
'wire' was not declared in this scope, and
'fast' was not declared in this scope
These errors went away when I changed to twowire.begin, which I noticed was more obviously defined in the library code. I don't know enough C and C++ to know why. In any case, fast and slow doesn't change performance of Adafruit's MCP4725 sketches, not a bit.
Unfortunately, I was unable to find a signal to measure frequency at the SDA and SCL pins with my DMM. Need to get a scope someday soon (I hope).
After reviewing Adafruit's MCP4725 sketches further, I realized today that communications with and output from the DAC are much faster than previously thought. The speed of voltage changes in DAC output is dependent on code complexity, I'm seeing DAC output speeds high as 27,414/sec using the Uno, and 4,023/sec using the Arduino 101 with a test code that simply flips between high and low with no delays.
I can't seem to get the 101 anywhere close to the Uno's performance with this i2c DAC. Coding to change i2c frequency makes no difference, but it might when Intel core libraries get fixed. Since the observed difference between Uno and 101 with this DAC are much greater than a multiple of 4, though, it may be that differences in processor, I/O speeds speeds in the two Ardino variants are at play. Is it possible that the 101 isn't as fast as the Uno overall for certain tasks?
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
Think I am done with this board for a while until someone from Intel lets us know whats going on with I2C, not sure anymore if the internal SPI from the IMU is interfering with the I2C timing.
As for the uno being faster for some tasks, don't know. Think it may be more of a maturity of the board.
UPDATE: After I posted this thought I would just test the 5883L by itself without the BMI160. Guess what - now the 101 does not even find the magnetometer.