@benfry What kind of vibes are you getting from GPIO.waitFor? Or just GPIO.wait? GPIO.waitPin?

Are there other things you'd be waiting on other than interrupts? Is there a simpler way of saying "interrupt" or is that the language that folks will see/use in this context 100% of the time anyway?

@benfry Thinking that interrupt might be a bit of a misnomer because the fact that it uses (waits for) an interrupt is just implementation detail... instead of using this function the user could just as well write

int start = millis();
while (GPIO.digitalRead(pin) == value && millis()-start < timeout) {
  // relax
}

The function would just make this more readable by turning it into

// some GPIO code
GPIO.waitFor(pin, value);
// more GPIO code

Which can be optionally abort after a timeout as to not block program execution forever

// some GPIO code
GPIO.waitFor(pin, value, 10);
// more GPIO code

Right now the function returns a boolean indicating success or failure, but I guess a way nicer way would be to throw an exception. This way a giant block of GPIO code could just be wrapped in a big try {} catch {}, and the various points where the program waits for some line to go high or low could each have their own allowance in terms of how much time they can spend waiting.

Yeah, that's what I'm trying to get at… the waitFor() syntax reads much better and seems more on-point.

We go out of our way to avoid exceptions for day-to-day functions—they're only in the API for advanced features like createInput() or createOutput() which are interfacing with Java code anyway. Does it require an exception or are you just going from how InterruptedException is typically used in Java?

I wouldn't require the exception to be handled by the sketch code, but - thinking aloud - this would be the simplest case:

GPIO.waitFor(4, GPIO.RISING);

Pin never rises? Well, then we're stuck here forever. Not the end of the world. Hit stop, figure out what's going on, etc. If we want to handle this case, and not use exceptions, then I fear people will have to use it like this:

boolean successful = GPIO.waitFor(4, GPIO.RISING, 10);
if (successful == false) {
  println("Pin did not rise");
  return false;
}

Which might be okay once, but not so nice if there are multiple of these after each other. If waitFor would throw an exception we could do this more concise

GPIO.waitFor(4, GPIO.RISING, 10);
GPIO.digitalWrite(5, GPIO.LOW); // or something
GPIO.waitFor(4, GPIO.FALLING, 10);
// ...

And if one of these ever takes longer than the 10 milliseconds we get a nice big error in the message area, that immediately points the user to the right line, and says "something here took longer than you said it would". Wish I had this when coding Arduino :)

And the most advanced users could still use something more elaborate like

try {
  GPIO.waitFor(4, GPIO.RISING, 10);
  GPIO.digitalWrite(5, GPIO.LOW); // or something
  GPIO.waitFor(4, GPIO.FALLING, 10);
  return true;
} catch (Exception e) {
  println("Could not initialized hardware, check wiring...");
  return false;
}

Looks good?

And about the name? GPIO.wait / GPIO.waitFor / GPIO.waitPin?

Would a callback be better? We have lame callbacks by using (public) function names (see selectInput() et al), at least until we can make use of the Java 1.8 syntax.

I still believe the error in the message area (that can optionally be circumvented with try {} catch {} by people in the know) would be best. It's really meant as a last-resort thing anyway, and because I think it's important to not silently ignore these errors. (So much room for mistakes: picking the wrong pin on the header, cabling issues, ...)

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.