Disabling External Interrupts from within corresponding ISR

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im trying to disable an external interrupt from it's corresponding service routine. The problem Im having is that Im confused as to why I can not disable the routine from executing multiple times. It's clear that to me that the AVR is rentering the ISR even though my attempts to disable the ISR have not worked. The interrupt is configured as a low level asynchronous interrupt and the chip that I am using is an Atmega64.
Here is the offending code:

ISR(INT7_vect)
{

//Disable Pin Change Interrupt
EIMSK |= (0<<INT7);
EIFR  = (1<<INT7);
ReadEnableADC();
ChipSelectEnableADC();
while(PINE & 0x40){};
//Enable RX complete interrupt
UCSR1B |=(1<<RXCIE1);
//Enable Transmitter
UCSR1B |= (1<<RXEN1);
//Enable Receiver
UCSR1B |=(1<<TXEN1);


}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
EIMSK |= (0<<INT7); 

Umm no, methinks you meant:

EIMSK &= ~(1<<INT7); 

(if you don't understand why read the "101" thread in Tutorial Forum)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

EIMSK |= (0<<INT7); 

Umm no, methinks you meant:

EIMSK &= ~(1<<INT7); 

(if you don't understand why read the "101" thread in Tutorial Forum)


God dammit. I was bitwise oring it not bitwise anding it which means it will always be one and never change. Thank you for pointing out my absurdly stupid mistake.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I was bitwise oring it not bitwise anding it which means it will always be one and never change.

You missed that "(0<<INT7)" is 0, and ORing with 0 produces no change in the bits (I guess it would change processor flags) and is essentially a C NOP. Code is probably generated because the I/O register is volatile.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe in the future, if there are presence in that kind of code, the compiler should know that something is not right and generate a warning signal...

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m23402027 wrote:
Maybe in the future, if there are presence in that kind of code, the compiler should know that something is not right and generate a warning signal...

Well the programmer is at liberty to write whatever he likes and too many warnings becomes annoying but if you want more warnings than you can possibly ever eat then before compiling first run the code through lint, splint, QAC or similar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is not the compilers job to stop you from shooting yourself in the foot. Besides one might shift a 0 for readability, even though the actual code has no effect.

flags = (1<<flag1) | (0<<flag2) | (1<<flag3);

Writing code is like having sex.... make one little mistake, and you're supporting it for life.