Go Down

Topic: EEPROM Library - Block Read / Write (Read 3005 times) previous topic - next topic

Hi all,

I notice that the EEPROM library for arduino is missing the standard:

void eeprom_read_block (void *pointer_ram, const void *pointer_eeprom, size_t n) / write equivelant (taken from the GCC AVR libraries)

And I've checked the source for the arduino EEPROM library, and it only wraps the eeprom_write_byte / read functions...

Surely this is a bad thing? Encouraging people to store what might be large amounts of data one byte at a time will wear out the EEPROM rather fast won't it?

Just wanted to ask if there was a reason why this was missed out, as I don't think it'd be too frightening to people not used to programming to have this feature, and it'll possibly save someones arduino at some point.

pYro_65

I think the write cycle count applies to individual cells, Internally the block commands must iterate the cells some how. Might be faster than implementing a loop with single read/writes, but I don't think it would protect the eeprom any better.


Coding Badly

Quote
Encouraging people to store what might be large amounts of data one byte at a time will wear out the EEPROM rather fast won't it?


Nope.  The EEPROM on AVR processors is byte-wise.  One byte at a time in.  One byte at a time out.  If a byte wears out the neighbors are not affected.

It would be nice if the standard EEPROM library included this... http://arduino.cc/playground/Code/EEPROMWriteAnything

I see, thanks for the clarification. And I second that the functions Coding Badly linked to should be added to the library, maybe the next version? :)

Nick Gammon


Nope.  The EEPROM on AVR processors is byte-wise.  One byte at a time in.  One byte at a time out.  If a byte wears out the neighbors are not affected.


4 bytes according to page 299 of the datasheet, or have I misunderstood it?
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics


4 bytes according to page 299 of the datasheet, or have I misunderstood it?

Interesting, the page size does seem to be 4 bytes. Possibly this is why AVR GCC has a write / read word function? Might be worth digging into the AVR GCC source, though I have a feeling the EEPROM stuff will be assembly guh.

Nick Gammon


And I've checked the source for the arduino EEPROM library, and it only wraps the eeprom_write_byte / read functions...


The way I read the datasheet the writing to EEPROM is a byte at a time (page 22). Thus making some sort of "block write" would achieve nothing much. However it would appear from the reference to 4 byte pages, that you are only "wearing out" a block of 4 bytes by writing to EEPROM.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Nick Gammon

However through serial programming (ie. ICSP) you could probably write a page at a time, so there is some point to knowing the page size.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Coding Badly

However it would appear from the reference to 4 byte pages, that you are only "wearing out" a block of 4 bytes by writing to EEPROM.


There are a few folks who have published write-to-death testing.  The results are consistently byte-wise failure.

Coding Badly



Nope.  The EEPROM on AVR processors is byte-wise.  One byte at a time in.  One byte at a time out.  If a byte wears out the neighbors are not affected.


4 bytes according to page 299 of the datasheet, or have I misunderstood it?


I assume the 4 byte page is to make external programming more efficient.  At ~3ms a byte, programming a 1K EEPROM takes at least 3 seconds.  Dividing that by anything (even a value as low as four) makes a huge difference in mass production.

Coding Badly

Interesting, the page size does seem to be 4 bytes. Possibly this is why AVR GCC has a write / read word function?


Nope.  The EEPROM can only be accessed one byte at a time from the running program.  (the 8-bit EEDR register is the pipeline)

Quote
Might be worth digging into the AVR GCC source,


It is.

Quote
though I have a feeling the EEPROM stuff will be assembly guh.


It is.

Nick Gammon


There are a few folks who have published write-to-death testing.  The results are consistently byte-wise failure.


Reading between the lines a bit, it appears that the page refers to the fact that you can program a page (ie. 4 bytes) of EEPROM whilst preparing another page for writing (using the ICSP interface).

Quote
I assume the 4 byte page is to make external programming more efficient.


That would appear to be what it is for.

Elsewhere the datasheet says:

Quote
It is organized as a separate data space, in which single bytes can be read and written.


They are vague as to whether the relationship between pages and single bytes is going to affect wear and tear, but by the sound of it, you don't have to worry about it.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

I had a brief look in the source to clarify for myself and it does appear to write one byte at a time. A shame really as I'm storing a programmable IR code in there which is pretty big, I think it may take a little while to write.

Oh well, thanks for the help guys.

One thing I have noticed, is that the arduino library is not using eeprom_update_* for writing to EEPROM memory. Update checks to see whether the memory being written to is different (EEPROM reads are free) before writing to it, it's slightly slower but it will save you from writing data when you don't have to.

I do notice that the version of AVR gcc that arduino comes with (arduino 1.0 at any rate) does not have this function.

FigZ

apparantely somebody else noticed this void (update instead of blindly writing to EEPROM) - and coded a nice library for this

http://playground.arduino.cc/Code/EEPROMex


Go Up