extern interrupt

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

hi

after the timer interrupt, i began with the extern interrupt. i have it working, but what i'm filling in doesn't make sense.

GICR|=0x40;
MCUCR=0x03;
MCUCSR=0x00;
GIFR=0x10;

// External Interrupt 0 service routine
interrupt [EXT_INT0] void ext_int0_isr(void)
{
PORTB.0 = !PORTB.0;

}

// Global enable interrupts
#asm("sei")

i'm a bit worried about the settings that i used for GICR, MCUCR, MCUCSR, GIFR.

when i press SW2 on the SKT500, which is connect to the INT0, to create an interrupt. this works, but when i look at the datasheet and at the settings i use..

the datasheet is saying this:
GICR|=0x40; --> INT2 is high now

MCUCR=0x03; --> ISC01 and ISC00 are high (which is the rising edge of INT0 or the if you look at ISC10 and ISC00 (which is the low level of INT1).

MCUCSR=0x00; nothing important
GIFR=0x10; --> INT1 is high.

hopefull u guys understand what i mean, and what's on with the code.

ps i use Atmega16l

Robbin

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

GIFR=0x10 does nothing-
0x10 = 0b00010000, and the bit you are setting is read-only and is not used. Only the 'high' 3 bits are used as intx flags. If you intended to clear the int0 flag by writing a 1 to the int0 flag, then you would want GIFR=0x40 (but the int0 irq clears this flag for you).

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

Quote:
the datasheet is saying this:
GICR|=0x40; --> INT2 is high now

Where does the datasheet say that? 0x40 would turn INT0 on, not INT2.
Quote:
MCUCR=0x03; --> ISC01 and ISC00 are high (which is the rising edge of INT0 or the if you look at ISC10 and ISC00 (which is the low level of INT1).

The first part is correct, it sets for the rising edge of INT0.
Quote:
GIFR=0x10; --> INT1 is high.

This does nothing. The bit being set is unused.

Regards,
Steve A.

The Board helps those that help themselves.

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

curtvm wrote:
GIFR=0x10 does nothing-
0x10 = 0b00010000, and the bit you are setting is read-only and is not used. Only the 'high' 3 bits are used as intx flags. If you intended to clear the int0 flag by writing a 1 to the int0 flag, then you would want GIFR=0x40 (but the int0 irq clears this flag for you).

oke thanks,

for some reason is was reading 0x10 as 1000 0000. how foolish of me :S

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

i have another question. i want to set the settings to INT1 now, but for some reason it ain't working.

i have these settings:

GICR|=0x80;
MCUCR=0x00;

this should work right?
Robbin

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

MCUCR=0x00 means you want a low level to trigger the int1 irq (and int0). If you wanted the same as you previously had with int0, you would need MCUCR=0x0C or MCUCR=(3<<ISC10).

Remember you also need the int1 irq routine.

I would also recommend using 'friendly names' instead of 0x80,0xC0,etc. Setting something to 0 is obvious, but anything else should probably use something like- GICR=(1<<INT1), or GICR=((1<<INT1)|(1<<INT0)), that way its easier to see what you are actually intending to do. Let the compiler do the hard work.

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

Could I suggest you use the following:

// GICR bits
#define IVCE    0
#define IVSEL   1
#define INT2    5
#define INT0    6
#define INT1    7
// GIFR bits
#define INTF2   5
#define INTF0   6
#define INTF1   7
//MCUCR bits
#define ISC00   0
#define ISC01   1
#define ISC10   2
#define ISC11   3
#define SM0     4
#define SM1     5
#define SE      6
#define SM2     7
// MCUCSR bits
#define PORF    0
#define EXTRF   1
#define BORF    2
#define WDRF    3
#define JTRF    4
#define ISC2    6
#define JTD     7

This way you can avoid all the "magic numbers" completely (and make the code more readable/portable) with code such as:

MCUCR = (1<<ISC01) | (1<<ISC00);

While the .h flies supplied with CV don't have all these individual bit names #define'd (about the only negavtive thing I can think of with CV) there is a way for you to generate them yourself. Go to your installation of Studio and check out the xmlconvert.exe program and the PartDescriptionFiles sub-directory

In fact I just used:

..\avrstudio4\xmlconvert -f c -1 atmega16.xml

to generate the attached which you should be able to #include in your program. NOTE that as this stands this will attempt to re-#define all the mega16 port names tat are already in the CV mega16.h flie - so you WILL have to edit this file (and any other you generate with xmlconvert) before use. Edit out the entire contents of the "* I/O REGISTER DEFINITIONS *" section (up to the "* BIT DEFINITIONS *" comment)

Cliff
(T-12 for anyone who's counting)

Attachment(s): 

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

Codevision can't reconice the (bit description) or how it's called.

like a newbie, i made a newbie mistake, i forgot to change the irg routine to int1 <_<. /me hides.

thanks

Robbin

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

Provak wrote:
Codevision can't reconice the (bit description) or how it's called.

Of course it can. It's a fairly standard C compiler and those header files are completely standard C. Just because CV has the non-standard extension (and nice feature IMHO) for bit access uing .N on port names does not mean you can't use "standard" bit name access too.

(T-11)