[Top][All Lists]

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

RE: [avr-gcc-list] Question about gcc preprocessing and port/pin assignm

From: Dave Hylands
Subject: RE: [avr-gcc-list] Question about gcc preprocessing and port/pin assignments
Date: Tue, 7 Dec 2004 22:52:58 -0800

Hi Ned,

I generally try to avoid bitfields. They're not even platform dependant.
They're compiler dependant. This can make it very difficult to write
portable code.

Having the definitions for the bitfields be generated (as you've done)
is a step in the right direction.

Since we're talking about AVR registers, portability isn't quite as much
as a concern, but gcc might not allocate the bits in the same order as
some other AVR compiler. I've only used gcc on the AVR, so I don't know
how relevant this is in this case.

I have worked with numerous compilers though, and I've seen several
different implementation of bitfields on other platforms.

Using the masks and shifts might not look as nice, but at least it
modifies the bits I want them to modify.

I'm not going to go so far as to say that one method is "better" than
the other. Many times it boils down to a particular application.

So anyways, that's my own personal perspective. Take it as you will.

> The compiler will combine these bitfield settings when the 
> register isn't defined as volatile:
> PORTB2 = 1;
> PORTB3 = 1;

Not defining the registers as volatile is like playing with fire. The
compiler can optimize away "redunant" accesses which aren't really
redunant because you're talking to real hardware. Trust me, I've written
enough device drivers and seen way too much code that only works when
the optimizer is turned off.

Dave Hylands
Vancouver, BC, Canada

reply via email to

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