avr-gcc-list
[Top][All Lists]
Advanced

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

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


From: David Kelly
Subject: Re: [avr-gcc-list] About context saving in Vectors
Date: Wed, 14 Jan 2009 14:29:38 -0600
User-agent: Mutt/1.4.2.3i

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.

-- 
David Kelly N4HHE, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.




reply via email to

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