Slow rising signal on external interrupts

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATMega168, Vcc = 5v

Is a slow rising signal (10%-90% time = 25ms, start voltage 0v, end voltage 4.16v, definitely monotonically increasing) on the INT0 external interrupt (edge triggered, rising edge) likely to result multiple interrupts?

I certainly seem to be seeing them and it's causing some grief :(

Is there any config (fuses, control registers) to stop the multiple interrupts happening, or do I have to have some software "debouncing"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If memory serves, the external interrupt lines do not have schmitt trigger inputs. As such, it would not be at all surprising to see the symptoms you describe. That could mean one of two things, add external hysteresis ( a schmitt trigger ) or do software debouncing. Another way to handle it would be to simply disable the interrupt on the first edge for some amount of timeout. It would not be as "safe" as real debouncing in code, but if you know the signal is monotonic and reasonably low noise ( so it cannot hit the trigger level unless it really is rising ) it should be safe.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Martin.

Definitely multiple interrupts - strobed an output pin inside the ISR and there they were :(

Have breadboarded a schmitt trigger comparator with an LM324 and that's sorted it, although a rail-rail opamp (MCP6002, LMV358 etc) would be better.

Will also think about disabling interrupts in the ISR (safe to do ?) and re-enabling them some time later - trouble is that the long rise time problem occurs at low device rpm - at higher rpm the rise time is fine (one interrupt per rising edge) but I don't want to miss any due to the kludge for low rpm.

I expect hardware is the right answer...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't the analog comparator a better alternative ? That has hysteresus and in case that's not sufficient a SW controlled hysteresus (IO-pin and two resistors) will do the job.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With such a slow rising signal, I think I would just poll the input instead of using ext INTS. I can't see the point of having uSec. response time when the actual time that the interrupt occurs is not easily defined anyway.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would poll and when you get some number in a row with the same value, call it good. But, make sure that the poll rate is sufficiently slow relative to the rise time.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the data sheet Voltage Input Low (Vil) is -0.5 to 0.3 of Vcc, while Voltage Input High (Vih) is 0.6 of Vcc to Vcc+0.5. This would mean your INT0 input signal would have to wander back and forth at least between 0.3 of Vcc and 0.6 of Vcc to cause multiple interrupts. This is an average hysteresis of 0.3 of Vcc. If you have high frequency noise greater than the hysteresis voltage, the slow rise time in your INT0 signal would give it more than enough time to cause false interrupts. If you are not using the INT0 pin internal pull up, a pull down resistor might help create a lower impedance on INT0 to help reduce some types of noise pickup (the resistor value would depend on what drives the INT0 pin). Even though the AVR input pin is not officially a Schmitt trigger, it is specified to have hysteresis.

However, all consecutive INT0 events will only set the edge triggered INT0 interrupt flag and all of them only count as a single INT0 event until after the INT0 flag is cleared. The INT0 flag will not clear until after the INT0 vector is executed. Ideally it probably takes at least around 5 to 7 AVR cycles to enter the interrupt vector. After this time the INT0 flag is susceptible to being falsely set again by noise. The next INT0 response to a false noise generated INT0 will be after the INT0 RETI instruction. If you clear the INT0 interrupt flag (set EIFR.INTF0) just before exiting the INT0 vector code RETI, it will effectively ignore the highest frequency noise triggers that are faster then the INT0 ISR completion cycle time.

When trying to see high frequency noise sources on the INT0 pin, it takes a sensitive very good high bandwidth test instrument and you need to ensure the test probe loading does not change the noise characteristic behavior (i.e. make sure the multiple interrupt problem does not go away just because you connected the test probe). Something like an entry 20 MHz bandwidth audio or hobby scope will not do this job. If you can locate and measure any high frequency noise it will tell you what type of problem you are fighting and guide you to the best solution to the problem.

Last Edited: Sun. May 8, 2011 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plons has another reasonable option with the the analog comparator. It has relatively small hysteresis at +-30mV, but it may be enough. Still, it seems that a hardware solution is the right way to go based on the fact that you have a variable rate signal; I certainly wouldn't go about messing with the disabling the interrupt if you are going to be dealing with higher speed signals.

Depending upon what your pulse rate is, however, polling - with software debounce / hysteresis - may still be a workable option.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm...KISS maybe applies

- no interrupts
- main loop polling of the INT0 pin (PIND.3 - CVAVR) just checking if different to last time and currently high (rather than checking a flag set in a rising edge INT0 ISR)
...seems to cure the problem.

The previous INT0 rising edge ISR was very short (just set volatile flag and return) but there seemed to be no HF noise on the signal (Tek DPO2014 - 100Mhz))

More testing and understanding needed (need to see what the main loop time is, as I've never bothered to find out before) but looks promising..I don't think I really understand why I had the original INT0 ISR problem though...