Using EEMEM inside a struct

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
dpaulsen
dpaulsen's picture
Level: Hangaround
Joined: Thu. Apr 27, 2006
Posts: 257 View posts
Location: San Jose, CA
#1
Posted by dpaulsen: Tue. Aug 3, 2010 - 09:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eventually what I am trying to do is to have my MCU keep an error log in eeprom,

In the past I have accomplished this by defining an array in eeprom. I kept track of the location of the next free space by writing 0xff to the next available spot. Every time my mcu would reset, one of the first thing it would do in the initialization is to poll every element in the eeprom until it got to a 0xff. Then it would store the element number of this location into a SRAM variable.

I thought it might be a little cleaner if I tried to put the eeprom array and the element number in a struct.

Here is my declaration:

struct ee_log_t {
uint8_t index;
uint8_t EEMEM list[256];
} reset_log, error_log;

I get a compiler error:

Quote:

Terminal.h:4: error: section attribute not allowed for 'list'

Did I get the syntax wrong or is this simply not allowed?

Tags:

Tools, Compilers and General Programming
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97852 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Aug 3, 2010 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely you want the whole thing in EEMEM?

typedef struct { 
uint8_t index; 
uint8_t list[256]; 
} ee_log_t;

ee_log_t EEMEM reset_log, error_log;

Top
dpaulsen
dpaulsen's picture
Level: Hangaround
Joined: Thu. Apr 27, 2006
Posts: 257 View posts
Location: San Jose, CA
Posted by dpaulsen: Tue. Aug 3, 2010 - 09:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely you want the whole thing in EEMEM?

typedef struct { 
uint8_t index; 
uint8_t list[256]; 
} ee_log_t;

ee_log_t EEMEM reset_log, error_log;

The only reason I can think of for not doing it that way is if you loose power while writing to index, you will loose your place.

Of course if my MCU gets hit by a meteorite, it might loose it place also, and I didn't account for that :).

Your way might work fine for what I am using it for.

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2672 View posts
Posted by curtvm: Wed. Aug 4, 2010 - 03:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are simply checking for the first 0xFF in eeprom, you don't need to keep an index. Just 'find' the next location by searching for it in your log routines. I can't imagine speed is important since you are not going to be logging that often (this is eeprom after all).

log_routine(){
x=get_next_avail_ee();
//log data
}
get_next_avail_ee(){
//find first 0xFF following !0xFF
//make sure 'next' ee is erased
return address;
}

Quote:
Did I get the syntax wrong or is this simply not allowed?
Think about what you are trying to do. You want part of the struct in ram, part in eeprom. You no longer have a consecutive 'group' of addresses, and it is no longer a struct, which is why the compiler complains.

Top
dpaulsen
dpaulsen's picture
Level: Hangaround
Joined: Thu. Apr 27, 2006
Posts: 257 View posts
Location: San Jose, CA
Posted by dpaulsen: Wed. Aug 4, 2010 - 09:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
If you are simply checking for the first 0xFF in eeprom, you don't need to keep an index. Just 'find' the next location by searching for it in your log routines. I can't imagine speed is important since you are not going to be logging that often (this is eeprom after all).

log_routine(){
x=get_next_avail_ee();
//log data
}
get_next_avail_ee(){
//find first 0xFF following !0xFF
//make sure 'next' ee is erased
return address;
}

Quote:
Did I get the syntax wrong or is this simply not allowed?
Think about what you are trying to do. You want part of the struct in ram, part in eeprom. You no longer have a consecutive 'group' of addresses, and it is no longer a struct, which is why the compiler complains.

Thank you for helping me understand. I guess I never really thought of a struct as a fancy array, but thats all it really is.

Also for some reason I was thinking that reading from eeprom was slow, but now that I think about it, the time involved to read 250 bytes of eeprom is 250 x 0.5 us = 125 us (6 cycles at 12Mhz), where as writing twice makes my program stall in a wait loop for 3300 us. Good call.

Top