avr-gcc-list
[Top][All Lists]
Advanced

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

RE: [avr-gcc-list] eeprom issue


From: Gavin Jackson
Subject: RE: [avr-gcc-list] eeprom issue
Date: Fri, 11 May 2007 10:00:58 +1200

Declaring the RAM variable as static would restrict it's scope to the
module (read .c file) in which it's found according to the C standard.
If one of your .c files was changing the variable and you could see
those changes from the other .c file with both variables declared as
static, then you have certainly found a bug, but one that would have
been found in the early days of the compiler. There must be some other
explanation for what you've observer.

What happens when you try and compile the files, using the RAM variable
but remove the static storage modifier from the front of the
declaration?

Gavin Jackson
-------------------------------------------
Research & Development Engineer
Tru-Test Limited
PO Box 51078
Pakuranga
Manukau 2140
Auckland, New Zealand
DDI +64 9 978 8757
-------------------------------------------

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf
Of Steve Franks
Sent: Friday, 11 May 2007 9:52 a.m.
To: Gavin Jackson
Cc: address@hidden
Subject: Re: [avr-gcc-list] eeprom issue


Sure seemed to me that when I modified the ram var in one file, I
could read the altered values in the other.  I'm not saying it's good
practice, just that it seemed it should have worked, and appeared to
for non-ee values, so maybe the 'bug' would be in the ram values, not
the ee ones, according to your explanation.

Steve

On 5/10/07, Gavin Jackson <address@hidden> wrote:
> Steve
>
> Since the .h file is pulled into each .c file, you would end up with
two
> declarations for temp_ee, hence the two 0x0A values in your ee.hex
file.
> If you remove the static keyword the compiler should complain that you
> have two global variables with the same name. The correct place to
> declare the variable would be in the .c file and not in the header.
>
> You'll find that your static char temp is also using two different
> memory locations, it's just not as easy to see since they're static
and
> don't appear in the map file, but check the addresses being used in
the
> compiled .c files and you'll see they are at different memory
locations.
>
> Regards
>
> Gavin Jackson
> -------------------------------------------
> Research & Development Engineer
> Tru-Test Limited
> PO Box 51078
> Pakuranga
> Manukau 2140
> Auckland, New Zealand
> DDI +64 9 978 8757
> -------------------------------------------
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
Behalf
> Of Steve Franks
> Sent: Friday, 11 May 2007 9:02 a.m.
> To: address@hidden
> Subject: [avr-gcc-list] eeprom issue
>
>
> I think I may have finally found my first legitimate bug!  Then,
> again, maybe not:
>
> 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;
>
> 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
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>


-- 
Steve Franks, KE7BTE
Staff Engineer
La Palma Devices, LLC
http://www.lapalmadevices.com
(520) 312-0089




reply via email to

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