set_async_interrupt not working about rppal HOT 19 CLOSED

Thanks for reporting this issue. At first glance, I don't see any obvious problems in the way you're working with async interrupts. I'm going to try this out here as well and see what I can find.

from rppal.

FYI: Same behavior observed when compiling using https://github.com/rust-embedded/cross from my laptop as from when compiling directly on the Pi Zero.

from rppal.

I just tried the code you provided without any modifications, on a Raspberry Pi 3 A+, and both the foreground loop and the background thread correctly displayed any level changes from high to low, and low to high.

I'm not sure why this doesn't work in your situation. Some things to check would be making sure you're running the latest release of Raspbian, having PWM disabled (pwm0 uses the same GPIO pin) or trying a different GPIO pin.

from rppal.

For the sake of completeness, I ran your code on a Raspberry Pi Zero W as well (compiled on the device) without any issues, getting the expected results. The Zero is running a linux kernel from 2017, so it doesn't seem to be related to changes in any recent Raspbian releases.

from rppal.

I am in the middle of upgrading my Pi Zero W to the latest Raspbian. I will comment again once re-tested on latest.

The same pin works with some python code... lots snipped out but here is the meat of it... but this code is normally running all the time on this Pi....

import RPi.GPIO as GPIO
BUTTON_PIN = 12

def button_event(channel):
    global start
    global pressed
    if GPIO.input(BUTTON_PIN) == 1:
        pressed = False
    if GPIO.input(BUTTON_PIN) == 0:
        start = time.time()
        pressed = True

GPIO.setmode(GPIO.BCM)
GPIO.setup(BUTTON_PIN, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.add_event_detect(BUTTON_PIN, GPIO.BOTH, callback=button_event)

So I don't believe that there is an issue with using this pin. I stopped that Python code while running the Rust code.

This Pi is running reef-pi (implemented in Go) to control my saltwater reef tank. It is possible that something else in that software is in conflict. I will shut that code down to see if behavior changes.

I'll comment again with the next set of results.

from rppal.

It could be possible for another process to grab the events from the underlying /dev/gpiochipN device before the Rust code has a chance to get them, so trying the code without having anything else running could be interesting. Looking forward to hearing about your progress.

from rppal.

Running latest Raspbian and not running either the Python or Go code mentioned above... same behavior, never see the background thread being triggered.

The Python and Go code still continues to run correctly.

from rppal.

I suggest trying a different pin just to make sure there's nothing else interfering with the one you're currently using. Or if you have another Pi lying around, try running the code on there. Other than that, at the moment I don't know what else you could try.

I can't reproduce the problem on my devices, and considering you're not running into the same problem with Python or Go, it doesn't appear to be a hardware issue. My best guess would be there is still something else interfering on the software side, perhaps reading the interrupt events and/or not properly closing its access to the driver.

I will comment again if I can think of any other possible causes. Please let me know if you end up figuring out what's happening, or have any tips on how to reproduce it on another device.

from rppal.

Actually, one more possible cause comes to mind. Make sure the relevant pin isn't exported in /sys/class/gpio. The sysfs gpio interface is deprecated and shouldn't be used anymore, but some libraries still haven't moved on to the newer /dev/gpiochipN interface. While I haven't tried this in practice, it seems reasonable to assume having the pin exported through the sysfs interface while trying to access it through /dev/gpiochipN might cause issues.

from rppal.

ls /sys/class/gpio
export gpio10 gpio11 gpio12 gpio17 gpio22 gpio27 gpio5 gpio6 gpio9 gpiochip0 unexport

from rppal.

Aha! That means either Python or Go accesses the GPIO pins through the sysfs interface, and doesn't unexport the pins after the process exits. Could you try running echo 12 > /sys/class/gpio/unexport which unexports the pin and removes gpio12 from that directory (check to make sure it's really gone), and then run your Rust code again?

from rppal.

That fixes it.. thank you

Now I get to figure out which piece of code exported that.

from rppal.

Awesome! Glad we found the cause. When you do figure out which code still uses the sysfs gpio interface, I suggest either finding a different library that uses /dev/gpiochipN instead, or adding some code that unexports the used pins when the process exits. The sysfs gpio interface will be removed from linux eventually, so it's a good idea to move on to the newer interface whenever you're able to.

from rppal.

It was the RPi.GPIO python library that was the culprit. I'll be temporarily adding a GPIO.cleanup() on exit to clean up after that code so that I can develop/test a replacement in rust using rppal.

Thank you for all the help in troubleshooting.

from rppal.

Hey! I had the same issue; no interrupts triggering. There weren't any exported GPIOs in my sys/class/gpio directory either. I had to set set_reset_on_drop(false) to get the pullup resistor working (and therefore the rest of the interrupt/level reading code):

use std::{thread, time};
use rppal::gpio::Gpio;
use rppal::gpio::Trigger;
use rppal::gpio::Level;

fn main() {
	let gpio = Gpio::new().expect("Gpio new");
	let pin = gpio.get(26).expect("gpio get");
	let mut pin = pin.into_input_pullup();
    pin.set_reset_on_drop(false);

	pin.set_async_interrupt(Trigger::Both, move |level: Level|{
		println!("This never works!! {}", level);
	}).unwrap();

	loop {
		thread::sleep(time::Duration::from_millis(1000));
		println!("button is {}.", pin.read());
	}
}

Any idea why this is? I'm still fairly new to Rust. I would guess that the pin is going out of scope when we set the interrupt (hence, the move keyword). Is this accurate? Is there a better way to write this code in which the set_reset_on_drop() function isn't required? Thanks for your help!

from rppal.

Update: for some reason, that exact code stopped working. Again, same issue: it doesn't appear that internal pull-up resistors are being set (verified with a multimeter). Any suggestions would be appreciated!

from rppal.

Thanks for the report, @bblanke. I'm not quite sure why you're seeing this result. The pin can't go out of scope until after the loop, otherwise you wouldn't be able to read its value with read. I'll recreate your setup, and will let you know what I find.

Considering it used to work for you with the example you posted, and now doesn't anymore, it sounds to me like something external is interfering, but if you're not running any other software that interacts with the GPIO pins, and it isn't a hardware issue (try a different GPIO pin), we'll have to dig a little deeper. 😄

from rppal.

I have run into maybe the same issue here as well? Couldn't find any GPIO pin which would fire on an interrupt, ended up just polling the pin instead...

Funny story, I was looking at other code I had with this library and realized I have another processes running on the same Raspberry Pi which is using this library (maybe an older version I would have to check) and using interrupts and it works just fine!

Is it possible two separate processes using this same library to setup interrupts is not possible on the same device? Just a thought, thanks for the sweet library!

from rppal.

I'm running into the same issue here. The interrupt callback is never triggered. I did verify that there are no exported GPIO pins in /sys/class/gpip. There's only export, unexport and gpiochip0.

I don't know if this is relevant, but on other pins I do have an NFC reader running via SPI.

Here's my /boot/config.txt, if that helps to narrow the issue down:

dtparam=spi=on
dtoverlay=gpio-no-irq
dtoverlay=hifiberry-dac
dtoverlay=i2s-mmap

from rppal.