From: "Larry Barello" <yahoo@barello.net>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, August 21, 2005 9:33 PM
Subject: RE: [AVR-Chat] mega 168
> 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
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>