I want to know about EEPROM life span...

It is said that the EEPROM memory has a specified life of 100,000 write/erase cycles…

SO what happens after that…??

I mean to say after we have already written/read 100,000 times what will happen…??

After, that, you can't rely on the values you read back.

I presume that the chemical or electrical changes will gradually degrade. Thus if they specify 100,000 cycles, some time after that it will become unreliable. For example, it might not erase (0 bits turn to 1 bits) or you might not be able to write (1 bits turn to 0 bits). Sooner or later then, what you write won't be what read back later.

If you are worried you could read back after writing, and if it isn't what you wrote, write again, and repeat until it is the same.

You could also devise some strategy of working your way through memory. For example, for the first 100,000 cycles, write to address 10, and then to address 11 for the next 100,000 and so on. Then write to address 0 the number of the "real" address (the write to address 0 only has to be done once every 100,000 cycles).

Joy:
I mean to say after we have already written/read 100,000 times what will happen...??

Just to clarify, that is 100,000 write cycles - reads are not a problem at all. One way to help with this is to check the data before writing it - if it already exists in eprom, then don't write it. If it IS different, then only write the difference. For many data items (like settings) this reduces 'wear' on the bits by a great deal.

Good idea. It would also speed it up.

That is a good idea instead… :slight_smile:

Ok ...
I wrote a code which reads an IR remote value and decode it to switch ON / OFF an LED with a button on the remote
another button to switch ON / OFF another LED and other two buttons to control the brightness of the LED..

This is a project I am building to control home appliances by remote..

now I have to write the current position of the OUTPUTS to the EEPROM so that if there is a power-cut and when the power comes back the OUTPUTS are in the same position..

That was a good point to write to the EEPROM only when there is a change else not...

But can someone give me some hints plz...I am still trying... :frowning:

A hint about what?
Just put a simple "wrapper", something like:

void myWrite (int address, int val)
{
  if (val != readEEPROM (address)) {
    writeEEPROM(address, val);
  }
}

AWOL:
A hint about what?
Just put a simple "wrapper", something like:

void myWrite (int address, int val)

{
 if (val != readEEPROM (address)) {
   writeEEPROM(address, val);
 }
}

See that way u r reading the EEPROM every time before writing...

So I think It will be better to write to EEPROM only the time there is a change in the OUTPUTS ...else no...

I may be wrong too...:frowning:

See that way u r reading the EEPROM every time before writing...

So?
Reading is much quicker than writing.
Is there some time-critical element about what you have in mind?
How else are you going to see what you want to write is different to what is already there?

AWOL:

See that way u r reading the EEPROM every time before writing...

So?
Reading is much quicker than writing.
Is there some time-critical element about what you have in mind?
How else are you going to see what you want to write is different to what is already there?

no no...
I meant to say that if u r not writing but reading every time to check if the value is same, that means u r reading and reducing the cycle from 100,000

There are no limits on reading (except maybe the half-life of silicon) - where did you get that idea?
The limits are on erase/write.

Ohh sorry..That was my mistake... :stuck_out_tongue:

I have re written the code to save the states of the PIN3 output if there is a change…

#include <IRremote.h>
#include <EEPROM.h>
int pin1 = 3;
int pin2 = 4;
int pin3 = 5;
int RECV_PIN = 11;
int fadered = 5;
int pin1State = LOW;
int pin2State = LOW;
int val;
int state;

int btnCnt;

IRrecv irrecv(RECV_PIN);
decode_results results;

void setup()
{
  irrecv.enableIRIn();
  pinMode(pin1, OUTPUT);
  pinMode(pin2, OUTPUT);
  pinMode(pin3, OUTPUT);
  fadered = EEPROM.read(1);
  
  /********** THIS IS TO READ WHAT WAS THE STATE OF PIN3 SAVED LAST TIME ***********/
  
  btnCnt = EEPROM.read(2);

      if(btnCnt % 2 == 0)
         analogWrite(pin3, 0);

      else
         analogWrite(pin3, fadered); 
}
void loop() {
  if (irrecv.decode(&results)) {
    
    /********** THIS PART IS FOR PIN1 ************/
    
    if(results.value == 0xffb24d){
      pin1State = !pin1State;
      digitalWrite(pin1, pin1State);
      
    }
    
    /********** THIS PART IS FOR PIN3 ************/
    
   if(results.value == 0xff38c7){
       btnCnt++;
      if(btnCnt % 2 == 0)
         analogWrite(pin3, 0);

      else
         analogWrite(pin3, fadered); 
   }
    
    if(results.value == 0xff7887 && fadered <=250){
      fadered = fadered + 5;
      analogWrite(pin3, fadered);
    }
    
    if(results.value == 0xff50af && fadered >=10){
      fadered = fadered - 5;
      analogWrite(pin3, fadered);
    }
    
    /********** THIS IS FOR SAVING THE BRIGHTNESS VALUE IN EEPROM ************/
    
      val = fadered;
          if(val != EEPROM.read (1)){
        EEPROM.write(1, val);
    }
    
    /********** THIS IS TO SAVE THE LAST STATE OF THE PIN3 ************/   
      
         state = btnCnt;
         if(state != EEPROM.read (2)){
        EEPROM.write(2, state);
    }
    irrecv.resume(); 
  }
}

I have uploaded the code to the board to check if it is saving and getting back to the last position of the PIN3 state each time I am resetting …
Please check out if I am WRITING SAFELY…
I mean to say if I am writing to the EEPROM if ONLY there is a change… Because I am still lil in confident and frightened that i am writing to the EEPROM every time the loop is running…
It may be that as I am new to coding I am writing things in a long way plz correct me in those parts which could have been made short to save the space… :stuck_out_tongue:

The Jeelabs dude did some destructive eeprom testing on a 168: http://jeelabs.org/2011/05/11/destruction/

EEPROM is more durable than previously suspected.

What I’ve done in the past with EEPROM programs is to save any/all changes to the values I want to store, but only after it’s been a couple seconds.
If you power the thing off in that time you’ll lose the data, but 100,000 writes at two seconds per write is a very long time indeed.

That's less than 2.5 days of continuous runtime, that's not a lot even for a toy.

Atmels spec for EEPROM is a minimum guarantee, not a maximum lifetime. Many will program for many more than 100k cycles, but it could begin failing at 100,001 writes and still be in spec.

  val = fadered;

if (val != EEPROM.read (1))
  {
  EEPROM.write(1, val);
  }

That looks OK to me. But a couple of things ... The EEPROM writes bytes (not ints) at a time, so how about changing:

int fadered = 5;
int pin1State = LOW;
int pin2State = LOW;
int val;
int state;

to:

byte fadered = 5;
byte pin1State = LOW;
byte pin2State = LOW;
byte val;
byte state;

If there is some reason byte won't work, then the EEPROM saving won't work either.

And then make it more self-documenting:

#define EEPROM_BRIGHTNESS 1

...

  fadered = EEPROM.read (EEPROM_BRIGHTNESS);

...

 if (fadered != EEPROM.read (EEPROM_BRIGHTNESS))
  {
  EEPROM.write (EEPROM_BRIGHTNESS, fadered);
  }

Now you won't get confused about which one is the brightness and which one is the state.

And if you really have worn out your EEPROM, they work in "pages". If you have worn it out you have probably worn out a page not a byte. If it doesn't work try going up 128 bytes (eg. use 128/129 rather than 1/2).

thank you so much for correcting those parts Nick.. :slight_smile:

And if you really have worn out your EEPROM, they work in "pages". If you have worn it out you have probably worn out a page not a byte. If it doesn't work try going up 128 bytes (eg. use 128/129 rather than 1/2).

@ Nick... I have not worn out my EEPROM..

but I am just trying to get sure of my code that I am only writing to the eeprom when it is necessary and not everytime uselessly and reducing its life....