[SOLVED] external interrupts spam

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Post Reply
LukeVideo
Posts: 22
Joined: Thu May 09, 2019 3:59 pm

[SOLVED] external interrupts spam

Post by LukeVideo » Tue May 21, 2019 9:18 am

Hy all,
I'm having a little difficulty managing my external interupts on a bike counter project. I use a reed switch to count the number of rotations of the wheel with a external interupt on counter 0.
I followed this post :
https://techtutorialsx.com/2017/10/08/e ... nterrupts/

I'm no expert but i already used external interrupts on arduino nano so i think i understand most of this code.

My problem is that the interrupt is triggered to many times and it "spams" the console 3 or 4 times every time i close the switch.

i use a different pin and change the IRQ to IRQ_RISING. The IRQ_RISING works better in my case the IRQ_FALLING triggered even more interrupts.

Code: Select all

reed = machine.Pin(39, machine.Pin.IN, machine.Pin.PULL_UP)
 
reed.irq(trigger=machine.Pin.IRQ_RISING, handler=callback)
I have a 220 ohms pulldown resistor on the board.

So i have many questions on how to solve this.
Can i use the same counter to add a second interrupt that checks if for a low input before handling the counter ?
Is this solvable by adding a delay/sleep to the interrupt so that it waits for a minimum of time before being re-triggered ?
Is another Pin more suitable ?

Luke.
Last edited by LukeVideo on Thu May 23, 2019 8:18 am, edited 1 time in total.

LukeVideo
Posts: 22
Joined: Thu May 09, 2019 3:59 pm

Re: external interrupts spam

Post by LukeVideo » Tue May 21, 2019 9:48 am

I modified the code to print the pin in the callback and added a 0.1 second sleep in the while statement. It kinda works.

The code :

Code: Select all

def callback(pin):
  print(pin)
  global interruptCounter
  interruptCounter = interruptCounter+1

 
reed = machine.Pin(39, machine.Pin.IN, machine.Pin.PULL_UP)
 
reed.irq(trigger=machine.Pin.IRQ_RISING, handler=callback)
 
while True:
 
  if interruptCounter>0:
    sleep(0.1)
    state = machine.disable_irq()
    interruptCounter = 0
    machine.enable_irq(state)
 
    totalInterruptsCounter = totalInterruptsCounter+1
    print("Interrupt has occurred: " + str(totalInterruptsCounter))
the output :

Code: Select all

Pin(39) 
Pin(39) 
Pin(39)
Pin(39)
Interrupt has occurred: 1
Pin(39)
Pin(39)
Pin(39)
Pin(39)
Interrupt has occurred: 2
Pin(39)
Pin(39)
Pin(39)
Pin(39)
Pin(39)
Pin(39)
Interrupt has occurred: 3 
Not the best solution but still usable...

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: external interrupts spam

Post by dhylands » Tue May 21, 2019 2:59 pm

The way that I would normally deal with this is that I would use a timer along with the pin. When the first pin interrupt occurs it would disable the pin interrupt and start a timer. When the timer interrupt occurs, then you reenable the pin interrupt. You don't want to put sleeps in the interrupt routines.

Another similar approach would be that when the pin interrupt occurs it disabled itself, sets a flag, and records a time stamp. The main program would detect the flag and if sufficient time had passed since the recorded timestamp, then it would reenable the pin interrupt.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: external interrupts spam

Post by jimmo » Tue May 21, 2019 3:18 pm

Sounds like classic switch debouncing? In addition to the software approaches dhylands mentions, have you tried adding some capacitance to the switch?

e.g. this first google result seems pretty good https://hackaday.com/2015/12/09/embed-w ... ns-part-i/

LukeVideo
Posts: 22
Joined: Thu May 09, 2019 3:59 pm

Re: external interrupts spam

Post by LukeVideo » Wed May 22, 2019 7:30 am

Thank you so much.
I'll stay with a softwre based soltuion for now, but if my prototype (and skills evolve) i'll try a hardware based debouncing.
I don't know why i assumed a reed switch wouldn't be so prone to debouncing. But again the fact that the rising edge has better behavior seems to confirm that it is subject to debouncing.

Luke.

Post Reply