AVR Freaks

Well, I was writing my code based upon the examples shown in the .pdf explaining how to use the eeprom, by Dean Camera. In his examples, the eeprom address was just a number (46, to be exact) which, perhaps, defaulted to an int? However, the examples all showed casting that value of 46 to an uint8_t*, not a uint16_t*. So, is this tutorial incorrect, or is there some hidden issue that I'm not recognizing?

This is from the Microschip (Atmel owners now) online reference:

Function eeprom_read_byte()

uint8_t eeprom_read_byte(
	const uint8_t * __p)

Read one byte from EEPROM address __p. 

I don't know how significant the __p syntax shown is, but could that be the source (no pun intended) of the problem? Does __p indicate something more than just a generic variable?

Just for fun, I tried replacing (uint8_t*) with the ampersand (&), and that did not work. No build error, but running the hardware, the eeprom data were not changed. As you can see, I am obviously not very pointer savvy.

At this point, it looks as if using EEMEM might be the way to go. I did a separate small project and fiddled with it, and here's what seemed to work:

/*
 * eepromIntTest.c
 *
 * Created: 1/8/2020 2:01:09 PM
 * Author : Dave
 */ 

#include <avr/io.h>
#include <avr/eeprom.h>

uint8_t eAddress;
uint8_t eData;
uint8_t temp;

uint8_t EEMEM eeData[8];

int main(void)
{
    temp = 0x00;
	for (eAddress = 0;eAddress < 7;eAddress++)
	{
		// write initial value of temp to ee
		eeprom_update_byte(&eeData[eAddress],temp);
		// read it back
		eData = eeprom_read_byte(&eeData[eAddress]);
		// now flip the bits and write back
		eeprom_update_byte(&eeData[eAddress],~eData);
	}
    while (1) 
    {
    }
}

This worked as expected running on the AVRDragon, so I think I'll go with it. I'd still be curious to know about why the AVR GCC reference shows the syntax it does, but for now, no warnings!