I2C Wire Library

Definitely welcome here as well. Thanks, Erik.

Tested with BMP180 sensor and works like a charm.

Somehow missed this. Awesome. Thanks for posting your results.

Any updates on I2C master?

I2C master and slave mode are both available with the Dash. You don’t need to include a library as it’s already bundled in.

1 Like

I will be using the ADXL345 accelerometer over I2C to put the dash to sleep for the “asset tracking” project Ben put up. Any advice on this? Do I need a logic level converter? I would like to turn off the Adafruit gps as well. Should I just use a ss relay or can I turn it off digitally? Thanks!

Has anyone tested any OLEDs or other displays with the included I2C library? I’m needing a small display for the Dash.

@nelson

Most Arduino code using the Dash I2C library should work. In some cases an Arduino library will have processor-specific code (like for an AVR) in it, and those calls would not work. If you link to a library you are considering I can do a quick check for AVR code.

I’m having problem running ADXL345 in DASH using Sparkfun Library using I2C connection (L03, L04).
It’s working in Arduino and Adafruit Feather boards without problem via SDA/SCL dedicated pins.
I hope you can look at the library and see if the AVR specific calls are compatible with DASH.

@arnoldvillasanta

That library and the example build just fine with the Dash. What sort of issues are you having?

Hi Erik,

I’m just getting 0,0,0 for the xyz values, and the ACTIVITY, INACTIVITY, and DROP are executed as well.
I’m using version 0.9.2 board driver (downgraded from 0.10.x because of Serial Monitor issues).

Software adjustments for INO file:
• Comment out the call to attach interrupt
• Change the interrupt pin to D05

My connections are:
SDA — L03
SCL — L04
VCC — 3.3V
GND — GND
Not using pull-up resistors for SDA and SCL
SDO not grounded
SC not connected to either VCC/Gnd

My observation:
Aside from output being always 0,0,0, The ACTIVITY, INACTIVITY, and FREE FALL is always logged. This happens with and without the ADXL345 module being connected.
(In Arduino and Adafruit, it’s usually only 0,0,0 when the module is disconnected.)

This I think should not be the case based on the condition set at:
if(adxl.triggered(interrupts, ADXL345_FREE_FALL)){
Serial.println("*** FREE FALL ***");
//add code here to do when free fall is sensed
}

From looking at the schematic for the Sparkfun breakout for the ADXL345, you’ll need to add pull-ups to the SDA and SCL lines. We don’t include those pull-ups on the Dash in case you want to you those IO for non-I2C applications. I’d suggest adding 10K Ohm pull-ups, but you can experiment with other values. Without the pull-ups, the SDA and SCL lines are always LOW, which will be read as 0.

That module (and the library) also support SPI, so you could try that instead. SPI uses directional IO instead of shared clock/data lines like I2C, so no pull-ups needed. Use pins L05/L06/L08 for SPI, along with any digital IO for chip select.

Hi Erik. Oscilloscope reads 300mV on both SCL/SDA lines without pullup resistors (I have a different board from Sparkfun ADXL345 - with pullup resistors already in there). I’m getting pulse reading from both SDA/SCL when using Arduino and ADAFRUIT feather boards, but not with DASH.
The only thing I can think of right now is with the SCL… is there clock/timing config in the library which can be an issue?

I’ll do a parallel test using SPI while waiting for the I2C resolution.

The nominal HIGH value should be 3300 mV, not 300 mV. There is a small amount of voltage on the line, and you can see the Dash I2C pulling it down to 0 for the I2C data. This is how I2C is supposed to work. The I2C device is either pulling the line LOW for 0, or letting it ‘float’, which allows a pull-up to bring it up to 3.3V. The Dash IO needs the voltage to be at least 2.7V (I didn’t look it up, but it’s around there) to register the line as HIGH (1). With I2C the devices never drives the line HIGH, because it is a multi-access bus. Masters and Slaves need to be able to pull the line down, so no device can actively drive it, hence the need for a pull-up.

This Sparkfun Guide shows pull-up resistors on the I2C SDA and SCL lines. It also notes that CS needs to be driven HIGH for I2C operation. If you have it floating, unconnected, then the ADXL345 isn’t in I2C mode.

I placed pull-up resistors to SDA/SCL pins and voltage is now consistent around 3.28 volts.
But still, output is 0,0,0.
I’ll do a parallel test while waiting for the resolution for the SPI issue.

I went back to I2C connection and I found out that:

  1. When ADXL345 is powered from DASH with SDA/SCL floating (not connected), the measurement in the ADXL pins are
    SDA = 3.28V nominal high
    SCL = 3.28V nominal high
  2. But when all pins are connected:
    SDA = .278V nominal high
    SCL = 3.28V nominal high
    This happens to my two DASH boards (260 and 270)

ADXL345 works with Adafruit Library in DASH via I2C without any glitch at first try.
I’ll stick with this library for now and hopefully will find time to see why the Sparkfun library did not work for this board.

I found the solution to make Sparkfun ADXL345 library to work with DASH in this link.

@arnoldvillasanta

Nice job tracking that down. And thank you for posting your solution. beginTransmission() initiates an I2C write, which would block the requestFrom() from working. I’m wondering if in the AVR version of the I2C library the beginTransmission() call has no effect in that situation, or is at least recoverable. I’ll do some digging on that.

You’re right in there Erik regarding the second .beginTransmission() call blocking the .requestFrom()… because the second call not ended with the .endTransmission().

I compared the Sparkfun library with Adafruit and found the discrepancy… though the Adafruit separated the .beginTransmission() and .requestFrom() in two separate code blocks.