Re: [avr-gcc-list] Question about gcc preprocessing and port/pin assignments

[Ned Konz]

On Tuesday 07 December 2004 10:52 pm, Dave Hylands wrote:

> 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.

But I'm not concerned with writing portable code here. I'm using GCC for a 
single target architecture.

And since my header files are generated automatically, if I change to another 
compiler I just change the script that generates the header files.

> > 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. 

There is a useful distinction between registers whose contents are in fact 
nonvolatile (like for instance DDRB) and those whose contents can be changed 
by hardware events (like PORTB, PINB, and the ADC value registers).

> Trust me, I've written 
> enough device drivers and seen way too much code that only works when
> the optimizer is turned off.

I only define the registers as volatile when their bits could be changed 
outside my program control.

So my example of PORTB above was wrong, as I should have it defined as 
volatile.

However, DDRB (say) does not have to be defined as volatile, since hardware 
isn't going to change it.

My script actually declares *all* the registers as volatile. I have gone in 
later for some of them and removed the volatile declarations (like for 
instance for DDRB, ADMUX, TCCR0, TCCR1, and maybe some others on the Tiny15).

What I haven't figured out a pleasant way to do yet is to deal with those 
cases where an interrupt handler might be changing an otherwise non-volatile 
register.

I suppose that I could define a volatile alias for those cases. But I haven't 
actually needed that yet.

-- 
Ned Konz
http://bike-nomad.com