AVR Freaks

Make sure to use eeprom_update*() routines not eeprom_write() routines then it doesn't matter so much if you inadvertently keep writing the same data as nothing is changed by "update" if what is being written is already there. "write" on the other hand will just erase/write regardless. On the whole there is no longer any reason to use eeprom_write*() routines at all.

I want to write some arbitrary data into atmega32 and read from that location..Which memory of the chip should i use and What are the instructions to do so..The data comes from another device through serial communication.

Thanks

The data comes from a meter continuously..SO it has to be overwritten everytime a new data comes..So the data can be volatile.

Thank you

Is there any tutorial to write into the ram and read from it?

you could have posted the link instead..!!

Thank you so much for the Information that a Pointer is a 2Byte

I got really confused by that. How should I address the Bytes 256+?? 

But that makes it easy - just add 1 to the pointer and it will increase the address by, as defined, one Byte :)

Didn't find this anywhere else. Not even in the Atmel Docs... At least not as fast as I found your Post :)

Maybe you should state that somewhere in big letters :D

Cheers 

ToM 

Great tutorial, but I miss a quick example on how to use EEMEM with write or update functions, there are only read examples.

#include <avr/eeprom.h>

int eevar EEMEM = 12345;

int main(void) {
    int ramvar;

    ramvar = eeprom_read_word(&eevar); // corrected spelling here
    eeprom_update_word(&eevar, 5432);
    ramvar = eeprom_read_word(&eevar);
}

When built this program will create a projectname.eep file. If you program it into the eeprom then run this program then on the first read "ramvar" will be 12345. But shortly after this it is changed to 5432 so on the next read it will be 5432. If you now power off and power back on then the first read will now read 5432 and when it does "update" nothing will change. So from now on all reads will read 5432 and the EEPROM will never be written to again (which is the reason to use update and not write - no point needlessly writing to the EEPROM when it's not needed).

The official home of the tutorial is the PDF on Deans web-site. It has examples of write and update.

The tutorial here in the Tutorials forum will not be updated any more. (Dean has chosen to use TeX to maintain the tutorial and produce the PDF from that, and will not do the double-work of also maintaining the text in the tutorial here.)

This is what Dean is trying to tell you by his edited-in comment at the beginning of the tutorial here in the Tutorials forum. It says

For an updated version of this tutorial in PDF format, please see this page of my website.

Do you understand now?

Looking into the PDF there is

• A section 2.2 "The update vs. write functions" which discusses the introduction of the (not so) new update functions
• A complete chapter 4 "Writing data to the EEPROM". While short, it is to the point. And it uses the new(ish) update functions, as discussed in section

What, specifically, are you missing in that PDF?

Again: If you're asking for an update of the text here then just accept that it won't happen.

Finally: Any Google result risk bringing up old and new stuff in no particular order. In no way specific to the question at hand you will always have to assess what information dug out of 20 years of human activity on the Web still holds, and what might be outdated. That's just how it is with the Web - a lot of old abandoned and no longer maintained material is floating around out there.

If the different syntax you encountered is the write functions v/s the update functions then Deans section 2.2 is a "strong hint" that it is the latter that should be used.

You know from the early chapters in the PDF how to read/write/update to fixed literal locations in the eeprom. The EEMEM chapter simply introduces a way of letting the compiler allocate a variable at some address in eeprom.

Now look at how the read changes from using a fixed address to using an EEMEM variable. Apply the corresponding change to any write/update use.

Mylord! I bring before this court exhibit "A", the second proverb in my sig/footer! And with that I rest my case. :-)

How can we possibly tell, since you have given no clue as to the type uint16, the type of the variable i that you then cast to a pointer to a uint16_t.

My guess is that the code above is not exactly what generated the error message. I suspect that where the code above has uint16 your actual code has uint16_t.

Posting code other than the actual code you have is meaningless, sends us out on a wild goose chasse, and is a waste of time. Keep it up and we will get tired of wasting time and you will be abandoned.

Always post real code. Always reduce it to the smallest possible that demonstrates the problem.

The quality of the answers you get is a mirror of the quality of the question you ask.

It does not. It has to be sizeof(uint8_t *) , which is something else.

Where did you find a statement that it has to be sizeof(byte)?

Small remark, but I believe it should be

 void eeprom_write_block (const void *pointer_ram, void *pointer_eeprom, size_t n)

instead of

 void eeprom_write_block (void *pointer_eeprom, const void *pointer_ram, size_t n)

http://www.nongnu.org/avr-libc/u...

Takes care of it.

You need to learn some C. Those parameter definitions say the size of the OBJECT POINTED TO not the size of the pointer itself.

In AVR all pointers are 16bit.

"uint8_t *" is a 16 bit pointer to 8 bit data.

"uin16_t *" is a 16 bit pointer to 16 bit data.

If I had:

typedef struct {
    char c;
    int n;
    long l;
    char dat[5];
} foot_t

foo_t * pFoo;

then pFoo would be a 16 bit pointer to 12 byte (96 bit) data.

I have heard that  a short delay function is needed when we are reading or writing eeprom and the reason is being sure that the reading or writing in eeprom memory is finished!

Is that right? and if yes, how long should it be??