Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Interrupt ISR bounces on IR sensor

  1. #1
    Junior Member
    Join Date
    Mar 2017

    Interrupt ISR bounces on IR sensor

    Hi all,

    I have been trying to use 2 difference kind of IR sensors with Teensy (3.2 and 3.5) ISR to no avail as it bounces a lot. One IR sensor is in a coin acceptor which I have tested and is working fine with Arduino. The other kind is a general obstacle avoidance IR sensor, newly bought; I have 2 units and have tested them both with Arduino. I can't seem to make them work with Teensy ISR.

    As these sensors are not mechanical, I suppose they should not bounce when trigger.

    This is my code:
    volatile int count = 0;
    void setup() {                
      // initialize the digital pin as an output.
      pinMode(14, INPUT);  
      attachInterrupt(14, infrared, RISING);  
    // the loop routine runs over and over again forever:
    void loop() {
      Serial.print("count = ");
    void infrared()
    The problem is "infrared" got triggered like hundreds of times each time the IR sensor detect an obstacle.
    Interestingly, this same code works fine on an Arduino UNO or Mega.

    Could anyone tell me what I missed?

    P.S. I would not like to have to implement some debouncing workaround, because I will have to use many of these in my project, and would not like to disable interrupts for debouncing.

    Thanks in advance.


  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Colmar, France
    There is more information needed about your IR sensors. What you missed is the fact that Teensy is so much quicker than Arduino, so that it is more prone to reveal weaknesses of the same peripherals than a slow asthmatic Arduino...

  3. #3
    Junior Member
    Join Date
    Mar 2017
    Quote Originally Posted by Theremingenieur View Post
    There is more information needed about your IR sensors. What you missed is the fact that Teensy is so much quicker than Arduino, so that it is more prone to reveal weaknesses of the same peripherals than a slow asthmatic Arduino...
    Teensy is much quicker, that's what I suspected too. I tried running the Teensy at 24MHz to no avail. The amount of glitch is the same. Wish I had a scope to see the signal.

    Name:  tracker_sensor1.jpg
Views: 88
Size:  8.2 KB

    Its a sensor that is based off the TCRT5000 that I bought from Aliexpress. Can't seem to find the rise time in the datasheet of the TCRT5000 though.

    I have just tried the Bounce lib with a 1 millisecond delay and it works like a charm.


  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Yup, Bounce is the best way!

    The ARM hardware has pretty amazing interrupt capability. With ARM, the hardware automatically pushes about half the registers onto the stack (the half that C functions can overwrite). On Teensy 3.x, the ARM processor has two separate 32 bit buses which feed into the bus matrix on the chip, and there's a special direct path to the RAM. So while it's fetching instructions to fill the pipeline, the other bus writes out the register state to the stack. It's incredibly efficient.

    On AVR, only the program counter is pushed saved by the hardware. So with ordinary C programming, usually you end up with code that has to push lots of the registers on the stack before it can actually start doing anything. On ARM, if your interrupt code is fairly simple, it probably won't have to save any of the other registers and can immediately get to work.

    Because the ARM processor manages saving and restore the registers, it can also do a special hardware-level optimization call "tail chaining". When an interrupt ends, the interrupt controller checks if another interrupt is pending. If so, it skips restoring the registers from the stack, because it knows it will just end up pushing them right back again to service the already-pending interrupt. That next interrupt executes much sooner than it normally would have with an architecture like AVR that can't do this tail chaining optimization.

    Normally these hardware-level optimizations are great. While you can do special tricks on AVR if you program in assembly, ARM's hardware optimization allow C code to have amazing interrupt performance. Usually that's a very good thing, but with mechanical chatter it means you can get extremely fast response while the signal is changing!

  5. #5
    Senior Member
    Join Date
    Apr 2017
    I'm having the same issues with a similar IR sensor. I didn't know about the bounce lib and wrote my own checker in the ISR--basically if the last pulse was greater that some value it would count it a as a trigger. Kinda works, but not reliably. Sometimes It registers extra triggers (like 2 as opposed to one). I'll try this lib. My application is an RPM sensor where I measure the time in microseconds between triggers and compute RPM based on that. RPM doesn't exceed 500 meaning 2 ms or more between pulses.

    I've tried everything to limit bounce--even added a 0.1 uF cap on the trigger pin to soak up bounces. Is it possible that the Teensy 3.2 timer can report bad times when micros() is called?

    Thanks in advance.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts