AVR-Chat

Yes, I can see that the structure will provide a convenient 
technique to read & write the entire block.

It has been a long time since I worked with structures.  Is there a 
way to get the offset of the element within the structure?  
Something like "&structure.element".  This way, I can start with the 
location of the structure in SRAM or in EEPROM and then access the 
individual element by base + offset.  Will sizeof() work with 
structure elements?

I keep forgetting what stuff I used to do was in C++.  Like I was 
sure I could pass a variable by reference and then use it as a 
regular variable in the called subroutine (instead of dereferencing 
by using *var).  Nope that was C++.

I used to get slightly into the object oriented structures, but I 
found it more confusing that more simple structures.  I forget if 
the dot operator (I seem to remember that is its name) is C++ only.

I obviously have more homework to do.

It is impressive (to me) how fast C is coming back to me considering 
I only used it for about 2 years continuously, then 4 years 
intermittently, then not at all for the last 12 years.

-Tony



--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> On Mon, Apr 25, 2005 at 05:12:13PM -0000, arhodes19044 wrote:
> > 
> > 
> > Actually, that struct idea is just perfect.
> > 
> > I definitely was planning on keeping an SRAM version of the 
> > variables, then only save the requesite info when necessary.
> > 
> > One of these will be a "first-run" flag which will allow 
> > initialization of the EEPROM, then there are some setting and 
> > calibration values to keep.
> 
> You can compile the default values of your EEPROM contents into 
your
> code by placing them in the .eeprom section. This way the ISP 
and/or
> JTAG programmer will write them when the FLASH code is written 
during
> production.
> 
> As for the syntax of compiling EEPROM variables all I can say 
is, "I've
> done it" but don't have an example under my fingertips or in CVS. 
IIRC
> the variables were defined in a .c source file reserved 
specifically for
> this purpose. In the Makefile this one source file was compiled 
with an
> option to map .data to .eeprom, or some such thing.
> 
> It may be one can tag the variable with an attribute to place it in
> EEPROM.
> 
> One has to be careful with this sort of mapping to EEPROM because 
these
> variables can not be reached without special handling, yet appear 
to
> have addresses same as any other variable.
> 
> So one might use a typedef to define the struct which is to contain
> EE-backed data. Then use the typedef to allocate one in eeprom and
> another in sram.
> 
> //  in ee_backed.h file place something like this:
> typedef struct {
> 	uint32_t	serial_number;
> 	uint8_t		cal[8];
> } EE_BACKED;
> 
> // in a code file place something like this:
> #include "ee_backed.h"
> EE_BACKED sram_ee;
> 
> // then in a special file just for ee variables:
> #include "ee_backed.h"
> uint8_t	im_afraid_to_use_byte_0;
> EE_BACKED ee_ee.
> 
> Then someplace, probably your startup code in main():
> 
> eeprom_read_block( &sram_ee, &ee_ee, sizeof(sram_ee) );
> 
> The whole point is to make the compiler do the work of allocating a
> local copy and of keeping track of where the data was stashed in 
eeprom.
> 
> -- 
> David Kelly N4HHE, dkelly@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.