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.
Agreed.
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.
Agreed.
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
necessary.
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.