C-AVR programming and saving to epprom

[phoenix1990]

so i started learning avr-c programming a few weeks ago and i'm a little confused about using the eeprom so save values.
i've been working a snake game for my project, and i need to save everything at any point to the eeprom so that the user can load it from that spot again.
but first i've been receiving warnings in regard to the way i've been trying to save the the highscore

#include <avr/eeprom.h> 
eeprom_write_word(1, hiscore);
printf("Current High-Score: %d\n", eeprom_read_word(1));
 

those are the only 2 instances where i've actually written to eeprom so far.
and it works so far, without any problems to the game, but the problem is i've been getting warnings saying.

warning: passing argument 1 of 'eeprom_read_word' makes pointer from integer without a cast
 
warning: passing argument 1 of 'eeprom_write_word' makes pointer from integer without a cast
 

and i don't know how to fix the code.
any help would be appreciated
thanks,
phoenix1990

[newb16]

It wants cast? Ok, give it the cast -
eeprom_read_wor d((int*)1)
or something like, depending on declaration of eeprom_read_wor d.

[Banfa]

@newb16
That is quite a bad mistake/assumption to make without further evidence that that is actually required. I know several people that had problems because they did that or something similar.

I think it is more likely that the function expected a pointer to a word(int) but you provided an int

const int *HIGHSCORE_ADDRESS = <someAddressInEEPROM>;
 
highscore = eeprom_read_word(HIGHSCORE_ADDRESS);
 

The point is I suspect the function is expecting you to pass it a location in eeprom to save to, not a number cast to an address. Unless you were very very lucky (int *)1 is most unlikely to be an address in EEPROM.

OK I just Googled the AVR memory map and I take that back, it turns out that for AVR architecture (int *)1 is a valid EEPROM address. Which just goes to prove the point that you can't always generalise (particularly with micro-controllers) things that look dubious from a generalised Standard C point of view can be perfectly correct.

I would still recommend #defining (or using const ints) the locations of you stored parameters in EEPROM rather than hardcoding using magic numbers.

[phoenix1990]

thanks for the help guys, your comments saved me a lot of time.