hi, guys i am writing following code for DUE.
if pin 2 detect HIGH it should go into ISR named blink1. and it should turn on and off Board LED. then come back to again check its states. its not working.
const byte = 13;
void setup()
{
pinMode(pin, OUTPUT);
attachInterrupt(2, blink1, HIGH);
}
void loop()
{
attachInterrupt(2, blink1, HIGH);
}
void blink1()
{
digitalWrite(pin,HIGH);
delay(1000);
digitalWrite(pin,LOW);
delay(1000);
}
I couldn't find information on the default operation of IO pins, but it'w worth setting pin 2 as an input. My desk isn't in Arduino mode at the moment so I can't try i out for myself 
What's connected to pin 2? Do you need an external pullup or pulldown resistor to prevent the pin from floating?
HIGH mode would be a poor choice for triggering an interrupt because it would keep re-triggering your interrupt routine as long as pin 2 is high. Try RISING or FALLING depending on how your input is connected and configured.
Don't put delay() in your interrupt routine as it isn't compatible. Just use a flag variable instead, then check the flag in the main loop and blink the LED if necessary.
I suspect that using an interrupt isn't necessary ... is this just a learning exercise?
Delete the attachInterrupt line inside the loop.
-p
I don't think that delay() is expected inside of ISR code; it relies on the millisecond clock interrupt to advance the time, and that might not happen if the code is in another ISR. (This is certainly true of AVR. CM3 is more complicated, because it has multiple priority levels, so it MIGHT work. But it's not a good idea to count on it!)
westfw:
I don't think that delay() is expected inside of ISR code; it relies on the millisecond clock interrupt to advance the time, and that might not happen if the code is in another ISR. (This is certainly true of AVR. CM3 is more complicated, because it has multiple priority levels, so it MIGHT work. But it's not a good idea to count on it!)
On the CM3 the Arduino core sets all interrupts to the exact same priority level. The chip itself has nested interrupts but with everything set to the same priority the best you can hope for is tail chaining (one interrupt directly after the other). The reasoning behind this is probably to prevent having to answer questions about why some really obscure race condition happened or why a variable got clobbered when it was accessed from two interrupts at basically the same time. Because of this, it is still dangerous to use delay() within an interrupt handler. The millisecond counter on the CM3 is done via the systick interrupt. You can still use delayMicroseconds() as it uses busy loops instead of looking for a timing signal. So, delayMicroseconds(1000) is equivalent to a 1ms delay.
However, delaying for 2 seconds within an interrupt handler is the form of evil usually reserved for Colombian dictators and time share salesmen. Never, ever, ever, sit around waiting for two seconds in an interrupt handler. Never. It's better to move this logic out into the loop function. Interrupt handlers are for setting flags and doing fast work.
AFAIK after reset, all interrupts are disabled and given a priority-level value of 0, BUT most exceptions, including all interrupts, have programmable priorities.
To set the priority of an interrupt, you have the CMSIS-Core access functions:
void NVIC_SetPriority(IRQn_Type IRQn)
void NVIC_SetPriorityGrouping(uint32_t PriorityGroup)
void NVIC_EncodePriority (uint32_t PriorityGroup, uint32_t Pre_emptPriority, uint32_t Sub_Priority)
See datasheet chap 10.21.6.1
The preempt priority level defines whether an interrupt can be serviced when the processor
is already running another interrupt handler. In other words, preempt priority determines
if one interrupt can preempt another.
The subpriority level value is used only when two exceptions with the same preempt priority level
are pending (because interrupts are disabled, for example).
When the interrupts are re-enabled, the exception with the lower subpriority (higher urgency)
will be handled first.
See datasheet chap 10.6.7.3 and 10.6.7.4
The Tail chaining feature speeds up exception servicing and the late arrival feature speeds up preemption.
Hello,
I been working with the Due as well. Is there a trigger voltage for Due Interrupts for Falling and Rising? I been using a Quadrature output from a DC Motor into two Interrupts and while I have switch around pins around I am getting similar results. The Due doesn't seem to like two pulses at same amplitudes although both signals are 90 deg out of phase. If I bring any of the two lower, the Interrupts seem to work but will fail if both are at the same level. Any ideas?
Pins used were 20, 21 on the DUE
Thanks,
MJ
Not shure of what you need.
while I have switch around pins around I am getting similar results
What did ou expect and what did you get?
AFAIK, voltage trigger will be the same as digital read.
Atmel data sheet section 45.2: LOW: 0.3 x VDDIO, HIGH: 0.7V x VDDIO
Perhaps you will need a comparator op amp to clean the signal.
Maybe you could also try the internal DUE smith trigger.
Regards.
Nitrof