[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Re: External EEPROM verses internal EEPROM data handl
From: |
Daniel O'Connor |
Subject: |
Re: [avr-gcc-list] Re: External EEPROM verses internal EEPROM data handling |
Date: |
Mon, 4 May 2009 23:17:31 +0930 |
User-agent: |
KMail/1.9.10 |
On Mon, 4 May 2009, David Brown wrote:
> Daniel O'Connor wrote:
> > On Mon, 4 May 2009, Bob Paddock wrote:
> >>> uint16_t voltage[24]; // adc counts of 24
> >>> channels in an array } ED; // total data = 58 bytes
> >>
> >> Because of issues of structure packing it is better to define
> >> structure items from
> >> the largest to the smallest, ie. uint16_t should be first. This
> >> is more important
> >> on 32bit processors and up than on the 8bit AVRs.
> >
> > You could just mark the struct as packed, eg..
> > typedef struct eventdata {
> > ...
> > } __attribute__ ((packed)) ED;
>
> Or use the -wpadded warning flag, which will let you know if any
> implicit padding has been added (I prefer to explicitly add padding
> if it is required).
>
> Of course, you don't get padding on an 8-bit AVR (except for bit
> fields), but it's good to write portable code when practical.
Padding is going to be unportable between architectures.. May as well
take advantage of the compiler extensions. (IMO :)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling, Steven Michalske, 2009/05/04