eeprom READ speed

Looking for a number, surpised I couldn't find it. I was going to usethe eeprom to store a handfull of scaling values for a pulse I need to generate, but since tehy will be read in an interrupt, I want ot keep things as fast and safe as possible. with the write time being quite large, I worry that the read time is equally slow. I am looking at the eeprom library to understand it better, and the data sheet to see where the time delay is inherently coming from, but if anyone has a solid number for how fast a single byte can be read from EEPROM, I would appreciate it.

Why not read the data outside of the ISR. Then, the speed doesn't matter.

Looks like at least four instruction cycles: Two to load the address registers, one to initiate the read, and one to read the data register.

EEPROM_read:
  ; Wait for completion of previous write
sbic EECR,EEPE  // Skip next instruction if the busy flag is clear
rjmp EEPROM_read

; Set up address (r18:r17) in address registers
out EEARH, r18
out EEARL, r17

sbi EECR,EERE  ; Start eeprom read by writing EERE
in r16,EEDR  ; Read data from Data Register
ret

Just copy the data to SRAM and use it from there.

Agree iwth JOhn wasser, make a working copy of the data stored in the EEPROM in a local variable and work with that,

Furthermore:
A write to eeprom is much more costly then a read, someone proposed to (re) implement write as follows

void myEEwrite(int address, byte val)
{
  if (EEPRO.read(address) == val) return;  // if the value already exist, no need to write.
  EEPROM.write(address.value);
}

this will works especially well if the val does not change much. e.g. writing configuration data. might help you in some future

first off, yes it looks like a read is extreemly fast and nothing to worry about. the fact the CPU is halted for 4 cycles has no effect on timers correct? the halt comes from 4 no-action executions or something, not by ignoring the clock for 4 pulses, possibly creating error in timing elsewhere (I have timers toggling pins purely in hardware, they will see no negative effects during this read, and even if they did 4 pulses at clock freq is pretty non-consequintial i think (250 nS))

My specific aplication is I need to control the revolution of a stepper motor preciesly. Its speed must vary throught 1 revolution, always in sync with its actual position with no feedback. I also need to vary the net rotational speed, so I am scaling each individual pulse timing by a scaler stored in eeprom by having an ISR scale my desired input by the value stored in EEPROM, insert it into the OCR and then kicking back into the program. with microstepping I therfore need to store a big pile of scalers as the speed mapping is emperically calculated and not easily compressed into a more practical size, although I am working on optomizing it.

If anyone has ideas of a better way of doing this, I would love to hear it and may just try implementing it. It looks like EEPROM will read plenty fast enough for what I need, but it leaves me with no real storage space left untill I come up with a working optomization bit, which I suspect I am close to but I have other thigns to do, so once this starts working satisfactorily it will be a bit backburner.

thanks guys and gals!

oh and if it was unclear, the EEPROM data NEVER changes, any tweaks to values will happen outside of runtime, and likely with a dedicated sketch just for tuning to avoid "wearing down" the eeprom. During actual use the scalers are constants

If it NEVER changes at run time, why do you need EEPROM? What’s wrong with constants if your code? Have you tried storing the constants in program memory with the PROGMEM functions?

Or just using plain constants in your code. EEPROM isn’t the best tool for this.

the fact the CPU is halted for 4 cycles has no effect on timers correct?

The CPU isn't halted. It's running flat out. It just has stuff to do that takes 4 clock cycles. No, no affect on timers.

after the explination and reading a little more nitty gritty, I understand the 4 cycle halt is as you say paul, the confusing part is in the data sheet they refere to the halt as "When the EEPROM is read, the CPU is halted for four clock cycles before the next instruction is
executed." and fail to elaborate. I am no longer confused but dang thats a bad paragraph.

now as to why I am using eeprom instead of progmem or whatnot, is because we are talking about 1kByte of data, give or take 50%. I could optomize it, but I remember now the reason I didn't start out with "effecient" code is the fear of doing math inside the ISR, I am leary of using them to begin with, so the less that happens inside of it, the better I would feel. while I could pull the math out of it (maybe) then I would fear a race condition, not knowing what is getting evaluated when etc etc. if it is just reading eeprom and advanceing one location till it wraps, then I know exactly what it is doing at all times.

I am bad at microcontrollers, so sometimes I need to force myself to stick to the clearest way of doing things rather than the best.

I am no longer confused but dang thats a bad paragraph.

Yes, it is.

PaulS:

the fact the CPU is halted for 4 cycles has no effect on timers correct?

The CPU isn't halted. It's running flat out. It just has stuff to do that takes 4 clock cycles. No, no affect on timers.

The datasheet explicitly states that "the CPU is halted for four cycles before the
next instruction is executed."
The EEPROM is a separate part of the chip to the CPU and the delay is latency in the
EEPROM block itself plus interconnect delays I expect. There's little reason to optimize
EEPROM read access when writes take several milliseconds per byte...

And no the system clock isn't halted, otherwise how could those 4 cycles be counted!

There's no reason to be afraid of doing math inside the ISR. Just make sure any global variables that the ISR modifies are declared as volatile.

joshuabardwell:
There’s no reason to be afraid of doing math inside the ISR. Just make sure any global variables that the ISR modifies are declared as volatile.

Agree with the volatile remark.
And if you are read 32 bit var’s from the core (like timer0_millis) than you need to disable interrupts too.

Doing math really depends on the number of ISR’s per second and the amount of math.
1 ISR per second allows for a lot of math while 1 ISR per 25uSec (e.g 38Khz IR) allows for substantially less.