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

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

Re: [avr-gcc-list] Set/clear bit?


From: Christian Ludlam
Subject: Re: [avr-gcc-list] Set/clear bit?
Date: Wed, 30 Jun 2004 01:35:24 +0100
User-agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.06) POPstar/2.05

On 30 Jun Pat Deegan wrote:

> It seems sbi/cbi are deprecated
> (http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr.html#a6) but
> couldn't find what we're supposed to use...

Use normal bitwise operations like |= and &=. This hasn't always been
possible, hence the previous need for sbi and cbi macros - these days if you
use, for example, PORTD |= 4, the compiler will generate an sbi instruction
itself.

> As a side note, I've got a register with both in and out pins (PORTD,
> which is also using the UART).  I'm looking to set the upper four bits
> (which are output pins) in the most efficient manner without messing
> with the input pins.  If I just:
> 
> newbits = blah << 4;
> PORTD =  (PORTD & 0x0F) | newbits;
> 
> will it mess with the uart or something?

In this case it's fine because PORTD is read/write. The compiler will
generate code that reads PORTD (once) and writes it (once). One place you
have to be more careful is with registers where bits are cleared by writing a
1 to them (TIFR et al), since in these cases the read catches all set bits,
and the write overwrites them all. In most cases however IO registers are
fully read/write and this problem doesn't arise.

Another reason that your code is ok is that enabling the UART overrides the
setting of the DDRD and PORTD registers, so writes to the relevant bits have
no effect. This is true of most peripherals (nice architecture, innit!)

-- 
Christian Ludlam
address@hidden


reply via email to

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