WiringPi / WiringPi-Node

Node.js bindings to wiringPi
334 stars 94 forks source link

wiringPiISR triggering callback continuously #23

Open stuarttayler opened 9 years ago

stuarttayler commented 9 years ago

I'm having an issue where when using wiringPiISR interrupts, the callback is triggered continuously once a button has been pressed.

When I run the following code:

var wpi = require('wiring-pi');
wpi.setup('wpi');

// // setup
wpi.pinMode(27, wpi.INPUT);
wpi.pullUpDnControl(27, wpi.PUD_UP);

wpi.wiringPiISR(27, wpi.INT_EDGE_FALLING, function(delta) {
  console.log('Pin 7 changed to LOW  (', delta, ')');
});

setInterval(function() {
    console.log('waiting');
}, 2000);

This is the output I get:

waiting
waiting
waiting
waiting
waiting
waiting
Pin 27 changed to LOW    ( 12908576 )
Pin 27 changed to LOW    ( 979 )
Pin 27 changed to LOW    ( 26 )
Pin 27 changed to LOW    ( 15 )
Pin 27 changed to LOW    ( 15 )
Pin 27 changed to LOW    ( 17 )
Pin 27 changed to LOW    ( 14 )
Pin 27 changed to LOW    ( 13 )
Pin 27 changed to LOW    ( 13 )
Pin 27 changed to LOW    ( 14 )

It logs 'waiting' until the button is pressed. The output continues then like this, registering the delta as around 14.

I had exactly the same setup previously and it only triggered the callback once (or twice due to the switch bouncing). This new behaviour has only happened since I did a 'sudo apt-get update' and 'sudo apt-get upgrade'.

I have an equivalent test program in python using RPi.GPIO and interrupts and that seems to work as normal, so wondering what could have caused this change...

Thanks

tleyssens commented 9 years ago

Hi, i have the same problem, also after apt-get update/ upgrade.

Greatings.

TheNotary commented 7 years ago

Hopefully you sorted things out by now, but something doesn't look right about those pin numberings. The comment indicates pin 7 is of interest. The pin terminology you're using is the 'wiring pi' terminology, and pin 27 may refer to a BCM pin 27, which would be wpi pin 2. Maybe that's the issue?

I have an additional issue where I was trying to set the pull up resistor on a pin. When I would close the circuit to ground, nothing happened... however, when I touched the pin (while beeing bare footed and standing on a wood floor of course) the callback would then and only then fire. I tested this many times. I don't really know my ee so it seems weird to me. The fix was to use the gpio utility to set the pin to input and up.

gpio mode 0 in
gpio mode 0 up

In my case, I was using wpi.setup('sys'); so the app could be run as an unprivileged user. As such I refered to the wpi pin zero as 17. Is there a chance there's something funky in the code about that?

Would someone be willing to confirm this strangeness? The pin that should be touched is on header 11. Somethings up with the pull up/down transistor code if it only fires on your contact instead of when it's touched to ground (say header 6).

Test Setup (incomplete?):

$  gpio mode 0 in
$  gpio edge 0 rising
$  gpio exports
GPIO Pins exported:
   0: in   1  rising  
  17: in   0  rising

Test code:

  var wpi = require('wiring-pi');
  wpi.setup('sys');

  var pin = 0;
  var bcm_pin = 17; // pinTranslator.toBCM(pin); // 17

  wpi.pinMode(bcm_pin, wpi.INPUT);
  wpi.pullUpDnControl(bcm_pin, wpi.PUD_UP);

  // A.  Get initial state of pins and report states

  wpi.wiringPiISR(bcm_pin, wpi.INT_EDGE_RISING, function(delta) {
    console.log("detection made... you probably touched wpi pin " + pin);
  });

I'm trying it for a second time after rebooting... and it's just not responding to touch or being connected to ground unless I do gpio mode 0 up which I wouldn't expect I would need to do from bash since there's a function to do that, right?

TominJoseph18 commented 7 years ago

Hi.

I want to send interrupts through my gpio pins. I am using the wiringPi Library for this purpose. When a code to wait for interrupt is run ,the ethernet connection to my laptop breaks and it says broken pipe error.

Could someone please help me to execute a command X in C when an interrupt event occurs which also prevents any kind of switch debouncing and transient voltages.

Thank you.

michaeljanich commented 6 years ago

I had a similar problem and I changed the pin and grounded the shield in the (2m long) cable, that probably acted as an antenna.

Don't use pins like i2c or w1 (pin 7 in whatever counting). You never know if there's a kernel driver "working" on those pins.

-M