Irq flags

[sadsyndrome]

Hi. I’m trying to write a very simply python script to monitor a GPIO input from an LDR that detects light.
My program is working using debounce in the callback function but I am very confused by the irq flags fucnction. There are lots of interrupts caused by the hardware implementation I guess, but the values of the flags() function is very odd. I understand that the register sets decimal 4 as falling edge and rising edge as 8. Also the documentation says the flags are reset to 0 after callback function has completed.

I am seeing a flags() result of 12 ( I assume this is BOTH rising and falling edge? Also the flags returns 12 in the main program AFTER leaving the callback function. Does anyone know why?

I would like to use the status from flags() of rising or falling edge in my program but with these results cannot do so.

[andrewleech]

How is the LDR connected? I'd normally think of them as an analog signal that you'd need to read with an ADC or comparator?

If the analog signal is wired direct to pin digital input I'd very much expect it to "bounce" a lot as it crosses the low to high threshold and vice versa, triggering multiple interrupt signals.

That being said if it's fast moving enough you could still treat it like a pushbutton which typically has a similar bounce issue.

There's some great examples of debouncing switch inputs with asyncio here that might work for you: https://github.com/peterhinch/micropython-async/blob/master/aswitch.py

[sadsyndrome]

thx. I have the ldr feeding base of transistor as part of potential divider. Transistor collector to gpio via 10k resistor. I've successfully implemented bounce measures in code but I'd still like to understand why the irq.flags() func is returning values of 12 (that 8 and 4 for rising AND falling) and also outside of the callback function? I read that the register provides the source of the irq so should be 8 or 4? Also I read that the flags() are set to zero on leaving callback function. I can't find any detailed info on it. I also just read that Pin16 can't be used with IRQ... sods law that's what I'm using:) Mind you it is working just not with the correct trigger setting or correct flag values...

[andrewleech]

Both flags being set likely just means that rising and falling edges have been detected even better the IRQ callback can be carried (these things take a few clock cycles at least). That's expected when there's a noisy/ analog signal on the pin - a transistor will speed up the transition from low to high but - it will still likely have a fairly slow transition between high/low states relative to the CPU clock speed.

[peterhinch]

Interrupts are the most misunderstood feature of MicroPython. They should be reserved for applications where very fast responses are required. Further, unless the signal causing the interrupt has fast edges (<1μs), behaviour of the host silicon is indeterminate. For slowly changing sources a hardware Schmitt trigger should be used.

It is usually simpler to poll the input using a task in asyncio. This avoids the many pitfalls in the use of interrupts. See asyncio tutorial. You might also consider using the ADC with an asynchronous driver such as this one.

[rkompass]

Given you observe contact bounce, which @sadsyndrome obviously has, I think there might be an alternative to using asyncio:

You should be able to achieve similar functionality with a short series of scheduled checks of the pin value. Which would probably do the same as Peters class (caveat: I didn't study that class thoroughly).

Idea: ISR is called upon changing (rising or falling edge) gpio, saves the pin value, deactivates the interrupt and re-schedules itself to check a few times later (a few milliseconds) whether the pin value has changed or not. Re-activates the interrupt once the pin value is found to be stable.
That could save a few bytes, in case you do not want to use asyncio somewhere else, and might achieve the same.
Perhaps it also would mean a lower learning threshold for beginners.

[sadsyndrome]

thanks for all input. I decided to go back to basics and just read pin values in a loop with delay. I also removed transistor so now have a simple voltage divider with LDR tied to 3.3 and through a pot and other resistors down to gnd. Mid point to gpio via 330R.
The reason I did this is that I have a another very strange issue. When the dim LED is detected by LDR the picoW more often than not immediately restarts?? Resistance in region of 60-80k Ohms when light on. The LDR is connected via a 12" length of twisted Cat5 cable.

I have tested this simple circuit with a 60K resistor in place of LDR ON and 1M to replicate LDR off and all works as expected??

Any ideas
?

[andrewleech]

That sounds more likely to be a software issue / crash but hard to know.

I would still recommend using ADC to read an LDR, just reading the analog value as a pin input is likely to be quite unstable relating to what brightness triggers the input.

[peterhinch]

Yes. Reading an analog value on a digital pin is a no-no. Options are to use an ADC or to provide a Schmitt trigger.