Paul responded off thread
>> I experienced this problem with version 4.3.0, I believe provided by an
>> older version of Ubuntu. Version 4.3.2 (as provided by Ubuntu 9.04)
>> fixed the problem. I assume later versions also work, though I have not
>> verified.
>
I am indeed using 4.3.0
Perhaps
The issue I am trying to draw attention to is that, in my case, the compiler
is not being conservative so the push/pop of volatile registers must be done
manually.
I experienced this problem with version 4.3.0, I believe provided by an
older version of Ubuntu. Version 4.3.2 (as provided b
Weddington, Eric wrote:
>
> Many times in the embedded software world, you have to deal with
> trade-offs.
>
> Sure you could design an ISR that way and do the unit testing the way you
> describe. And I'm sure that it would make your unit testing easier. The
> trade-off though is that it make
t; Subject: Re: [avr-gcc-list] assembly-c mix and interrupts
>
>
> In my opinion, the best algorithm for an interrupt would be:
>
> ISR(vector){
>data=getData();
>processData(data)
> }
>
> then unit testing can be carried out on processData() and
> getD
What I was trying to say was:
ISR(vector){
interruptHandler();
}
interruptHandler() was blindly destroying volatile registers which ISR
should have been preserving since they are the callers responsibility. ISR
was not preserving these registers because it was not aware that these
registers w
darkschine wrote:
> my code was actually already written in C and looked something like:
>
> ISR(vector){
>interruptHandler();
> }
Which is less than ideal because the compiler *always* has to preserve
all the registers that could possibly be destroyed by
interruptHandler(). If possible, a
David Brown-4 wrote:
>
> So any function generated by the compiler, or compatible functions
> written in assembly by hand, can freely use the call-used registers
> (SREG, r18-r27, r30-r31) without preserving or restoring them. But if
> it wants to use the call-saved registers (r2-r17, r28-r
ly ISR, you must do this also.
This might provide you with some more information
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
Julius
> > From: julius.luu...@lut.fi
> > To: avr-gcc-list@nongnu.org
> > Subject: Re: [avr-gcc-list] assembly-c mix and interrupts
>
On Thu, Nov 19, 2009 at 05:08:45AM -0800, darkschine wrote:
> My assembly code follows a standard that ALL registers used are pushed and
> popped from the stack. However, my assembly code does NOT store the SREG.
> Could this be causing my problems?
If it is in the interrupt routine that cpu statu
Your description is rather vague, but in any case i would say that at
interrupt you should save everything you make use of in your routine.
It seems to me that it is very unlikely that you do not make
(indirect) use of the SREG. Thus you have to save (and restore!) it.
From experience i can say t
; Subject: [avr-gcc-list] assembly-c mix and interrupts
>
>
> Before I continue, I would like to suggest a resolution to my
> problem. I am
> using the ATmega328P
> My assembly code follows a standard that ALL registers used
> are pushed and
> popped from the stack. Howe
On Thursday 19 November 2009, darkschine wrote:
> Before I continue, I would like to suggest a resolution to my problem. I am
> using the ATmega328P
> My assembly code follows a standard that ALL registers used are pushed and
> popped from the stack. However, my assembly code does NOT store the SRE
Before I continue, I would like to suggest a resolution to my problem. I am
using the ATmega328P
My assembly code follows a standard that ALL registers used are pushed and
popped from the stack. However, my assembly code does NOT store the SREG.
Could this be causing my problems?
I am coming acro
13 matches
Mail list logo
