One shot timer doesn't work always (in conjunction w/ pin IRQ)

[cristian-spiescu]

Hi guys,

I have a simple class that (tries to) handle pin input debouncing. The logic is simple: on IRQ event received, start a timer. When the timer fires, check the value of the pin, to see if it's stable. I'm using ESP8266.

The issue: sometimes the timer doesn't fire, and I don't understand why. Let's take a look at the code:

class Debouncer:
	def __init__(self, pin, cb, irqMode = machine.Pin.IRQ_FALLING, wantedValue = 0, period = 100):
		self.pin = pin
		self.cb = cb
		self.wantedValue = wantedValue
		self.period = period
		self.justCalled = False
		self.timer = machine.Timer(-1)
		pin.irq(self.irqHandler, irqMode)
		
		# seems that this is the equivalent of JS bind(), which means mem allocation, hence not allowed
		# in ISR; cf. https://docs.micropython.org/en/latest/reference/isr_rules.html#creation-of-python-objects
		self.ccb = self.timerHandler;
		# if this really means mem alloc, then I put this; because used in timerHandler, which is an interrupt
		# handler as well
		self._irqHandler = self.irqHandler;
	
	def irqHandler(self, pin):
		if self.justCalled:
			logDebouncer("Debouncer.irqHandler 1 " + str(pin))
		else:
			logDebouncer("Debouncer.irqHandler 2 " + str(pin))
			self.justCalled = True
			# even if I disable the IRQ, after this, a few more calls happen (falling into the above if branch)
			# I interpret this as these calls being queued
			pin.irq(trigger=0);
			self.timer.init(period=self.period, mode=machine.Timer.ONE_SHOT, callback=self.ccb);

	def timerHandler(self, t):
		logDebouncer("Debouncer.timerHandler " + str(self.pin) + " final value = " + str(self.pin.value()))
		self.justCalled = False
		if self.pin.value() == self.wantedValue:
			micropython.schedule(callCallback, self)
		self.pin.irq(self._irqHandler, machine.Pin.IRQ_FALLING)

def callCallback(debouncer):
	debouncer.cb();

def logDebouncer(str):
	if DEBUG_DEBOUNCER:
		print(str)

So for the code above, sometimes after irqHandler() (the branch which registers the timer), timerHandler() doesn't get called.

My hypothesis is that maybe I'm not respecting one of the rules of the ISR. In irqHandler(), maybe the logging/printing that I'm doing allocates memory? Or maybe even the timer.init() allocates memory?

I found this implementation of debouncing logic, which seems to do more or less what I'm doing. Except the printing.

Does anybody has some hints about this issue?

Thanks a lot in advance!
Cristian.

[robert-hh]

Hard to say if it is a problem with the print or the code. In such a timing critical sequence I would never print, but toggle instead a Pin and look at it with a logic analyzer. That's faster and has almost other dependencies.

[peterhinch]

I have doubts about electrical aspects of using IRQs to handle signals from switches: see my notes here. In my opinion switch debouncing is best done by polling in uasyncio and the doc I referenced offers classes that do this.

[karfas]

For me, it looks overly complicated to have callbacks/IRQs for both the button and the timer.

If you don't want to or can't use asyncio with the pushbutton function:
Why not create a periodic timer and poll the button from here ?
When the button remains in one state for N ticks, debouncing is over...

[peterhinch]

For me, it looks overly complicated to have callbacks/IRQs for both the button and the timer.

Absolutely. The easy way, for users determined to avoid uasyncio, is to have a timer run at a fixed rate. 20Hz (50ms) is fine for most switches and yet gives the appearance of an instant response. Have a variable record the last button state. On each tick compare the pin state with the last state. If they differ, update the current state and, if the new state is a press, act on the change. By the time you check again, any bouncing will be over.

[cristian-spiescu]

Thanks a lot guys!

doubts about electrical aspects of using IRQs to handle signals from switches

This was also my conclusion. I have made additional tests today, writing a much simpler program, where I'm sure I didn't make memory allocation in my handlers. And the issue was still reproducible. So my thought was using polling.

timer run at a fixed rate. 20Hz (50ms)

This was my idea also.

If you don't want to or can't use asyncio

To be honest, I didn't know of its existence. I will study asap. It seems to be what I'm looking for.

[peterhinch]

See my guide to uasyncio particularly the tutorial.

There are classes for interfacing switches and pushbuttons.

[cristian-spiescu]

Thanks!

I have already used the docs. I used Switch. The issue for me is that it doesn't let REPL execute.

[peterhinch]

See aiorepl a very new feature which allows uasyncio applications to support a REPL.

[karfas]

The issue for me is that it doesn't let REPL execute.

What exactly do you mean ?
I don't think there is a difference between running an asyncio and a "normal" program - both will run as functions/modules started from the REPL, so turning off REPL input while running.

[cristian-spiescu]

Thanks @peterhinch. Looks really good.

What exactly do you mean ?
asyncio and a "normal" program

You are right. But my program doesn't have an infinite loop. I have a periodic timer, and there I do the periodic stuff. E.g. sending "acknowledge" to Blynk, blinking my status LED that shows the user if the system is alive, etc.