AVR-Chat

If what you are saying is true (and it isn't) then this very common
programming idiom won't work since an interrupt on the "rjmp" instruction
will cause it to exit. 

Forever:
	Rcall DoThisTask
	Rcall DoThatTask
	Rcall etc
	Rjmp forever

Please re-read my previous response again.  What is pushed is the address of
the next instruction to execute, not the next address.

Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Dennis
Sent: Sunday, August 21, 2005 6:45 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] mega 168

An infinite loop sits there waiting for an interrupt. When the interrupt 
occurs, the stack is pushed with the current location. In the AVR, when the 
RETI happens, the Global interrupt is re-enabled and the stack is popped+2 
for high byte and low byte. That address is the instruction following the 
previous one, the infinite loop, ie. it shouldn't go back to the loop.
D
----- Original Message ----- 
From: "Larry Barello" <yahoo@barello.net>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, August 21, 2005 6:22 PM
Subject: RE: [AVR-Chat] mega 168


Well, one problem leaps off the page: your have infinite loops which will
never exit.  Interrupt handlers return to the next address to FETCH, not the
next address!  When you jump to yourself, the next address to fetch is
yourself.

I recommend you get rid of the interrupt handler and just poll the timer
overflow bit.  Remember to reset it after it is set.  E.g.

loop:
sbis TIRF1, TOV1
rjmp loop
sbi TIRF1, TOV1


-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Dennis
Sent: Sunday, August 21, 2005 10:28 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] mega 168

Here is the code using AVR Studio SP3. As I said, I can put the RETI as the
only instruction in the PBINT1 service routine and the same still happens. I

can also take the infinite loop out of the routine (waiting for T1
interrupt), put it following the first infinite loop, and the same happens.
I'm using visual "breakpoints". The processor is generating triggers to an
STM quad AC switch which drives 3 AC driven strings of LEDs.
D
----- Original Message ----- 
From: "Larry Barello" <yahoo@barello.net>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, August 21, 2005 12:05 PM
Subject: RE: [AVR-Chat] mega 168


It is very, very, VERY UNLIKELY you have stumbled across a CPU problem. It
is very, very LIKELY your code is the problem.  Unless you show us your code
and how you built it (what compiler, etc), there is little anyone can do to
help you.

Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Dennis
Sent: Sunday, August 21, 2005 8:09 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] mega 168

Changed vector names from ZCINT0 to EXT_INT0 and PBINT1 to EXT_INT1 per the
168 data manual. Still the same results. More head banging.
D
----- Original Message ----- 
From: "Mark Nowell" <mark@dicam.co.uk>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, August 21, 2005 1:39 AM
Subject: Re: [AVR-Chat] mega 168


> Dennis
>
> FWIW I'm using both INT0 and INT1 on M168 with no problems ... now. I did
> spend several hours banging my head against these interrupts because a)
> I'd
> used the wrong vector names; b) more than one of the bit defs in the
> avr-libc headers were wrong. The latest WinAVR appears to correct the bit
> defs but it sounds as though you're using asm anyway?
>
> Mark
>
> ----- Original Message ----- 
> From: "Dennis" <dkazar@sbcglobal.net>
> To: <AVR-Chat@yahoogroups.com>
> Sent: Sunday, August 21, 2005 5:31 AM
> Subject: Re: [AVR-Chat] mega 168
>
>
>> When interrupt occurs, EIMSK,1 is set to zero disabling further INT1
>> interrupts. Interrupt routine loads T1 for 50ms debounce timeout and goes
>> into infinite loop waiting for T1 timeout.
>> It really doesn't matter. As I stated before, if I do an RETI as the
>> first
>> instruction in the interrupt routine, it doesn't return.
>> The vectors are all standard assignments for a 168 with 16k flash.
>> Stack appears to operate properly if INT0 and Timer1 interrupts function.
>> It's a bugger. Have sent code to Atmel FAE to get his opinion. Might,
>> maybe
>> get it on Monday.
>> Otherwise, more head-banging.
>> Thanks
>> Dennis
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>





Yahoo! Groups Links











Yahoo! Groups Links











Yahoo! Groups Links









Yahoo! Groups Links











 
Yahoo! Groups Links