[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] About context saving in Vectors

From: dlc
Subject: Re: [avr-gcc-list] About context saving in Vectors
Date: Wed, 14 Jan 2009 13:41:33 -0700
User-agent: Thunderbird (Macintosh/20081105)

I guess that we agree.  :)

My biggest problem was getting variables established that gcc wouldn't try to save when the ISR started. I've tried "REGISTER", but I couldn't guarantee that the register I'd fixed an index to was really not being used elsewhere, I had one instance where it clearly was corrupted elsewhere, even if it was in the list of registers that various docs say are "available".

I'm used to the PIC (yeah, don't say it) where the IRQ saves the stack and the status register as a hardware function and I could specify easily what was needed to be saved and what not. It just isn't that easy in the AVR with GCC and the code "overhead" in the ISR was staggering to me. I don't yet know all the ins and outs of how gcc/AVR handle ISR's, stack, and other things that I know very well on the PIC. I'll get there.


David Kelly wrote:
On Wed, Jan 14, 2009 at 12:06:54PM -0700, dlc wrote:
Don't quite understand the push/popped reference, but if a variable is
accessed in both interrupt space and "user" space it needs to be
protected so that its uses "atomically".
Here is where I disagree with the gcc implementation. If you have an index to an array that is updated in an ISR and not even looked at outside of that ISR then you need to do nothing with that index variable when you enter the ISR.


Conversely, if you have an index (variable) that is updated outside of
the ISR and not used in the ISR then you don't need to do anything to
the variable/register/memory when you enter/leave the ISR.


You also don't need to be saving/restoring the data in the array when
you enter the ISR since it won't be accessed until after it is written
and the ISR exits.

Agreed. So how does gcc differ?

Perhaps you are alluding to a "local not volatile" (I just made that up)
or some such where a variable doesn't need to be volatile within an ISR?
Some variables do not need to be volatile inside an ISR but must be
volatile outside. IMO its a small price to pay to use the variable as
volatile inside an ISR when it doesn't have to be.

When reading a ring buffer from outside the interrupt one generally
compares the head index to the tail index to know if there is data in
the buffer. An "atom" in an AVR is 8 bits so if one uses 8 bit
indexes then no special care is needed. But if 16 bit pointer that
may span multiple 256 byte pages one must block the interrupt before
reading the variable that the interrupt might modify.

But this is something warranting further study of your specific code.
If instructions are used that read the whole 16 bits without
possibility of an interrupt between the bytes then no protection is
Indeed. If the data is 8 bytes there is _really_ no issue. But even

If the variable is 8 *bits*. Data type in the ring buffer array does not
matter as the use of indexes is keeping you out of entries that are
might be modified during access.

in the case of a 16 bit read/write, if you will not be reading a variable at the same time that you are writing to it, there is no issue.

Yes, thats what we have been saying, if only you *know* the variable is
not being accessed. Are you claiming avr-gcc 4.x is making bulk copies
of things on the way in/out of an ISR?

In the case of variables that are modified inside an ISR they either
have to be the size of an atom or otherwise protected against change
while being used outside of an ISR. Elements of a ring buffer are are
known to be valid and stable for the next few moments based on the
values of the buffer indexes. But the buffer index that gets updated in
the ISR must be atomic when it is accessed from outside.

Dennis Clark          TTT Enterprises

reply via email to

[Prev in Thread] Current Thread [Next in Thread]