Looking in the library for this EEPROM there is a write() function and an update() function.
The parameters are the same, (uint16_t address, uint8_t value).
It looks like the difference is that update() does not write anything if the data already contained in the EEPROM is already at the "new" value.
write() always writes.
Why not always use update(), the chip would last longer like that because it could have fewer writes?
Is it a question of speed? write() will be faster than update()....
Or have I misunderstood something?
I don't think it is speed, I think that it's more a historical thing.
I think (but I don't know much about the history of the EEPROM library) that the library initially could only do read and write. And the user was doing the check if the value did change or not before writing.
Later versions of the library took that pain away by providing the update() function.
But update() will be slower I presume?
Yes. But it would also be slower if you were doing the checking yourself before writing.
Do you want a long life or a fast life 
I want a long AND fast life!
With update() and write() methods, you cannot achive "long AND fast life" of the EEPROM simultaneously.
I know, I was joking.
In my applications I don't need fast access, so I'll go with the long life option of update().
I have no idea what you want to save in EEPROM but if it's anything different from a byte you should look at the put and get functions.
Surprise there is a part called FRAM (Ferroelectric Random Access Memory), not the oil filters. FRAM is a type of non-volatile memory that uses a ferroelectric layer to store data, allowing it to retain information even when power is lost. It offers advantages like faster write speeds and higher durability compared to traditional flash memory. It requires no delays when reading or writing to. It also allows single byte read/write, there is no such thing as sectors. The life cycle is in high the billions or more.
Not necessarily. Writing to the EEPROM is a fairly slow process, much slower than reading and comparing to see if the data has changed. If all the data you are writing has changed, then update() would be slower, but if there are portions that have not changed then update() would likely be faster.
Are you referring to ~3.4 ms write delay per byte?
void setup()
{
Serial.begin(9600);
EEARL = 0x10; //EEPROM location: 0x0010
EEARH = 0x00;
//----------------
EEDR = 0x15; //data to be written
//------------------
EECR &= (0 << EEPM1); //EEPROM programming Mode; Erase and Write
EECR &= (0 << EEPM0);
//--------------------
EECR |= (1 << EEMPE); //Master Programming Bit is active
EECR |= (1 << EEPE); //EEPROM programming is enabled
//--------------------
while (bitRead(EECR, EEPE) != LOW) //EEPE-bit remains HIGH until data write is not done
{
; //wait until writing is done; about 3.4 ms later EEPE-bit goes from HIGH to LOW
}
//--------------
EECR |= (1 <<EERE); //data read enabled
byte n = EEDR; //n = 5
Serial.print("Read from EEPROM Location, 0x0010: ");
Serial.println(n);
void loop() {}
Yes.
Gets a bit more complicated, now that I look at the data sheet. The AT24Cxx chips have a page-mode write, which is much faster than individually writing one byte at a time, but you do need to be aware of the page size for a particular memory chip.
You are correct for AT24XX EEPROM. AT24C32 supports 32-byte page size which can be written in a single ~5 ms write delay instead of 5x32 ms write delay that would be required if one goes by byte mode.
Does internal EEPROM of ATmega328P support page mode?
Looks like it has a page size of 4 bytes, but page access is only available to an external programmer, all access from code is single byte.
Would be glad to know if the page size information is in the datasheet.
It is, section 27.5 page size is given in a couple of tables. The entire section 27 concerns external programming.
Thank you. I have got it.
