adding delay in interrupt does not work

Projects Programming
1

i was just hoping to get an explanation as to why when i add the _delay_ms
in an interrupt it cause it to not work.
i was trying to add it to the ISR call as oppose to the while loop, for no real reason i figured it would work the same , i imagine since its "haniging" there it misses there interupt next time around...everytime around??

/*
* PWM_experiment.c
*
* Created: 7/16/2013 9:43:52 PM
*  Author: eddiea6987
*/

#define F_CPU 16000000L
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

double  pwm = 0;
int cycle = 0;
int main(void)
{
	DDRD |=(1<<PIND6); // set pin d6  "OC0A" to output
	
	TCCR0A |= ((1<<WGM01) | (1<<WGM00)); //set form generation mode to  fast pwm
	
	TCCR0A |= (1<<COM0A1); // clear on compare match
	TIMSK0 |= (1<<TOIE0);// overflow interrupt enable 
	sei(); //enable global interrupts 
	
	OCR0A = ((pwm / 100) * 255.0 ) ;//value to compare to timer ,  pwm dudty cycle 
	TCCR0B |= (1<<CS00) | (1<<CS02); // set prescaler to 1024 , once set timer will start 
	
	while(1)
	{
		_delay_ms(10);
		pwm++; //increment dutyCycle PWM 
		if(pwm > 100)
		{
			pwm = 0;
		}
		
	}
	
}
ISR (TIMER0_OVF_vect)
{
	OCR0A =  ((pwm / 100) * 255.0 ); // give it a new dutycycle " since it was changed i while loop main
	
	//_delay_ms(50); // adding a delay in the isr will cause it not work 
}
2

You cannot use delays in an interrupt.

•Don't attempt to delay, eg: delay (100);

•You can get the time from a call to millis, however it won't increment, so don't attempt to delay by waiting for it to increase.

•Don't do serial prints (eg. Serial.println ("ISR entered"); )

•Don't try to do serial reading.

See:

3

Here's why it won't work:

  • delay() calls micros to determine how much time has passed
  • micros() examines the Timer0 overflow count, multiplies it by 256, adds it to the current Timer0 count, and multplies the result by something to get its result
  • The Timer0 overflow ISR manages the Timer0 overflow count
  • When the program responds to an interrupt, one of the first things it does is disable all other interrupts; it reenables them when it exits the ISR
  • Unless your ISR explicitly reenables interrupts, other ISR's won't execute until yours is finished
  • Specifically, the Timer0 overflow ISR won't execute
  • The Timer0 overflow count never changes
  • micros() doesn't change much, since the Timer0 overflow count accounts for most of its value
  • delay() never sees the value of micros() get big enough to indicate that the delay period has elapsed, so it never returns

It waits forever. That's why everyone will tell you this: Don't call functions that rely on interrupts from ISR's. I'll reveal that you actually can do it, but there's almost always a better alternative, so you shouldn't. If anything isn't right, it's notoriously hard to troubleshoot - most of the time, you might as well just shoot yourself in the foot.

4

Very well explained guys and good link there to Gammon's site. I did not know the whole interrupts are disabled when an interrupt occurs , but then again I am to blame when it is right there , first sentence on page 14 of the datasheet

When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts are disabled. The user software
can write logic one to the I-bit to enable nested interrupts. All enabled interrupts can then interrupt the current
interrupt routine. The I-bit is automatically set when a Return from Interrupt instruction – RETI – is executed