[Solved]Want to know how long it takes to read the whole EEPROM.

Hi!

We have this one project with my friends that is gonna have a lot of EEPROM reads. We would need to know how much does it take to read 1024 bits from EEPROM. I wrote this code but i'm getting weird output. Well maybe not that weird (6 milliseconds) but i wanted you guys to verify does my code seem right? So here it is:

#include <EEPROM.h>
unsigned long start, finished, elapsed;
// start reading from the first byte (address 0) of the EEPROM
int address = 0;
byte value;

void setup()
{
  // initialize serial and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }
}

void loop()
{
  if (address == 0){
    start = millis();
  }
  // read a byte from the current address of the EEPROM
    value = EEPROM.read(address);
  
  
  
  // advance to the next address of the EEPROM
  address = address + 1;
  
  // there are only 512 bytes of EEPROM, from 0 to 511, so if we're
  // on address 512, wrap around to address 0
  if (address == 1024){
    finished=millis();
    elapsed=finished-start;
    Serial.print(elapsed);
    Serial.print('\n');
  }
  
   
  
}

Seems a bit long winded... Any why not use micros() to get much better accuracy? Why not simply:

start = micros();
for (address = 0; address < 1024; i++) {
  value = EEPROM.read(address);
}
end = micros();

Serial.print("Elapsed: ");
Serial.print(end - start);
Serial.println("microseconds");

the whole 1024 bit EEPROM.

Which processor do you have - none that I know have that small an EEPROM.

if (address == 1024){

At this point you're already incremented to & read from the final address, so test that you are there:

if (address == 511){
or
if (address == 1023{
or
if (address == 2047){

depending on the chip being used.
And reset address to 0 to start the next pass.
You migth get more accurate results using micros() also instead of millis.
Make sure all time elements are of type unsigned long.

AWOL:

the whole 1024 bit EEPROM.

Which processor do you have - none that I know have that small an EEPROM.

The ATmega328 has 1 KiB of EEPROM.

AWOL:

the whole 1024 bit EEPROM.

Which processor do you have - none that I know have that small an EEPROM.

...But I thought all the Atmel chips were two bit chips ]:smiley: (ducks)

majenko:
Seems a bit long winded... Any why not use micros() to get much better accuracy? Why not simply:

start = micros();

for (address = 0; address < 1024; i++) {
 value = EEPROM.read(address);
}
end = micros();

Serial.print("Elapsed: ");
Serial.print(end - start);
Serial.println("microseconds");

Thank you very much. This worked out for me. :slight_smile:
And in case someone else wants the answer, it takes 2720 micros to read 1024 bytes from atmega328 EEPROM.

The ATmega328 has 1 KiB of EEPROM.

kibibit != kilobit,

AWOL:

The ATmega328 has 1 KiB of EEPROM.

kibibit != kilobit,

Thank you for that. I thought all the time that it would only have 1024bits. I feel a bit stupid right now but lets say that I misread it :smiley: You helped me with my project by telling me that. :slight_smile:

AWOL:

The ATmega328 has 1 KiB of EEPROM.

kibibit != kilobit,

Also, kibibit != kibibyte...

I know, new-fangled money - you say tomato, I say tomato.

AWOL:
I know, new-fangled money - you say tomato, I say tomato.

Except, that's more like you say tomato and I say a tomato plant.

KiB is 1024 bytes. Kib is 1024 bits. A capital B always signifies bytes. It's like M and m for Mega and milli.

AWOL:

The ATmega328 has 1 KiB of EEPROM.

kibibit != kilobit,

If you are going to split hairs, KiB is neither kibibit nor kilobit. It is kibibyte. And while we are splitting hairs, 1KiB == 1024B so he was using the correct technical term. (1KB == 1000B) See: Byte - Wikipedia Now further questions arise, is the Atmel Datasheet incorrectly (but commonly) using kilo to mean 1024 where it states the 328 has "1K Bytes" of EEPROM (table 2.1)?

And closer scrutiny of this thread shows the OP confusing bits with bytes, so maybe your admonishment should have been:
kibibyte != kibibit (KiB != Kib)

@ Jokke
You should mean:

it takes 2720 micros to read 1024 Bytes from atmega328 EEPROM.

Edit: PS. Sorry for jumping all over you, AWOL. Looks like several of us have just been waiting for you to make a mistake. Finally, proof you are also human. XD

Sembazuru:

AWOL:

The ATmega328 has 1 KiB of EEPROM.

kibibit != kilobit,

If you are going to split hairs, KiB is neither kibibit nor kilobit. It is kibibyte. And while we are splitting hairs, 1KiB == 1024B so he was using the correct technical term. (1KB == 1000B) See: Byte - Wikipedia Now further questions arise, is the Atmel Datasheet incorrectly (but commonly) using kilo to mean 1024 where it states the 328 has "1K Bytes" of EEPROM (table 2.1)?

And closer scrutiny of this thread shows the OP confusing bits with bytes, so maybe your admonishment should have been:
kibibyte != kibibit (KiB != Kib)

@ Jokke
You should mean:

it takes 2720 micros to read 1024 Bytes from atmega328 EEPROM.

You can thank the major hard drive manufacturers for the source of all the confusion. Until their poxy marketing departments got their grubby little mits on it K always meant 1024 in a computing context. It's only when they started using K=1000, M=1000000 and G=1000000000 etc to make their hard drive capacities look bigger (a 1GB hard drive is actually only 953.7GiB - such a con) that it all went to hell in a hand basket.

Amen.

majenko:
[... snip ...]
You can thank the major hard drive manufacturers for the source of all the confusion. Until their poxy marketing departments got their grubby little mits on it K always meant 1024 in a computing context. It's only when they started using K=1000, M=1000000 and G=1000000000 etc to make their hard drive capacities look bigger (a 1GB hard drive is actually only 953.7GiB - such a con) that it all went to hell in a hand basket.

Well, that and the computing context actually broke SI standards, so a new standard was drafted all the way back in 1999 by IEC. 14 years on and it still has never really caught on. (Isn't there a joke here somewhere about the trouble with standards is there are too many of them?)