EEPROM read clock cycles

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am planning to use EEPROM for storing a table in ATmega162/V. It is for speed reasons.

On page 22 the handbook says:
"The EEPROM read access takes one instruction, and the requested data is available immediately.
When the EEPROM is read, the CPU is halted for four clock cycles before the next execution is executed."

What does this mean?
-(A)The CPU is stopped 4 clock cycles; the read takes 4 more clock cycles compared to other internal memory reads.
-(B)The read takes 4 clock cycles.
-(C) There is a delay time, like at reading external RAM where puls stretching is used.

If I have to do sequential reads (4 bytes in my case), how many clock cycles will that take per byte?
Does it help to execute a little other command between two reads (to get more time between EEPROM reads).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(A) methinks.
effectively you've stated the same in C - if you used pulse stretching or wait states or delaying a data acknowlege (for 68k fans) the net result is the same - the cpu isn't doing anything else at that point in time apart from chewing cycles.

As to the exact number of cycles, I'd have to read the datasheet or you can set up a loop and time it just to be sure.
Do whatever you want between eeprom reads, but it aint going to buy you anything extra.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not simply test this in the simulator? I wouldn't trust SimV1 but if you pick an AVR modelled in SimV2 you can probably be pretty certain that the sim will get the EEPROM access timing correct.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I found this in "Accessing the EEPROM" appnote AVR100:

EERead:
	sbic	EECR,EEWE	;if EEWE not clear
	rjmp	EERead		;    wait more

	out 	EEARH,EEardh	;output address high byte, remove if no high byte exists
	out	EEARL,EEard	;output address low byte


	sbi	EECR,EERE	;set EEPROM Read strobe
				;This instruction takes 4 clock cycles since
				;it halts the CPU for two clock cycles
	in	EEdrd,EEDR	;get data
	ret

sbi would normally take 2 cycles, thats what the Instruction Set book says, but with EECR,EERE it will be extended to 4 cycles...?

Note (added):
The shown code from AVR100 says "it halts de CPU for 2 cycles".
I think AVR100 is "old" and run on AT90S8515. In the 8515 documentation they say that when EERE has been set the CPU is halted for 2 cycles.
Including the sbi EECR,EERE it is 4 cycles as stated in de comment.
For the ATmega162/V it would be 2+4= 6 cycles.
AT90S8515 runs on 4Mhz (takes 2 halt cycles), and ATmega162/V runs on 8 Mhz (takes 4 halt cycles).

So I conclude that the CPU ATmega162/V is truly halted 4 cycles, like 4 nop's are inserted.

Last Edited: Tue. Jun 15, 2010 - 11:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm curious about the seeming importance of a couple of cycles. "eeread()" is normally a subroutine anyway. Passed parameters, handling return value, call & ret--not cheap sequences. A real routine will save SREG, CLI, and restore SREG. The check loop can run for several milliseconds.

Is this some kind of streaming app?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
I'm curious about the seeming importance of a couple of cycles....
Is this some kind of streaming app?

No I try to figure out how fast a fast-division routine could be made.
When putting the table in EEPROM I seem to loose 2 CPU cycles for every 4 Mhz of CPU speed. At 20 mHz that takes probably half the time of the total division routine...
So I think by now it is far better to have the table in flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So I think by now it is far better to have the table in flash.

Exactly - surely you have other flash data (text strings?) that you could swap into EEPROM as they don't need "fast" access?