Read and Write time in EEPROM in Atmega32.

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

Why in Atmega32 for EEPROM read time is more than write time, while in real for EEPROM the read time is less than the write time ?

 

see the text from Atmega32 below 

 

This topic has a solution.

I am living to bring up new earth ,and not to eat and destroy earth.

Last Edited: Thu. Jan 31, 2019 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When doing a write to eeprom, the address and data is just latched and the actual eeprom write continues in parallel. Whereas for a read, the eeprom has to be read and takes longer. This should have been obvious if you read the whole datasheet section rather than highlighting one paragraph.

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

Could you mention where it is explained in datasheet of atmeg32?

 

I am living to bring up new earth ,and not to eat and destroy earth.

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

Its right in front of your eyes! It tells you the write is self timed and the software can determine when the write is complete.

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

In paragraph below it explains the write only that is self-timing function (note i don't what it means this term) and the read where it is explained ??

 

I am living to bring up new earth ,and not to eat and destroy earth.

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

Mohamed asaad wrote:

In paragraph below it explains the write only that is self-timing function (note i don't what it means this term) and the read where it is explained ??

 

Think about it a little.

 

When your code writes to the EEPROM the important point in time is when you issue the command to write. It does not matter when the actual write happens. All that matters is that you check that the write has happened the next time you want to write. So the actual writing of the data can happen while the processor continues to run and execute code that is after the actual write command. Self-timing means that the EEPROM does not rely on code to do the actual writing of the data; it deals with all the timing itself.

 

When your code reads from the EEPROM then the actual read must happen and complete before your code can continue because that data is needed by your code. SO the processor must wait at that point for the read to occur.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

So you mean that in mentioned paragraph above it means about the halt is done by code (that write need instructions takes two cycle and read need an instructions takes four cycles)

I am living to bring up new earth ,and not to eat and destroy earth.

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

Does the halt is counted after this instruction sbi in writing? 

 

and in reading after this instruction sbi also ?

 

 

Could you tell me if i think right or wrong?

I am living to bring up new earth ,and not to eat and destroy earth.

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

Mohamed asaad wrote:

So you mean that in mentioned paragraph above it means about the halt is done by code (that write need instructions takes two cycle and read need an instructions takes four cycles)

 

No, the halt is done by the processor between lines of code.

 

From the datasheet...

 

Quote:

EEPROM_read:
; Wait for completion of previous write
sbic EECR,EEWE
rjmp EEPROM_read
; Set up address (r18:r17) in address register
out EEARH, r18
out EEARL, r17
; Start eeprom read by writing EERE
sbi EECR,EERE

***the processor will halt here so that the data is ready for the next instruction***
; Read data from data register
in r16,EEDR

...

 

 

You should be able to test all these things for yourself by running test code on a real processor and timing the results. The datasheet tells us a lot but not everything because we do not need to know. All we need to know is that if we follow the instructions in the datasheet 

then our code will work.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Thu. Jan 31, 2019 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More importantly, under The EEPROM Control Register – EECR:

 

 

So the 'cpu halted for 2 clock' cycles pales in comparison to the 8.5 ms it takes for the write to actually occur and for EEWE to self-clear before the next write (or read, for that matter), can proceed.

 

Note that the above table is two pages later in the datasheet from the paragraph you pasted into your OP, and that it is even referenced at the top of that very paste!:

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Jan 31, 2019 - 06:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But also that doesn't explain why the CPU is halted more time in reading , Because what i knew that writing in any EEPROM take more time than reading.

 

I am living to bring up new earth ,and not to eat and destroy earth.

Last Edited: Thu. Jan 31, 2019 - 09:07 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Because what i knew that writing in any EEPROM take more time than reading

Yes, your memory is correct (and that makes it easy to jump to conclusions).  Now, if you wanted to write a bunch of bytes, the program would be much slower than reading a bunch of bytes (since, as you remembered, the actual writing is verrrrrry sloooow [compared to reading]).  When you only have 1 byte to write, the program can toss it to the EEPROM & let it worry about the slowness...the program can simply march ahead without delay.

 

The two halt cycles mentioned for a write, don't mean the write is finished...it take 2 cycles to toss the data to the EEPROM & get the write prepped/underway. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Jan 31, 2019 - 09:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The best explanation thanks  avrcandies  smiley

I am living to bring up new earth ,and not to eat and destroy earth.

Last Edited: Fri. Feb 1, 2019 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lesson:  cpu-halt-cycles != eeprom-write-time

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

If the next question is 'what does it do in those two or four cycles' - we don't know as Atmel don't tell us. As such, we don't need to know in order to use the chip.

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

Mohamed asaad wrote:

But also that doesn't explain why the CPU is halted more time in reading , Because what i knew that writing in any EEPROM take more time than reading.

 

Did you read what I wrote in #6?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

No, i was wondering why it is opposite what i have studied , but it becomes clear by avrcandies.  

I am living to bring up new earth ,and not to eat and destroy earth.

Last Edited: Fri. Feb 1, 2019 - 06:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ya ,I think it is the same explanation thank you

I am living to bring up new earth ,and not to eat and destroy earth.