I have a Pi hooked up to the output and reset nodes of an NOR gate S-R latch. For those of you who don't know what that is, basically I have an input in GPIO pin 11 that goes high (3.2V) whenever the latch is triggered. I then have an output in pin 12 (standard numbering not broadcom) that is supposed to go high once the Pi has detected the latch, which causes the latch to reset and the cycle can start again.

The whole point of this is to detect when the camera takes an image, use the pi to extract the time when the image was taken and write it to a text file. The problem is my program seems to be having difficulties detecting when the latch is high

using namespace std; 
void interrupt(void);

struct timeval curTime;
char dateiname[256] = "";
int i=0;
int milli;
int seconds_in_day;
char buf[255];
ofstream myfile;

int main(int argc, char *argv[]){


time_t t = time(0);
struct tm * now = localtime(&t);

//Create and open file
sprintf(dateiname, "/home/raspbian/Desktop/%02d%02d%02d_%02d_%02d.txt", 
                   now -> tm_year+1900, 
                   now -> tm_mon+1, 
                   now -> tm_mday, 
                   now -> tm_hour, 
                   now -> tm_min); 


//write heading to file before loop
myfile << "picture, System Time" << endl;

//Set 11 & 12 as input/ output
pinMode(11, INPUT);
pullUpDnControl(11, PUD_DOWN);
pinMode(12, OUTPUT);
pullUpDnControl(12, PUD_DOWN);

//make sure 12 is low
digitalWrite(12, LOW);
digitalWrite(12, HIGH);
digitalWrite(12, LOW);

  wiringPiISR(11, INT_EDGE_RISING, &interrupt);


void interrupt(void){
gettimeofday(&curTime, NULL);
milli = curTime.tv_usec / 1000; //Get time in milliseconds
seconds_in_day = curTime.tv_sec % 86400; //Get seconds since midnight
sprint(buf, "%d %d.%d", i, seconds_in_day, milli); //Write to file
myfile << buf << endl; 

//send out reset signal
digitalWrite(12, LOW);
digitalWrite(12, HIGH); 
digitalWrite(12, LOW);

Does anyone know what could be causing my program not to be detecting the input? My suspicion is that it has something to do with the interrupt but i'm not sure. Any help would be appreciated.

  • Before trying to analyse your code have you checked the circuit. Run gpio readall to check that the inputs change as expected.
    – Milliways
    Commented Oct 30, 2015 at 5:44
  • I ran a test that came with wiringPi and the test came back with a couple of pins that were faulty but not the ones that I am using
    – oodan123
    Commented Oct 30, 2015 at 5:47
  • That was not the question. Have you run readall then set the latch and verify that it changes. "faulty" pins are a worry!
    – Milliways
    Commented Oct 30, 2015 at 6:45

1 Answer 1


The problem is likely in this line:

  wiringPiISR(11, INT_EDGE_RISING, &interrupt);

Here you are continuously registering an interrupt function to pin 11. This is not how this should work. Two things need to change:

  1. You should register the interrupt/event function outside of the while(1) loop. WiringPi only needs to know this interrupt binding once for it to use it every time it detects a rising edge on pin 11.
  2. Doing a while(1){} loop is causing high CPU load (this is called "busy waiting" - unless the c++ compiler optimizes this somehow during compilation). This is negates the intent of the whole event/interrupt setup. Try replacing the while-loop with a sleep function which allows the CPU to work on something else. The <pthread.h> library contains a sleep() function definition.
  • Thanks for the answer. However I was just wondering that if I replace the while(1) loop with a sleep function, won't the program end after the sleep function has completed executing? Or do I put the sleep function in the while(1) loop so that the sleep continually gets executed?
    – oodan123
    Commented Nov 1, 2015 at 23:52
  • 2 options: 1) you can use a gigantic number of seconds to sleep, or indeed 2) take a smaller number of seconds and loop it in a while(1) loop as you suggested.
    – Phil B.
    Commented Nov 2, 2015 at 1:00

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.