External Interrupts « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

External Interrupts

(22 posts) (4 voices)

Started 5 years ago by Silntknight
Latest reply from Silntknight

12 Next »

Silntknight
Moderator

The external interrupts page is very detailed (http://leaflabs.com/docs/maple-ide/external-interrupts/), but I noticed that LOW wasn't an option for an interrupt. I know the Arduino has this functionality and was wondering if this was a small typo (because there is another) on the page or if there is no compatibility here. It would be very helpful for me if the Maple supported LOW because I need a switch that, when disconnected, puts the code in an infinite loop that leave when the pin goes HIGH again. FALLING doesn't do this for me. I don't know if it's possible/wise to make the code something like:

void infinite () {
if(pin == LOW) {
;
} else {
loop; //I am assuming here that this is the correct syntax
}

By the way, the other typo is that RISING and FALLING are both described as "low to high."

Posted 5 years ago #
crenn
Moderator

DigitalRead(pin) will return the state of the pin (Either HIGH OR LOW).

Posted 5 years ago #
gbulmer
Moderator
This may flesh it out a bit more.
Use attachInterrupt(..., ..., CHANGE) and look at the pin in the interrupt handler using DigitalRead(pin) as crenn suggests.

I suggest you don't go into an infinite loop inside an interrupt handler, all sorts of weird things may be caused to happen.

The worst case is the interrupt handler blocks itself from being called (I'd need to double check to understand if this is happens), so it never sees the later event it is looking for.

Instead use a variable that is tested by loop(), and set or clear the variable in the interrupt handler.

E.g.
```
volatile bool isOn = true;

void setup() {
  ...
  attachInterrupt(..., offOnHandler, CHANGE);
  ...
}

void loop () {
  if (isOn == FALSE) {    // or (!ifOn) ...
     return;
  }

  ... the rest of loop() ..
}

void offOnHandler() {
  ... do stuff to decide what to do ...
  val = digitalRead(pin);
  ...
  if (... val says we want to stop ...) {
    isOn = FALSE;
  } else {
    isOn = TRUE;
  }
}
```
This approach ensure the system is always responsive to interrupts.

WARNING - I haven't compiled this code, so it may contain errors.
Posted 5 years ago #
Silntknight
Moderator

Ok, I think I understand where this is going. I actually don't need an interrupt if I have the if statement at the top. I can just put my loop in an if statement dependent on the switch's state. If it is high, then run the loop, if not, don't run. Something like:

void loop() {
c = digitalRead(pin);
if (c == HIGH) {
//loop stuff here
}
}

Gbulmer, this may also avoid some of the problems associated with my "Fun with timings" post as far as interrupts go because I would be eliminating one other possible interrupt conflict.

Posted 5 years ago #
gbulmer
Moderator

I actually don't need an interrupt if I have the if statement at the top. I can just put my loop in an if statement dependent on the switch's state. If it is high, then run the loop, if not, don't run.

Exactly.

... this may also avoid some of the problems associated with my "Fun with timings" post as far as interrupts go because I would be eliminating one other possible interrupt conflict.

I believe so too.

Posted 5 years ago #
Silntknight
Moderator

Great! This works out well.

Posted 5 years ago #
poslathian
LeafLabs

I never fully understood the purpose of an on-low interrupt, does this just continually fire as long as the pin is low?

Posted 5 years ago #
Silntknight
Moderator

I never fully understood the purpose of an on-low interrupt, does this just continually fire as long as the pin is low?

If I understand you correctly, yes. To provide an example, I intended to run a code that control an engine. When I wanted to run the engine, I would have the kill switch closed. Then, when I wanted t kill it, I would open the switch. The LOW interrupt would keep it "killed" as long as the switch was open. I was able to replace this with a simple if statement, but for an operation that couldn't do that, LOW (or HIGH) is almost necessary. Going back to my example, I couldn't use CHANGE or else the engine would never run. I also couldn't use RISING or FALLING because the code-stop was an infinite loop. Again, my example could have used a delay(100) command and either RISING or FALLING, but there could be others with different needs.

Posted 5 years ago #
poslathian
LeafLabs

hmm. So youre engine is running, the kill switch is not thrown. You want to kill the engine as soon as the kill switch is thrown. So why not interrupt on the low to high transition and kill the engine?

Posted 5 years ago #
Silntknight
Moderator
This was my original code for a LOW interrupt:
```
void kill() {
  while (true)
  ;
}
```
If I had made it:
```
void kill() {
  delayMicroseconds(5000000);
}
```
Your solution might have worked. The original code had an infinite loop that would only be run if the switch was LOW. If I did RISING with that code, I would never leave the loop. Also, running delays in an interrupt is (apparently) unwise, so the second isn't the best solution. In the end, I realized that I could just make an if statement at the start of the loop:
```
void loop() {
  if (digitalRead(pin) == LOW) {
    //loop//
  }
}
```
In this way, as long as the switch is open (or closed if I wanted), the loop runs. Otherwise, it just keeps checking the switch's state.
Posted 5 years ago #
poslathian
LeafLabs
yep thats what I was thinking.

Remember to debounce your buttons for critical things (like a kill switch!)

debouncing: http://www.ganssle.com/debouncing.htm

TLDR:
Switches will often rapidly toggle when you open/close them because of mechanical vibrations right at the contact point. This means if you did something like:
```
bool buttonDown = False;
int cnt =0;
while(1) {
    if (buttonDown) {
       if (!readPin(button)) buttonDown=False;
    } else {
       if (readPin(button)) {
          cnt++;
          buttonDown = True;
       }
    }
}
```
and you hit the button ONCE, you might very well get a count of 10 or 100. Which you obviously dont want. So you want to bake into your switch-check loop some sort of "downtime"

that is, you dont set buttonDown until the button has been reading consistently as "down" for some number of cycles.
Posted 5 years ago #
Silntknight
Moderator
Ok, I think for my purposes a simple delay in the code and a recheck would suffice. Obviously the engine would stop if the connection is successful. Also, missing one cycle isn't terrible. This means the lightest program that can do the job is probably adequate. I was thinking something like
```
if (digitalRead(3) == LOW) {
  //loop//
} else {
  delayMicroseconds(5);
  if (digitalRead(3) == LOW) {
    delay(1000);
  }
}
```
Just so you know, I am using some hefty toggle switches. We use these for normal engine kills (by grounding the spark) and we've never had trouble with it. It is unlikely that the connections would be made inadvertently. Thanks for the suggestion though; the code isn't hard to implement and can only help!
Posted 5 years ago #
Silntknight
Moderator

Poslathian, I like the idea of debouncing, but I have a switch that is (surprisingly) more critical than the kill switch. It monitors whether the intake valve is open or closed. I have an interrupt that runs off of this and actually controls the entire circuit. The switch will be mounted literally on top of an engine and will experience lots of vibrations. I can't think of any way to debounce this, however. Should I configure the switch to be in a position where it is on most of the time or off most of the time. My reasoning is that if it is on mostly, then the connectors are closed by significant pressure, thus the connectors cannot literally bounce. The interrupt (if the button is configured to be normally on, or an NC circuit) would then be triggered by the rising action. Even if in the milliseconds it is open (anywhere from 5ms to 60ms) it bounces, it only becomes a stable RISING input when it is closed by the pressure of the valve on it.

Posted 5 years ago #
gbulmer
Moderator

Silntknight - could you use a Hall sensor instead? They are physically quite robust (no moving parts) and I believe some have some mitigation over switch bounce.

Posted 5 years ago #
poslathian
LeafLabs

my recommendation would be to run it, and scope this input. See if it is glitchy (alot of bouncing). Based on what the scope tells you, we can think up the right way to interpret the signal.

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.