search

fhunleth / elixir_ale

Interact with hardware in Elixir - GPIOs, I2C and SPI
Apache License 2.0
344 stars 44 forks source link

GPIO.set_int pid, :rising still emits :falling messages #62

Closed jsimmonds2 closed 6 years ago

jsimmonds2 commented 6 years ago

Is it expected that GPIO.set_int gpio_pin_5, :rising should prevent all :falling messages ?

fhunleth commented 6 years ago

Unfortunately yes, and that's a bug.

What you're seeing is that the interrupt happens and then when the Elixir/ALE port process samples the GPIO, it has gone low again. So the content of the message is incorrect and the event really did happen.

I've addressed this issue in https://github.com/elixir-circuits/gpio. I'm going to be strongly encouraging everyone to use it as soon as we're able to release it. It's actually usable today, but the API isn't stable.

Don't get me wrong, I'm definitely not opposed to fixing ElixirALE, but if I'm the one doing it, it might take me a little bit. Help would be super-appreciated.

jsimmonds2 commented 6 years ago

Thanks. I'd love to help and will start now, though, as I'll need to read a lot of doc, it may also take me

a little bit

My reproducer is simply one output GPIO output pulsing one input GPIO input across a short wire.

jsimmonds2 commented 6 years ago

As I only have Raspberry Pi 3 B+, is it enough to fix this issue for that platform ? I need to use the GPIO Events available via the character special device driver; the obsolete gpiolib approach won't cut it, I believe.

(I have old Tessel 2, Intel Edison, Intel Joule, and MinnowBoard Turbot . . but nothing newer than that or any other Linux/ARM things)

fhunleth commented 6 years ago

If you're going to look into GPIO events, then I'd recommend submitting a PR for Elixir Circuits GPIO. I have no plans to upgrade or maintain a non-gpiolib ElixirALE, but that's not needed to fix this issue. Also, GPIO events are only supported on Linux 4.8 and later, so it would break Nerves users who aren't on the latest Nerves systems (most systems were Linux 4.4 until the latest releases).

jsimmonds2 commented 6 years ago

Ok, thanks. It was this little document that set me off looking for a contemporary solution. Quite surprised about that Linux version lag in the field. Is it common to just upgrade the ElixirALE package on those "stable" 4.4 kernel-based systems ?

fhunleth commented 6 years ago

Yeah, that's embedded Linux. There's a lot of Linux 2.6 in the field that can't be updated, and a whole lot of Linux 3.x. It is incredibly difficult to keep current with Linux - many reasons, very frustrating, and I spend a ton of time trying to keep the path smooth for Nerves users. That's actually why Nerves stuck with 4.4 for so long. 4.14 actually has at least one painful bug with wired Ethernet on the Raspberry Pi 3 B+ and I held out as long as could, but then 4.4 started bitrotting with wifi.

Anyway, my view on Elixir/ALE is that it's done. I'll certainly merge little fixes into it, but all of my effort is going to be getting ElixirCircuits out the door since it should be better in many ways, it will be a little easier for me to maintain, and I have more help.

jsimmonds2 commented 6 years ago

Got a 'little fix' for the spurious :rising, :falling edge alerts . . basically we just remember what we wrote to … gpio<nn>/edge and trust the kernel driver. The user app code still needs to debounce / understand pin state for :both

This is my first ever PR to the wonderful Open Source community, so I'm seeking some guidance on submitting 🙂

fhunleth commented 6 years ago

Great! It sounds like the fix should work since if the kernel driver is wrong, there are big problems.

I think you should create the PR and not worry about making it perfect. It's quite common for PRs to undergo 2 or 3 or more revisions. I don't think this will be the case for yours, but I find it helpful to go into the process expecting the possibility. Github has instructions on the mechanics and I'll certainly help out if I notice anything. If you have trouble, ping me on Slack.