1

This program is supposed to react to rising and falling edges of an input signal. However it doesn't exactly work as expected. The expectation is that one (1) interrupt is generated for any edge, same for rising and falling. When the input is at a constant level no interrupt should be generated.

So effectively the result should be something like "HLHLHLHLHLHLHLHLHLHL..." indicating alternating edges.

For testing I connect the input "BUTTON" directly to GND or 3V3, so no floating inputs.

When connected to 3V3 I get something like "H" or maybe "HHHH".

When connected to GND I get "LLLLLLLLLLLLLLLL...". The interrupt is executed repeatedly several times (randomly 1-100) per second.

At the same time the PWM output is activated driving an LED hooked to 3V3 with ~40kHz. Disconnecting the LED improves the situation. But even then the output is not alternating but shows the same level repeatedly.

The Scope shows that the LED creates some noise on the 3V3 rail of about +/- 200mV. I wouldn't expect this to cause that problem as the trigger levels for edge detection should be far off, especially for GND.

What could I do to get exactly one interrupt for each edge (alternating) and nothing when the input is at a constant level?

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <stdlib.h>
#include <wiringPi.h>

// pin defines (BCM2835 numbering)
#define BUTTON    17

void myInterrupt (void)
{
    if (digitalRead(BUTTON) == LOW)
        printf("L");
    else
        printf("H");

    fflush (stdout);
 }

int main (void)
{
    if (wiringPiSetupGpio () < 0)
    {
        fprintf (stderr, "Unable to setup wiringPi: %s\n", strerror (errno)) ;
        return 1 ;
    }
    else
        pinMode(BUTTON, INPUT);

    if (wiringPiISR (BUTTON, INT_EDGE_BOTH, &myInterrupt) < 0)
    {
        fprintf (stderr, "Unable to setup ISR: %s\n", strerror (errno)) ;
        return 1 ;
    }

    for (;;) {}

    return 0 ;
}

The code compiles without warnings or errors.

2
  • Further investigation shows that detaching the LED, shutting off the PWM but instead writing some dummy data on the SPI results in the same glitches on the 3V3 rail with the same behaviour of the interrupt.
    – Soeren
    Commented Oct 9, 2014 at 16:39
  • Without any detail of what is connected it is impossible to say.
    – Milliways
    Commented Oct 9, 2014 at 22:32

1 Answer 1

1

You are printing the gpio level when your callback is called. This has no relationship with the level which triggered the callback (at least 50 microseconds earlier according to my experiments on the Pi).

If you don't have a logic analyser I suggest you download piscope. It will allow you to get some idea of what is happening on your gpios.

If you want to monitor the levels on multiple gpios or monitor any gpio changing state more than, say, 20 thousand times per second you are better off using my pigpio from C or Python (or any other language you care to use).

6
  • I decided to try piscope. I first installed pigpio (i believe you are the author) and ran the tests sudo ./x_pigpio gave an error gpioInitialise: bind to port 8888 failed (Address already in use) pigpio initialisation failed I haven't been through the code yet, but – it seems the port is used by rpimonito RPi-Monitor.
    – Milliways
    Commented Oct 10, 2014 at 3:00
  • The port is certainly used by other software on the Pi. RPi-Monitor sounds like it's one. You need to change the socket number. When you start the pigpio daemon use the p option, e.g. sudo pigpiod -p 8877. For other programs set an environment variable, e.g. export PIGPIO_PORT=8877 then run the Python module, piscope etc. Of course the export number must match that used by the daemon. Note, x_pigpio is a test of the underlying C library and can not be run at the same time as the daemon (it uses the same resources). Also note that it's best to close piscope before killing pigpiod.
    – joan
    Commented Oct 10, 2014 at 7:08
  • It is true that the printing of the gpio level does not show which edge actually triggered the interrupt. But still it indicates that the interrupt is called permanently when the gpio is connected to GND while it is only called a few times when connected to 3V3.
    – Soeren
    Commented Oct 12, 2014 at 17:10
  • What have you connected to gpio17? I can't see anything wrong with your software, that leaves the connected hardware as the problem.
    – joan
    Commented Oct 12, 2014 at 17:23
  • For testing I have reduced the hardware to a jumper wire that connects gpio17 either to GND or 3V3.
    – Soeren
    Commented Oct 12, 2014 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.