Getting all data from EEPROM and save it during run

Say my EEOROM is full of data, then when the program start I would like to read all the data , say its 950 bytes, then save it somewhere forever, so I can use it during the program runtime .

the problem is, you can’t declare array of 950 characters to save it to, so if you have a 1k EEPROM, how did they think I can use all of it anyway ?

I guess I don’t really understand it deeply enough, so I will be happy to hear about a solution.

(assuming you can’t iterate over the EEPROM every cycle of your program loop )

Thanks a lot.

gil22: (assuming you can't iterate over the EEPROM every cycle of your program loop )

I can't help you with your other questions, but just as a word of advice, it is not advisable to reiterate your EEPROM data during each cycle. EEPROM is flash memory and therefore has a limited number of read and writes much like an SSD. From what I saw online, the EEPROM on an Arduino has about 100000 read/write cycles before it will start to go bad. If you are changing the values of your EEPROM data every cycle through the loop, it won't last very long.

Why not just read it as it’s needed?
Otherwise:

#include <EEPROM> // or whatever the syntax is
void setup(){
  for (x=0; x<950; x=x+1){
  dataArray[x] = EEPROM.read[x]; // same here - check syntax
  }
}

Libraries page, EEPROM is first one listed.
https://www.arduino.cc/en/Reference/Libraries

But it's already stored in the EEPROM. There's no need to copy it. Reading the EEPROM is basically free. It takes a small fraction longer than reading normal SRAM. The number of reads is unlimited. However the number of writes does have a limit, so don't use EEPROM for variables that change more often than one per second.

MorganS: There's no need to copy it.

Exactly. When I read the OP's comment, I felt like he was saving some sort of configuration data that doesn't need to be updated (or rarely so), but just read in an on-demand basis. Perhaps more detail about what is being done with the 950 characters would help explain the need.

Thanks guys.
Well the thing is that there is some kind of configuration “file” (text) saved on the EEPROM once in a while by a user( of course not every cycle).

BUT, the program needs to read these values EVERY cycle of its loop in order to know what to do, so it has to be available to the program ALL the time .

I could see that reading from EEPROM is not limited ( ? ) , is it right to actually access an EEPROM every cycle and read it ?

is it takes time ? ( like more then few ms to read the whole 950 bytes)
is it the right way to go ? or there are other ways to work inside the main loop with a big configuration file like that?

Thanks.

BUT, the program needs to read these values EVERY cycle of its loop in order to know what to do, so it has to be available to the program ALL the time .

Why? Unless you wrote to EEPROM in the last cycle, the values didn't change. If you did write in the last cycle, you know what you wrote, and where you wrote it.

I don't see the problem.

Read is absolutely no issue, so you can do it every time the application is powered up. I don't see a reason why you want to read it every cycle, when the information wasn't changed.

If the user changed something, you should store that information in a variable which is read every cycle and if something was changed you re-read the content of the EEPROM.

How long it takes - I have no experience; so give it a try and measure the time. As this would be done only rarely it might not matter for the application as such.

Edit: AWOL was quicker :) He is right stating that when the user modified something, your sketch should notice the edit and then you just can replace the previous content with the new one and you don't need to read the flag every cycle.

michaelsm: From what I saw online, the EEPROM on an Arduino has about 100000 read/write cycles before it will start to go bad. If you are changing the values of your EEPROM data every cycle through the loop, it won't last very long.

It basically has unlimited read cycles. It's the writing that kills the eeprom eventually.

@AWOL and others, you right, but the reason I need it every cycle is because it has some logic in it, not just booleans and strings, see it as an interpreter that saved all commands in the EEPROM, and the main loop is done according to this commands.

  1. if it had only booleans for examples, how would you do it without saving them somewhere? say the main loop has to do things according to 900 booleans , like process some data, even if you don't change it last cycle, you need to check for it inside the loop, so it has to be saved somewhere ( ? i am not sure I get you )

2.if the EEPROM has some strings that actually determine the whole logic inside the main loop ( something like interpreter that saved commands into eeprom) , you will also need to access it every cycle, so it has to be saved some where ?

Why at all do you want to save the logic operations into the EEPROM?

If you need the EEPROM content every cycle - I still have not understood why you don't copy it in the normal working area once while setup() runs atbthe very beginning of the sketch - and then you just modify when a change has happened.

Or do you expect that the user modifies values,which have to be stored back into EEPROM every single cycle - then your user must have very fast fingers.

If a modified value has to be saved permanently not being lost at powering off - store it into EEPROM, re-read the logic of EEPROM if you can't put it into a volatile variable, and only WRITE when a change happens.

During operation you can work with the content of your EEPROM in the RAM of the Arduino.

900 booleans fit in less than 125 bytes ;) You can use bitfields.

struct VARIABLES
{
  unsigned long bool1: 1;
  unsigned long bool2: 1;
  unsigned long id: 6;
  ...
  ...
};

VARIABLES cfg;

void setup()
{
  Serial.begin(9600);

  Serial.print("size of cfg: ); Setial.println(sizeof(cfg));

  if (cfg.bool1 == true)
  {
    Serial.println(cfg.id);
  }
}

The above struct will occupy 4 bytes till you have used all 32 bits. You can keep expanding, between 33 and 64 bits it will use 8 bytes, between 65 and 96 bits it will be 12 bytes and so on.

VARIABLES contains two bools each occupying a single bit and a 6 bit id field.

Can't work out more as I'm using a tablet at the moment.

I see it as a valid technique to reduce SRAM usage. If the EEPROM values are changed infrequently then there's no problem with reading them frequently. Treat it as a special storage location for the "instructions" to be interpreted and start from the top on every loop.

I haven't looked too closely at the EEPROM timing. I suspect that reading 900 bytes out of the EEPROM might take a millisecond or two.

I thought I read that reading EEPROM takes a clock cycle or two longer than SRAM due to having to set up an address register.

Wow, its hard..

I DO NOT need the EEPROM values every cycle, and its not changed every cycle but consider this pseudo :

1.program starts 2.read from EEPROM your 7 commands for the lifetime of this program ( interpreter! like Firmata) 3.save them somewhere ( **** otherwise how can I use them later?? )

loop () read saved command 1 and perform it read saved command 2 and perform it ... ... ...

So, how can my loop perform these commands ? option 1 -read each command from EEPROM every loop, option2 read them from somewhere else (then we must had save them)

Read statement from eeprom Execute statement

Read next statement Execute next statement from eeprom

Read next statement Execute next statement from eeprom

Etc etc etc

You can time how long e.g. 1000 read cycles take and see if it suites your needs

Say you had a selection of 100 “commands” available and you wanted to run, 7 at a time every time.
Then you could do something like this:

void setup (){
Serial.begin()(9600);
while (Serial.available()<6){
// hang out until 7 one byte commands come in - can be smarter, do some data checking?
// maybe two byte commands, example: 'flash leds' command, along with the # of 
// times, or 3, with duration of a flash, etc. Or maybe that chain of bytes is the// only command, and the balance of the 7 are just null data that get ignored.
}
// data received, proceed. Or do the data checking before storing a byte to EEPROM
EEPROM.write(0, Serial.read() );
EEPROM.write(1, Serial.read() );
EEPROM.write(2, Serial.read() );
EEPROM.write(3, Serial.read() );
EEPROM.write(4, Serial.read() );
EEPROM.write(5, Serial.read() );
EEPROM.write(6, Serial.read() );
x = 0;
}
void loop(){
if (x==7){
x=0; // reset to initial command - or maybe hang out like above waiting for another command?
}
command = EEPROM.read(x); // read the "command" to perform
switch(command){
case 0: //
// do features of that command
:
:
x=x+1;
break;
case 1: //
// do features of that command
:
:
x=x+1;
break;
:
:
case 99: //
// do features of that command
:
:
x=x+1;
break;
} // end switch
} // end loop

otherwise how can I use them later??

Read them from the EEPROM as and when you need them.

Thanks a lot guys.

So the simple answer is just to read it directly from the EEPROM, I wasn’t sure if thats “ok” to do.
Thanks.

I wasn’t sure if thats “ok” to do.

There may be some advantage to copying data from EEPROM to RAM and accessing it from there if speed were an issue, but otherwise accessing it from EEPROM when needed seems the obvious thing to do.

As has been said earlier you can store 8 “boolean” (HIGH/LOW, true/false) values in a single byte in the EEPROM at the expense of slightly more overhead in accessing them, but it could reduce the number of EEPROM reads needed.

What sort of application are you programming ?