Open wurtel2 opened 4 years ago
I'll have a look today and figure out what's going on.
On Wed, Sep 25, 2019 at 12:00 AM wurtel2 notifications@github.com wrote:
I have the following little perl script; the problem is that whether GPIO 4 to GPIO 17 changes state, only the last configured interrupt handler i.e. pin17_interrupt_handler is called.
This makes it a pain to determine which GPIO actally changed state. Am I doing it wrong?
Thanks.
use RPi::Pin; use RPi::Const qw(:all);
my $pin4 = RPi::Pin->new(4); $pin4->mode(INPUT); $pin4->pull(PUD_UP); $pin4->set_interrupt(EDGE_BOTH, 'main::pin4_interrupt_handler');
my $pin17 = RPi::Pin->new(17); $pin17->mode(INPUT); $pin17->pull(PUD_UP); $pin17->set_interrupt(EDGE_BOTH, 'main::pin17_interrupt_handler');
while (1) { sleep(1); }
sub pin17_interrupt_handler { my $state = $pin17->read; print "\ain interrupt handler 17: state $state"; sleep 0.2; print ".\n"; }
sub pin4_interrupt_handler { my $state = $pin4->read; print "\ain interrupt handler 4: state $state"; sleep 0.2; print ".\n"; }
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stevieb9/rpi-pin/issues/6?email_source=notifications&email_token=ADDQEP2CXYPG73QS7HSYQFLQLMECNA5CNFSM4I2ISQYKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HNQHVXA, or mute the thread https://github.com/notifications/unsubscribe-auth/ADDQEP6CZ5AFUYFTOHYGGX3QLMECNANCNFSM4I2ISQYA .
anything new on this issue? I've been running in the same problem.
No updates. To be honest, I've fallen onto extremely hard times, and am struggling to keep my family afloat, so I will be of no help on this issue.
Unless someone steps up to offer help, it is very unlikely that this will be fixed any time soon.
I'm deeply sorry.
On Fri, Aug 14, 2020 at 5:49 AM Dr. Andreas Schmitt < notifications@github.com> wrote:
anything new on this issue? I've been running in the same problem.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stevieb9/rpi-pin/issues/6#issuecomment-674058114, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDQEP334WXLNCUFSUE64TDSAUXGBANCNFSM4I2ISQYA .
This appears to be a limitation of WiringPi::API. Sadly, if your design requires multiple momentary switch closures, you can only have one. Issues like this are driving builders to Python.
As of oktober 9th 2023: Same issue here Bummer, was kinda glad I could program a Pi using Perl. But for me this is a show stopper. Wish I had the know how to fix it but I don't
I changed my program to poll the inputs. In my application the switch closures won't be less than 10 seconds so not an issue for me.
Did not expect a reply on this... how nice :D So in effect you create your own interrupt, that would be an idea. In my case it should be a pulse. It's for a gardenpump starting a manual sequence. Guess I would have to press the button a bit longer. Thinking out of the box, nice. Started looking at Python yesterday. Everybody thinks its readable and simple... but I got stuck on missing fetchrow_hashref :D
@stevieb9 Sorry to hear about you problems. Hope you solve them.
Reading up on other open issues it seems interrups could use some attention. In issue #8 (I think it was) someone did in fact offer to help. Would be nice if this fine project would get afloat again.
I have the following little perl script; the problem is that whether GPIO 4 to GPIO 17 changes state, only the last configured interrupt handler i.e. pin17_interrupt_handler is called.
This makes it a pain to determine which GPIO actally changed state. Am I doing it wrong?
Thanks.