I have a sensor project and I use all but one (pin 2) of the Nano's pins.
Since this is INT0, I was wondering if anything might be using this pin, making it unreliable for my project.
Here is what I have connected or in use on the Nano:
0 and 1 - nothing connected, but I understand that they are reserved for Serial, which I use in my project
2 - the problematic pin
3 - digital sensor
4, 5, 6 - LEDs
7, 8 - digital sensors
9 - DHT11 digital humi/temp sensor
10, 11, 12, 13 - ENC28J60 Ethernet Card
A0 - digital sensor
A1 - digital output (buzzer)
A2 - LED
A3 - digital output (relay)
A4 and A5 - BMP085 temp/pressure sensor
A6 and A7 - analog sensors
Everything works well and I have no issues with my project, with the exception of connecting (moving) any input or output to pin 2.
If I do that, things stop working. Well, not the Ethernet, so SPI is still good and not Serial.
But I2C on A4 and A5 or any of the other digital inputs may be affected.
I can't find any common denominator so I decided to post this message.
Many of the examples I found for DHT11 call for pin2 to be used, so I assume even though it's INT0 it should still work.
But because of my setup, I wonder if INT0 is being affected by my other devices that are connected.
Since it might be software, here are the libraries that I included:
SPI and UIPEthernet for the ENC28J60 module
DHT for the DHT11 sensor
Wire, Adafruit_sensor and Adafruit_BMP085_U (unified) for the I2C sensor.
Any suggestions would be greatly appreciated.
It would be nice to have another pin available, as I am completely out.
But my main reason is to understand why this is happening.
That it's INT0 has no effect unless you have the INT0 interrupt enabled - do you have anything that might be trying to look for an interrupt on that pin?
Check EIMSK - if bit 0 of EIMSK is 1, that means something has enabled INT0, and would explain why stuff happening on that pin breaks stuff.
Also check PCMSK2, bit 2 (the third bit, 4's place - zero-based indexing)
(ie, check (EIMSK & 1) and (PCMSK2 & 4) - if either of those aren't 0, there's something with an interrupt set on that pin - it's something in your code or a library you're using, if so)
BTW, I don't mean any disrespect so please let me know if you dislike 'Doc'.
I must sound more competent than I really am, as I need to research these registers. Thanks for putting me on the right track.
There are no interrupt calls in my program, unless the calls into the functions that use either of the devices make use of any interrupts.
I actually suspect the BMP085 sensor, as it was one of the last ones I added before I noticed things going bad. It is connected to the I2C pins.
As a note, am I incorrectly referring to pin 2 as INT0? As in zero? Pin 3 is INT1, so I thought...
Arduino-pin 2 is INT0 - and (short of a wiring issue), that or the PCINT18 the only functionality on that pin that I could imagine making unexpected things happen (i mean, It's pretty much the only special functions of pin 2). Note that unless the appropriate bits in EIMSK are set, though, the INT0 functionality isn't active, and so shouldn't be interfering (likewise with the PCINT and PCMSK2). If the interrupts aren't enabled, then we're back to a mystery as to why it might not be working.
Just for the sake of closure, this might have been caused by pushing the limits of the RAM. I was getting the warning, but everything else was running fine and that is why I ignored it.
Reducing the code and optimizing it seems to have helped with the instability.
I will try the exact same sketch and pin configuration on a Mighty and report back.