General Thoughts on EEPROM allocation

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys;

Here is the senario; You have created a super sweet project thats open source so people are always contributing to its growth; now you want to add an EEPROM for the device to utilize for holding settings and whatever else.

Whats the best way to form a solid memory allocation routine?

What i mean by that is i would like to see a function for writing to the eeprom thats smart enough to know where each setting needs to go and to ensure a differnt peripheral isnt overwritting in the wrong spot.

Anyone made a good memory allocation project before?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With flash or SRAM memory, the actual memory locations do not matter. They could change with every build.

However with EEPROM, you want the data to 'survive' between builds.

You either specify absolute locations in the EEPROM, or you use 'EEMEM' named variables. It is possible to mix the two methods, but it requires linker control files.

So the #1 rule of your open source project is that the #defines of the absolute locations never alter.
If you use EEMEM variables, put them all in one module. #2 rule is 'never change the declaration order'.

#2 rule is not really safe. The compiler or linker are both allowed to rearrange or delete unused variables. Using a struct can keep the members in order.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah; I understand that. I was kinda hoping for a more intellegent path; I really want to avoid large .h file full of defines. but i guess there isnt much more that can be done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have an Open Source project, you need to set out some simple ground rules. Using an "eeprom_var.h" and "eeprom_var.c" confines details to a specific place.

One .h file strikes me as easier than twenty or a hundred assorted .c files in an open project.

If you only have a simple private project, you can organise it however you want. Anything more complex and you need some consistent 'rules'.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Group it all in a struct{} and tell the users that any new elements must be added on the end. The linker will place the struct at 0 and it guarantees the layout.

BTW as EEPROM location 0 is the "dangerous one" you may want to make the first struct element:

typedef struct {
  uint8_t dummy_unused_to_avoid_0;
...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

BTW as EEPROM location 0 is the "dangerous one" you may want to make the first struct element:

Is that still the case? I seem to remember that it was only an issue with the earlier models, but was fixed with the later ones. Or is it still "dangerous" if you are not using BOD?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well 48/88/168/328PA manual still has the dire warning about low voltage corrupting EEPROM however it doesn't specifically mention location 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you want to add an EEPROM

Ummm--all you respondents are talking about an AVR's internal EEPROM. OP suggests an external EEPROM. Now, why that would be needed when the AVR has a perfectly good area of EEPROM ...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of my C projects used the !AVR chip which had an explicit persistent variables of that type, not initialized during reprogramming. After adding or removing persistent/eeprom variables the chip kept settings (I suspect it was a job of a compiler in close cooperation with a programmer reordering data on upload) but I didn't go into the details.

Anyway, another problem is you need an additional section in elf file and a smarterdude programmer which will preserve the persistent section during reprogramming (because afaik current dude cannot do that, I am not sure EESAVE helps much).

Perhaps it would be also wise to add some kind of softMPU and an abstraction layer when accessing eeprom locations, r,w,r+w. At least for a Debug version, to keep a Release small. AVRs do not have that smart "break on value" breakpoints (actually no EEPROM location breakpoints) and although you can set EEDR breakpoint on write only (which would indicate a write attempt usually), debugging could become a tedious job when you finally notice (believe me, it is only a matter of time) that "Help, my persistent eemem float gets corrupted".

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

you want to add an EEPROM

Ummm--all you respondents are talking about an AVR's internal EEPROM. OP suggests an external EEPROM. Now, why that would be needed when the AVR has a perfectly good area of EEPROM ...

Already taken; That eeprom is already spoken for + a few other reasons. I would like the external eeprom to be for making sticky settings and perhaps holding a few other things. The device has modes; so I was thinking perhaps a page per mode or somthing of that nature; the first few bytes of each page would be specificly for common settings for all modess; then bytes after that for settings not seen in all modes.