[Top][All Lists]

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

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

From: David Kelly
Subject: Re: [avr-gcc-list] Problem with timer0 overflow interrupt in clanguage..
Date: Mon, 10 Dec 2007 21:10:06 -0600

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

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.

reply via email to

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