Re: [avr-gcc-list] eeprom issue

[David Brown]

Steve Franks wrote:
> I think I may have finally found my first legitimate bug!  Then,
> again, maybe not:

It's not a bug, at least not in the compiler!

> Anyway, if you have a project with two C/C++ sources, both of which
> include the same header, and you have:
>
> static char temp_ee __attribute__((section (".eeprom"))) = 10;

Here you have done two things wrong.

First, the use of "static" at file scope means that the data (or 
function) is only visible with the C code you are compiling.  The easy 
way to think of "static" is to pretend that the compiler tags "file_" to 
the front of every "static" item it sees when compiling "file.c".  Think 
about that, and you'll understand why the compiler generated the code it 
did.

C gives you lots of freedom to make a complete mess of your headers and 
C files.  Here is the short guide to sanity:

The header file "module.h" contain "extern" declarations, saying what 
data (and functions) "module.c" exposes to the rest of the world.  The 
header is wrapped in "#ifndef __module___ ..." protectors.  Anyone using 
the module should find all relevant information, including declarations 
and comments, in "module.h".  They should see nothing of the 
implementation.

The file "module.c" contains the implementation.  It has #include's 
module.h, and defines all the data and functions declared with "extern" 
in the header file.  All other data and code that is private to the 
module, is declared "static".

The only time I ever use "static" in a header file, is for "static 
inline" functions to act as type-safe macros.

There are, of course, many other opinions - but please read and 
understand the above suggestions first (and I guess any follow-ups 
should go to avr-chat).


The second big mistake you made is declaring "eeprom" data in more than 
one place.  Be aware that any re-compile of the program could re-arrange 
the variables in the .eeprom segment, making it impossible to update the 
program in a running system without wiping the eeprom data.  If you want 
to get consistent placement of the data, use a "struct" and make all 
your eeprom data fields of the struct.

mvh.,

David




> in the header, if you build, you will see 0x0A at two locations in
> your ee.hex file.
>
> I don't have an example at the moment, because I had to deliver to a
> customer, so naturally, I moved the variable definition to one C file
> only, and pointed to the ram value I load it into in the header.
>
> static char temp (w/o the EE attrib) appeared to work fine in the same
> header, so it appears to be a unique error to the EE attrib.
>
> If we elevate this to, "yes, it may actually be a bug, Steve's not
> just clueless", then I'd be happy to regenerate the example code.
> Thought I'd check with y'all first.
>
> Steve