Re: [avr-gcc-list] Problem with timer0 overflow interrupt in clanguage..

[David Kelly]

On Mon, Dec 10, 2007 at 12:51:31PM +0100, Schwichtenberg, Knut wrote:
> On Friday, December 07, 2007 5:24 PM, David Kelly wrote:
> > The compiler won't read PINB using the above.
> >
> > In general on AVR when one reads PORTB one reads the output latchs,  
> > in
> > other words the last value written. On other CPU's this same
> > action may
> > read the input buffers. AVR provids PIN ports for specifically  
> > reading
> > the state of the external pins.
> >
> > Using -O1 the above exclusive-or-equals generates exactly the
> > same code
> > as the OP first wrote:
> >
> >        PORTB = ~PORTB;
> > 3ee:   85 b1           in      r24, 0x05       ; 5
> > 3f0:   80 95           com     r24
> > 3f2:   85 b9           out     0x05, r24       ; 5
> >        PORTB ^= 0xff;
> > 3f4:   85 b1           in      r24, 0x05       ; 5
> > 3f6:   80 95           com     r24
> > 3f8:   85 b9           out     0x05, r24       ; 5
>
> This result is unambiguous. The question is: Is this a bug which means
> a bug report is necessary or is it a feature that needs to be
> described?  It would be comfortable if GCC could distinguish between
> the IO-ports and other IO-variables were the in and out address are
> identical.

I don't think there is anything wrong. Is perfectly legal to read PORTB.
Would be completely wrong for the compiler to read PINB for either of  
the
above situations when its told to use PORTB. If one wanted PINB then
write "PORTB = ~PINB".

My original point was that one should use care and think about these
things because on some MCU architectures (and maybe some variants of
AVR) one reads input values from the same place one writes new outputs.
That reading reads the state on the pin which may be forced externally
to a different value than one wrote, so code as shown above would never
toggle a pin that was shorted or pulled hard high, it would always try
to drive it the other way.

The OP was not seeing his LED flash. If an LED loaded the circuit too
much the MCU would not have seen valid logic levels on PINB.

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