[Top][All Lists]

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

Re: [avr-gcc-list] >4.5.1 better than this at register-structure (xmega)

From: Erik Walthinsen
Subject: Re: [avr-gcc-list] >4.5.1 better than this at register-structure (xmega) access?
Date: Wed, 10 Oct 2012 16:46:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1

On 10/10/2012 02:24 PM, Weddington, Eric wrote:
Johann is being pedantic. Atmel has their own set of patches, i.e. it *is* a 
private port, because those patches aren't fully submitted upstream yet.
I'm working on getting Atmel's patches upstream.
In the meantime (I'm assuming the delay is the gcc team), any chance of making the set available directly in some "official" location? If I'm going to have any chance of upgrading my toolchain I do not have time to try to extricate everything out of the available Atmel source trees, if they're even remotely up to date in the first place.

But specifically to your problem: I've had a latent concern about the xmega 
register definitions via structure layout. My concern is that the compiler 
would do exactly as you describe and always try to do an address/offset type of 
access to registers.
Concerns as far as whether it should be done at all? I have to say that not having those structures would have made my source very unmanageable. My hardware.h file says things like:

#define ADS1281_SPI SPID

and if my PCB design changes and moves it to another port, I just change the header to match the new revision. Right now I'm even running a the exact same codebase on two different hardware revisions that have different PCB pinouts but are otherwise schematically identical. That's one of the key things I love about the Xmega specifically is the *almost* perfect interchangeability of the ports.

I even have a header file that I've built up over time that does things like:


They basically take the address of the structure (since USARTC0 etc is fundamentally an address) and do an ? : chain to return what I wanted entirely at compile-time.

Also, in the ARM works CMSIS makes register-structures a de facto standard....

But as you said: Does it do that with recent versions? I'm afraid that no one 
yet knows.
If I get a chance to build a new (stock) toolchain with the latest binutils/gcc/avr-libc I'll try to find out.

In the meantime I hacked up a macro that gets me the effect ("fast-struct"):

#define FS(s,m) (*(typeof(s.m) *)((void *)&s + offsetof(typeof(s),m)))

timer = CYCLECOUNTER_MILLISEC.CNT     // "slow"


Now I'd love to know why LAS/LAC instructions don't seem to work, but that's an investigation for later.

reply via email to

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