brberie 
I have two questions
1. Could anyone please provide link/example how to locate eeprom variables to specific location
2. How to make eeprom variable visible only in one file and NOT initialize it at the same time. Attribute static does first thing but it also initializes variable to 0
Thanks.
MegaTorr ad 1: look for variable attribute "section" in the avr-libc documentation. It explains how to locate RAM varaibles to specific addresses. eeprom works the same way, just a different address range.
ad 2: declare the variable as "extern" in a header file and include that header file where the variable should be visible and where it is declared/initialized.
Markus
Markus, I think you misunderstood brberie's second question. The way I read it, the problem is this:
- The scope of the EEPROM variable should be limited such that it is only visible to other functions contained within the same .c source file, but not to functions that are linked in from other .c files.
- The EEPROM variable should not be initialized.
I'm afraid I don't quite understand, however, exactly what practical benefit brberie hopes to achieve from not initializing an EEPROM variable. By definition, an EEPROM variable's initialization only exists in as much as it shows up as a sequence of bytes within the compiler's .EEP output file. If no particular initial value is wanted, it seems to me that the solution is simply this: don't use the .EEP file.
Or do you want to prevent this particular EEPROM variable from having an initial value, but you do want initial values for every other EEPROM variable? I can see this being a possibility, for example, if the plan is to upgrade an old product which already contains some old EEPROM data, but which needs to have some new EEPROM data "grafted" onto it (presumably in the form of a new .EEP file) without disturbing a portion of the old data.
In my opinion, the easiest way to achieve that wouldn't be through any manipulation of the source code, but rather by using the SRecord tool after compilation is complete, to selectively crop the resultant .EEP file and omit the addresses holding whichever variables which shouldn't have initial values, (which presumably are also the ones that are being located at fixed addresses).
However, if it is true that the EEPROM variables which are planned to be located at specific addresses are the very same EEPROM variables which are not intended to have initial values, then the simple act of placing such variables in a custom memory section ought to be sufficient to ensure that those initializers never show up in the resultant .EEP file, simply by virtue of the fact the the makefile command responsible for generating the .EEP file, by default, doesn't include any memory sections other than the named ".eeprom" section - whatever other name you give for your fixed-address EEPROM section, as long as it isn't ".eeprom", it will not show up in the .EEP file by default.
That being said, care would have to be taken to ensure that:
1) The EEPSAVE fuse is programmed, so that chip erases during the re-flahsing process don't inadvertently erase the very EEPROM data that was supposed to be preserved.
2) The programming software of choice (whatever is used to send the .EEP file to the AVR) knows to interpret gaps in the .EEP file as signals to leave the corresponding bytes untouched, rather than setting them to a default (erased) state.
brberie Thank you for the helpful reply. Just want to add some additional info about second my question.
I have the structure located in EEPROM which shouldn't be touched and some other variables which need to be erased. All this have to be in the scope of one file only.
Thank you for the helpful reply. Just want to add some additional info about second my question.
I have the structure located in EEPROM which shouldn't be touched and some other variables which need to be erased. All this have to be in the scope of one file only.
If you declare the variable at the top of a particular C file, but not within a specific subroutine, then that variable will have "module" scope. All subroutines in that particular C file will see the variable, but not any outside the C file unless you add "extern" to the variable name (in the other C file).
Personally, I like module level of scope and then the use OCCASIONAL "extern" when some other subroutine needs to access the variable, BUT lots of people take a dim view of scope beyond the module., and prefer accessor routines. Sort-of like C++ public functions in a class.
Look up "section" as it regards defining variables. EEPROM is one of the standard sections, and is very very easy to use. This allows the compiler to handle the address of all the variables.
As for initialization, all the programmers I use ISP. JTAG ICE will allow you to initialize EEPROM optionally. Do not use the option at all. Then manually initialize whatever variables you want in the beginning of the program. However, this is not usually a problem unless you are re-programming the CPU with important data in the EEPROM. Usually, there is important data only after the final programming of the CPU.
Alternatively, use external non-volatile RAM, EEPROM, or FRAM. The programmer can't touch that memory even if you want it to.
-Tony
