Hardware Interrupt

[code//This is just a tutorial for me to understand how to put the software //In a one line or two line loop. like toggling a pin except with //The ability to jump out of the loop upon triggering if a hardware interrupt.

int a = 0; int pin = 13; volatile int state = LOW;

void setup() { Serial.begin(9600); digitalWrite(20, HIGH); pinMode(pin, OUTPUT);

//Program needs to be in a one line loop at this point then break out based on the isr. I want the program to sit and wait for an interrupt not run all the time //Program sychronization is dependant on this interrupt. At present the interrupt is produced by mementary=ily grounding pin 20. ATMega 2560. } void loop() { interrupts(); attachInterrupt(3, sam, RISING); noInterrupts(); if (a = 1) { Serial.println(" interrupt");

}

if (a = 0)

{ Serial.println("no interrupt has occured"); } digitalWrite(pin, state); } void sam() { (a = 1); }code]

  if (a = 1)

Fail.

please use code tags when posting code

 if (a = 0)

  { Serial.println("no interrupt has occured");
  }

Also wrong.


void sam()
{
  (a = 1);
}

What are the brackets for?

http://www.gammon.com.au/tips#trap3

The variable "a" should be volatile.

http://www.gammon.com.au/interrupts

has anyone addressed the problem brought forth?

Which particular problem?

Please post your amended code, in code tags.

int pin = 13;

would be better as const byte led =13;

volatile int state = LOW;

you obviously intend this to change in the isr but you do nothing with it

interrupts(); attachInterrupt(3, sam, RISING); noInterrupts();

why the interrupts/nointerrupts , it serves no purpose and constantly attaching the interrupt in the main loop is also pointless ,do it once in setup

if (a = 1) { Serial.println(" interrupt");

}

if (a = 0)

{ Serial.println("no interrupt has occured"); } digitalWrite(pin, state); }

apart from the = instead of == issues , surly an interrupt has occurred or it hasn't ie if {} else {} construct is more appropriate. also the interrupt notification condition (a=1) needs to be cleared.

void sam() { (a = 1); }

maybe add digitalWrite(led, !digitalRead(led)); // toggle led on interrupt

const byte led = 13;
volatile byte a = 0;

void setup()
{
  Serial.begin(9600);
  digitalWrite(20, HIGH);
  pinMode(led, OUTPUT);
 attachInterrupt(3, sam, RISING);

  //Program needs to be in a one line loop at this point then break out based on the isr. I want the program to sit and wait for an interrupt not run all the time
  //Program sychronization is dependant on this interrupt. At present the interrupt is produced by momentarily removing grounding pin 20. ATMega 2560. (its a rising edge interrupt)
}
void loop()
{



  if (a == 1){
   Serial.println(" interrupt");
   a = 0;
   digitalWrite(led, !digitalRead(led));  //  toggle led on interrupt
  }



}
void sam(){
  a = 1;

}

This is NOT how you use interrupts

void loop()
{
  interrupts();
  attachInterrupt(3, sam, RISING);
  noInterrupts();

In fact, I think it entirely misses the point of using an interrupt. You don't start an interrupt when you think something is about to happen. It needs to be listening in the background all the time. That's because interrupts are normally used to detect unpredictable of short-lived events.

The attachInterrupt() is normally called from setup() so that it is available all the time to detect whatever is to be detected. Then when it is triggered the Arduino automatically pauses whatever it was doing and jumps to the Interrupt Service Routine (ISR). When the code in the ISR is completed the Arduino will carry on from where it had paused.

The sequence of your interrupts() and noInterrupts() makes no sense because interrupts are normally ON and the usual reason you switch them off (briefly) is when you want to read a value that has be updated by the ISR and which might be updated again during the time the value is being read. In your code the only time the interrupts are ON is while you are attaching the ISR and you have the interrupts OFF for the rest of the time.

See Nick Gammons interrupt tutorial - linked to in Reply #4.

...R

stx38834: has anyone addressed the problem brought forth?

Yes, they have. Hast thou understood the answers?

Likely Not.. Really dodgy code too.. IMO

Doc

stx38834: has anyone addressed the problem brought forth?

Did you read the previous replies ?

and

What was the actual "problem brought forth" ? Your original post doesn't seem to actually have one...