Issues with attachInterrupt

I'm having a bit of trouble getting interrupts to work on my program. An interrupt pin is set as pin2 on the Arduino Uno and the program just waits for that particular pin to go HIGH or LOW. The interrupt provides a 16 ms delay, sets an outpin pin to HIGH or LOW(depending on what transition the scanned pin makes). My issue is there is alot of debouncing when the signal is coming in, so the interrupt is able to finish its work quickly but once it goes back to the main loop, there is still debouncing occuring until it settles into one of the states(LOW or HIGH). Occasionally the output pin will set to HIGH from LOW and within an instant get set back to low because of the debouncing signal. Is there a way I can stop the debouncing from having such a major effect on the interrupt. Below is the coding of the interrupt that i'm using. Any help would be appreciated. I've looked all over the net for a solution, and figured you guys would be the best informed on this subject.

int scanPin = 2;

volatile int outInter = 9;

void setup() {

Serial.begin(9600);

pinMode(scanPin, INPUT);
pinMode(outInter, OUTPUT);

attachInterrupt(0, interFunc,CHANGE);

}

void interFunc(){

if(digitalRead(scanPin)==HIGH){

for(int i=0; i<1000; i++)
{delayMicroseconds(16);}

digitalWrite(outInter, HIGH);}

else if(digitalRead(scanPin)==LOW){

for(int i=0; i<1000; i++)
{delayMicroseconds(16);}

digitalWrite(outInter, LOW);
}

}

void loop() {

}

You refer to debouncing when I think that you mean bouncing. It is the LACK of debouncing that is causing you issues.

Interrupt Service Routines (ISR) should be designed to do something simple as quickly as possible. Delaying 16 ms does NOT meet this guideline.

Why do you need interrupts anyway? Debouncing can be handled in an ISR but it would be simpler (from a development and debugging standpoint) in code that runs in the loop() function. There is a helpful library for doing debouncing, but it will be easier to use in the loop() function.
See the Arduino Playground section for the Bounce library ( Arduino Playground - Bounce ).

You haven't explained how to tell the difference between a bounce and normal operation. What are you trying to accomplish? How is your Arduino connected? Especially, what is connected to pin 2?

When you post code, PLEASE use the # button to create the appropriate tags.

Your code is suspect. The 16 ms delay is common to both paths and should be factored out.

Your code is suspect. Is this really necessary?...

 else if(digitalRead(scanPin)==LOW){

If the value of pin 2 was not HIGH, isn't it going to be LOW?

Good Luck!

int scanPin = 2;

volatile int outInter = 9;

void setup() {
  
  Serial.begin(9600);

  pinMode(scanPin, INPUT); 
  pinMode(outInter, OUTPUT);  
  
  attachInterrupt(0, interFunc,CHANGE);

}

void interFunc(){

  if(digitalRead(scanPin)==HIGH){
    
    for(int i=0; i<1000; i++)
  {delayMicroseconds(16);}
  
  digitalWrite(outInter, HIGH);}
  
  else if(digitalRead(scanPin)==LOW){
  
    for(int i=0; i<1000; i++)
  {delayMicroseconds(16);}
  
  digitalWrite(outInter, LOW);
  }
  
}

void loop() {
 
}

PLEASE USE THE "#" CODE TAG BUTTON TO POST YOUR CODE.

My issue is there is alot of debouncing when the signal is coming in, so the interrupt is able to finish its work quickly but once it goes back to the main loop, there is still debouncing occuring until it settles into one of the states(LOW or HIGH). Occasionally the output pin will set to HIGH from LOW and within an instant get set back to low because of the debouncing signal. Is there a way I can stop the debouncing from having such a major effect on the interrupt.

Do you know what DEBOUNCING MEANS ?
If so, please define it :
Give an example.

To be a little less subtle, mechanical contacts have 'bouncing' characterization. Debouncing is the process one uses to try and deal with them using external components or software functions or both. If a switch contact is directly driving a interrupt input pin it's usually best to try and debounce the contacts externally with circuitry rather then software functions inside the ISR routine.

Thanks Retrolefty but you just defeated the whole purpose of my post. There is no mention of switches or relays or anything mechanical in the OP's post or his code, hence the attempt to determine if he knows what he is saying.

Yes, you're right. I meant bouncing. For example if I take a 5V signal and put it (physically) into pin2 on the Uno it enters the interrupt function. However, that change to 5V isn't a smooth transition and bounces a while before settling into 5V(Which would cause the program to enter the interrupt function several times instead of only once). My particular program is quite long and putting it into the main loop would defeat the entire purpose of the interrupt, since the interrupt can occur at any moment. The if statement is there because the output pin has to change from low to high if the interrupt pin measures high. The same applies for when it measures LOW.

Sorry, but you cannot use the term "bouncing" if you have no switches or hardware. If you have a timing issue, it is not due to what you are calling "bouncing". The correct term for what you are describing (which is not occurring is "ringing". All the TTL signals involved on your board meet TTL spec (meaning they don't have ringing) so there is no point in talking about "bouncing" . If for example you ran a TTL signal on a very long cable, you could have ringing due to reflected wave but that is not the case here. I'm not saying you don't have a timing issue, I"m just saying that and "settling time" should not come into the conversation unless your timing is off. It is standard procedure to put very small delays for managing timing issues but it is not because of any "bouncing" but because it is a good practice to do so. When you add switches and relays we can talk about switch bounce, which is a physical fact. We haven't talked about decoupling caps so maybe you have noise on your +5V power bus, which is noise , not bouncing. A negative spike could falsely trigger an interrupt which is why it is standard practice to have 0.1uF decoupling caps adjacent to all IC's running on +5V. CMOS (+12v) does not suffer from that vulnerability so it is not common to see such caps on CMOS circuits.

There is a wire connected to the Arduino Uno at pin2. I have a DC power supply(set to just slightly under 5V) which is connected to this wire. When i have the program running without the else if statement(just setting the output pin to HIGH, instead of HIGH and LOW), and i turn on the supply the program works as expected(So noise isn't what's triggering that pin). This is provided that I give the interrupt a significant delay time(in which case it would still be in the interrupt if bouncing is occuring).

int scanPin = 2;

volatile int outInter = 9;

void setup() {
  
  Serial.begin(9600);

  pinMode(scanPin, INPUT); 
  pinMode(outInter, OUTPUT);  
  
  attachInterrupt(0, interFunc,CHANGE);

}

void interFunc(){

  //if(digitalRead(scanPin)==HIGH){
    
    for(int i=0; i<1000; i++)
  {delayMicroseconds(3000);}
  
 // digitalWrite(outInter, HIGH);}
  
 // else if(digitalRead(scanPin)==LOW){
  
   // for(int i=0; i<1000; i++)
  //{delayMicroseconds(16);}
  
  digitalWrite(outInter, HIGH);
 // }
  
}

void loop() {
 
}

Are you telling me you are using the output of a DC POWER SUPPLY as a logic signal to trigger your interrupt ? Is that what I am to understand ?

The final design has the 5V signal coming from elsewhere in the overall circuit. The power supply was just for testing but it provided the proper functioning, so I don't see a hugh issue with that. Am i missing something?

Delaying 16 ms does NOT meet this guideline.

Doing it 1000 times is just plain stupid.

The final design has the 5V signal coming from elsewhere in the overall circuit. The power supply was just for testing but it provided the proper functioning, so I don't see a hugh issue with that. Am i missing something?

Yes. The power supply is not designed to perform like a TTL chip. It could be used , with an RC low pass filter (resistor and cap)
which results in a stable time controlled rising voltage with a time constant = RC = R X C , so 100k x 10uF = 1 Second. You can play around with the values to change the time constant but this circuit guarantees no "bounce" . A better solution would be a power on reset circuit (POR ) , which can be implemented with a simple 555 one shot timer or you could use a chip specifically designed as a power on reset like the MAX699CPA which delivers a negative (RESET-BAR ) pulse of from 140ms to 500ms duration on power up.
The advantage of this is that you are guaranteed a SINGLE NEGATIVE PULSE (NO MORE, NO LESS) where as with your dc power supply there could be hundreds of spikes or ringing or whatever. A 555 is very cheap. Here's a tutorial on the chip:
[ http://www.instructables.com/id/555-Timer/step2/555-Timer-Monostable-Mode/ ](http:// http://www.instructables.com/id/555-Timer/step2/555-Timer-Monostable-Mode/)
Here's another approach:
http://tradeofic.com/Circuit/4333-POWER_ON_RESET.html
http://ww1.microchip.com/downloads/en/DeviceDoc/31003a.pdf

The old school cheap power on reset circuit is the resistor cap I talked about . Resistor connected to the voltage input (in your case that would be the dc supply) and cap is connected to GND at one end and the other end of the resistor and cap are connected together to create the output signal where they are connected. The signal is a slowly (relatively ) rising voltage with
a curved shape to it . Here's an example of one:

MAX698-MAX699-107107.pdf (179 KB)

Thank you, I'll read up on all these. I've read a bit on the 555 timer in the past. I think the time constant is a bit too high for this program. Would it be possible to apply a resistor and capacitor such that it would operate with say, 100nF x 10k = 1ms ?