digitalWrite() causing program (I2C accelerometer) to hang?

Using Arduino Programming Questions
1

So i have a basic accelerometer that I'm reading, and its values are supposed to turn an LED on if they are over a specified threshold. However, when the arduino exceeds that threshold and the digitalwrite command fires, the program hangs. I'm using a nano clone (chinese driver is installed) and the sparkfun LIS3DH accelerometer breakout. I've successfully read values using I2C communication, but once I try to run LED's with those values everything breaks down.
Thoughts?

Here's the Code:

#include "SparkFunLIS3DH.h"
#include "Wire.h"
#include "SPI.h"

LIS3DH myIMU; //Default constructor is I2C, addr 0x19.

void setup() {
// setup code here
Serial.begin(9600);
delay(1000); //pause
Serial.println("Processor came out of reset.\n");

//Call .begin() to configure the IMU
myIMU.begin();
pinMode(13,OUTPUT);
}

void loop()
{

float thresh = .5;

//Get sway vals:
float xval = abs(myIMU.readFloatAccelX());
float zval = abs(myIMU.readFloatAccelZ());

Serial.print(xval);
Serial.print(" > ");
Serial.println(thresh);

if (xval > thresh){
digitalWrite(13,HIGH);
Serial.println("Moving");
}
else{
digitalWrite(13,LOW);
Serial.println("Still");
}
delay(250);
}

2

However, when the arduino exceeds that threshold

Explain how it is possible for that to happen.

Thoughts?

Try adding your own LED, with current limiting resistor, and use a different pin.
Try adding more Serial.print() statements, to get a better idea where the program "hangs".

3

(deleted)

4

spycatcher2k:
Google what pins are used for SPI on the Arduino, and a solution shall present itself. :slight_smile:

The accelerometer is an I2C device. Where does SPI enter the picture?

That there was a misuse of an SPI pin was my first thought, and why I suggested using a different pin, and the device OP is using can be used in SPI or I2C mode, but the code he/she is using looks like it is in I2C mode (since the no-argument constructor defaults to I2C mode).

5

PaulS:
Explain how it is possible for that to happen.

  • A set threshold is compared against by the arduino (ie 1.23 float value). Actions happen when the input from the accelerometer exeeds it (1.5 float value)

[/quote]

PaulS:
The accelerometer is an I2C device. Where does SPI enter the picture?

That there was a misuse of an SPI pin was my first thought, and why I suggested using a different pin, and the device OP is using can be used in SPI or I2C mode, but the code he/she is using looks like it is in I2C mode (since the no-argument constructor defaults to I2C mode).

I'm using I2C mode, the #include "SPI.h" is just from the tutorial code header that I didn't bother changing.

PaulS:
Try adding your own LED, with current limiting resistor, and use a different pin.
Try adding more Serial.print() statements, to get a better idea where the program "hangs".

Same thing happens when using the onboard LED, I can keep testing other pins, but I'd like to know why this isn't working as it stands.

6
  • A set threshold is compared against by the arduino (ie 1.23 float value). Actions happen when the input from the accelerometer exeeds it (1.5 float value)

But that is not the same thing as "the arduino exceeds that threshold".

The sensor reading has. or has not, exceeded a threshold.

Same thing happens when using the onboard LED, I can keep testing other pins, but I'd like to know why this isn't working as it stands.

So we are left to guess which pins you tried. I'll guess that you tried 12, 11, and 10, and they caused problems, too.

Try some non-SPI pin, just for giggles.

And get rid of the #include statement for SPI.h, since you do not need it.

7

Switched to digital pin 2 and that solved the problem. I'd still like to know why the other pins don't work, my research hasn't yielded any reason why they shouldn't...

8

afrye:
Switched to digital pin 2 and that solved the problem. I'd still like to know why the other pins don't work, my research hasn't yielded any reason why they shouldn't...

Could you try all of the digital pins, and compile a list of the ones that cause, and the ones that do not cause, interference? Perhaps those lists will give us a clue.

9

(deleted)