[TUT] [C] Using the EEPROM memory in AVR-GCC

Go To Last Post
353 posts / 0 new

Pages

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

I thought this forum was a place to ask questions and to learn

 Did you miss the sticky on top of the forum http://www.avrfreaks.net/forum/p...

particularly the bits in Red. wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

yes it is a place to ask questions,

yes it is a place were you can learn,

 

but no it is not a place were we will write all the code the requester needs.

The problem is that in the end 99% of the requests for code are school projects that had to be finished a week ago, but that the lazy student thought we would be writing for them.

 

You say you have written code to test what you want to do.

Post this code and people will have a look and tell you what things you have done wrong.

 

There should be a lot of questions on eeprom usage with code already present. SO I think it is strange that you did not find what you were looking for.

as a suggestion, I would not update your EEProm every second, but only keep the minutes and longer in memory. first as writing to it will take time and second the eeprom does have limited writing cycles. And althoug they are much, I do not see you writing an algorithm that uses more then 1 storgae location for keeping time and thus wearing out the eeprom less fast.

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

I spent a couple weeks on this part of the program before I went to AVR freaks , I understand where you are coming from people take advantage of you help sometimes.

I got the issue resolve from help here. The program writes to 2 memory locations only and I will monitor the life span before it leaves my hands.

 

It only saves to eeprom on request by user to save data, not in a loop or cycle so that should help .

 

Thanks for your reply .

 

 

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

I did miss that big red sticky at the top . I will pay more attention to forum usage in the future .

 

 

Thanks

 

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

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.

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

Thank you for pointing that out , I will use update to make it live longer .

 

 

 

Thankful that this forum is here.

 

 

 

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

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

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

Volatile or non-volatile? 

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

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

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

Then why in the name of all that is holy have you posted on the end of this tutorial? 

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

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

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

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

Surely you are making fun of us?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

you could have posted the link instead..!!

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

You do realise that in C if you write

int x;
x = 12345;

then that is stored in volatile memory?

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

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 

of all the things i've lost - i miss my mind the most.

Last Edited: Thu. Aug 13, 2015 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Didn't find this anywhere else. Not even in the Atmel Docs

Isn't this the stuff one learns at computer kindergarten? wink It's only 2 bytes if the address range is 0x0000 to 0xFFFF, if you have a larger memory then it would be 3 bytes or 4 (or bigger??).

 

If you had a very small micro with only 256 bytes of memory then it would be 1 byte only.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Dean,

 

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

 

 

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

mfeinstein wrote:

Dean,

 

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

 

 

 

please go to deans website and download the PDf he created called "Using the EEPROM in avr-gcc" that is a good refence document and holds all the information you will need.

 

regards

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

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).

Last Edited: Tue. Oct 20, 2015 - 06:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson!

 

My code looks just like your example so this makes things easier.

 

I think this should be added to the original tutorial, so it won't be easily missed in the middle of the other (and future) posts.

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

mfeinstein,

 

what does the first line of the first post say?

The tutorials grow over a large amount of time.

My guess is that somewhere in the 7 pages of posts the write to EEPROM stuff is handled.

Dean has taken the time to create a nice pdf file that you can download and keep at hand at all times.

I know he updated it already a couple of times, so when you see a tutorial and it states "look at the pdf for latest version" I would suggest you first ahev a look at that.It will most likely contain a lot if not all the info gathered from all the replies to the original post.

 

have fun

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

meslomp,

 

Thanks for your reply. I don't think I made myself clear, so let me be more specific....

 

.... after I read the entire original post and after I read the entire PDF tutorial on Dean's website and after I searched for write and update examples in the 7 pages and found a lot of examples but with different sintaxes, I think a write and update examples should be added to the tutorial so to cover all the usages of EEMEM.

 

I always try to read all the recommendations and links on posts before posting to avoid situations like this.

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

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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Ok, I thought the PDF was the "official" release, but here was updated as well since this is the official AVR forum and tends to be the first search results...my fault on this one.

 

Now, on the PDF...I can see there are write and update sections, no problems there I have used EEPROM before, so I know how it works, but on the EEMEM examples there isn't a write or update example using EEMEM.

I have never used EEMEM before, I just relied on countless "#define ABC_ADDRESS 1", and of course I hate it, so learning this new thing is really nice. I think it's supposed to be:

 

eeprom_update_byte(&myEEMEMvariable, myValue);

 

And of course this is easy to test, but I just wanted to suggest that adding this examples in the tutorial, wherever it lives, will be handy, specially for beginners, since pointers usually makes them confused.

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

mfeinstein wrote:
but on the EEMEM examples there isn't a write or update example using EEMEM

 

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.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Yep, and that's exactly what I did hahaha, again, it was just a recommendation to make things more clear....the whole tutorial covers read, write and update, so I thought for the sake of completeness the EEMEM part should reflect this as well. 

 

Some stuff appear obvious for us with years of C programming experience, but I can see some beginners struggling for simple stuff like this.

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

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

 

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

hahaha I agree, but not on introductory tutorials....

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

Anyways it was just a suggestion for "others", if you think it's too much, it's fine, never mind.

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

 

 

but the warning said

#include <avr/eeprom.h>
#include ....

uint16 Alamat, Data=123; 
  int main()
  {
      //button initialize and pullup;
      ...
   while(;;)
   {
       Data++;
       _delay_ms(200);
       if (ButtonPress())
       {
           uint16 i;
          
           i=0;
           for (i=0; i<100; i++)
           {
               eeprom_write_word((uint16_t*)i, Data);  // I make i as a autocount up address
               _delay_ms(50);
           }
       }
   }
  }

Warning 1 cast to pointer from integer of different size [-Wint-to-pointer-cast] D:\HARDWORK\MYLEARN\CHECKER Ver2.0(Program Tester)\Tes_Motor\Tes\Tes_Motor.c 142 24 Tes_Motor

How did it happened? 

I like logic and such a programming :)

Last Edited: Fri. Nov 27, 2015 - 06:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Apologies if this is covered somewhere in the previous 7 pages or so, but I was wondering why the address pointer parameter for eeprom_read_byte also has to be sizeof(byte)? If you want to write an 8 bit value to an eeprom location beyond 0xff, how is this meant to be accomplished?

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

anthony_k wrote:
why the address pointer parameter for eeprom_read_byte also has to be sizeof(byte)?

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)?

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

OK that makes sense, thanks. I was misreading an error message in studio.

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

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...

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

If you read back through the 7 pages I seem to remember someone already pointed this out. I also believe that Dean has up to date PDFs that correct the error.

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

abcminiuser wrote:

You can initialize the EEPROM array just like a normal C array:

uint8_t EEArray[5] EEMEM = {1, 2, 3, 4, 5};

- Dean :twisted:

 

I don't understand the purpose of storing the EEPROM variable addresses in EEPROM. Why do we bother programming the EEPROM file to our microcontroller separately? For example, if I need to store only 2 bytes in EEPROM for my CRC Value, can't I just initialize the address in a variable defined in SRAM and  get rid of programming the EEPROM file? 

I can get this work but I would like to know if I am doing something wrong:

 

int EEPROM_CRC  = 0x10;   //Address for the CRC Value to be stored in
.
.
.
int main()
{
	eeprom_write_word((uint16_t*)EEPROM_CRC,CRC16_Received);
	.
	.
	.
	
	
}

And thanks for such a good tutorial :)

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

You can do it like that if you like. But just as you don't normally do this in RAM:

int * AddrMyInt = 0x147;

int main(void) {
    *AddrMyInt = 12345;
}

In which YOU pick some random address in RAM to hold an int you wouldn't usually do it in EEPROM either.

 

Sure, if there's nothing else ever going to be stored in the EEPROM I guess you can pick some random address to use. But often MCU programs use EEPROM extensively (that's why it's there after all!) and in this case you want the linker to pick locations for your variables rather than trying to ensure that some manual layout you come up with yourself doesn't have locations that crash.

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

clawson wrote:

You can do it like that if you like. But just as you don't normally do this in RAM:

int * AddrMyInt = 0x147;

int main(void) {
    *AddrMyInt = 12345;
}

In which YOU pick some random address in RAM to hold an int you wouldn't usually do it in EEPROM either.

 

Sure, if there's nothing else ever going to be stored in the EEPROM I guess you can pick some random address to use. But often MCU programs use EEPROM extensively (that's why it's there after all!) and in this case you want the linker to pick locations for your variables rather than trying to ensure that some manual layout you come up with yourself doesn't have locations that crash.

 

Yes, the "0x10" value will not be stored in EEPROM, it will be stored in a random address of RAM. But do we need to care about the location of "0x10" ? I will just use that 'value' to call the "eeprom_write_word" with. Then the 'CRC16_Received' will be stored in the EEPROM and I will only want the value 'CRC16_Received' to be stored in RAM. Then I can just read the 'CRC16_Received' from the address 0x10 of EEPROM. Is this wrong?

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

abdullahcinar wrote:
Yes, the "0x10" value will not be stored in EEPROM, it will be stored in a random address of RAM. But do we need to care about the location of "0x10" ?

Not the point I was making. 0x10, the random value you just plucked out of the air is the random value I was talking about. For example suppose you did this:

int EEPROM_CRC  = 0x10;   //Address for the CRC Value to be stored in
struct {
    int n;
    long l;
    char txt[12];
    float f;
} struct_inEE EEMEM;
.
.
.
int main()
{
    eeprom_write_word((uint16_t*)EEPROM_CRC,CRC16_Received);

That struct is 20 bytes long. The linker almost certainly places it at 0x0000 in EEPROM so it will span 0x0000..0x0013. When you do:

    eeprom_write_word((uint16_t*)EEPROM_CRC,CRC16_Received);

you actually write on top of that struct because the 0x10 you randomly picked just happens to be "on top" of the location of that struct. This is what happens when both you and the linker begin to pick addresses in the same address space and is why it is usually better to let the linker place objects in a memory space such as RAM or EEPROM.

 

If you do want to pick a fixed location then pick one that is towards the end of the EEPROM so it is out of range of the area the linker is likely to be using. Thus if there is 2K of eeprom position your CRC at 0x7FE not 0x10.

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

clawson wrote:

abdullahcinar wrote:
Yes, the "0x10" value will not be stored in EEPROM, it will be stored in a random address of RAM. But do we need to care about the location of "0x10" ?

Not the point I was making. 0x10, the random value you just plucked out of the air is the random value I was talking about. For example suppose you did this:

int EEPROM_CRC  = 0x10;   //Address for the CRC Value to be stored in
struct {
    int n;
    long l;
    char txt[12];
    float f;
} struct_inEE EEMEM;
.
.
.
int main()
{
    eeprom_write_word((uint16_t*)EEPROM_CRC,CRC16_Received);

That struct is 20 bytes long. The linker almost certainly places it at 0x0000 in EEPROM so it will span 0x0000..0x0013. When you do:

    eeprom_write_word((uint16_t*)EEPROM_CRC,CRC16_Received);

you actually write on top of that struct because the 0x10 you randomly picked just happens to be "on top" of the location of that struct. This is what happens when both you and the linker begin to pick addresses in the same address space and is why it is usually better to let the linker place objects in a memory space such as RAM or EEPROM.

 

If you do want to pick a fixed location then pick one that is towards the end of the EEPROM so it is out of range of the area the linker is likely to be using. Thus if there is 2K of eeprom position your CRC at 0x7FE not 0x10.

 

I got the point now, thanks! Actually, I'm ok with fixed addressing but I didn't want to program the EEPROM separately for my each micro. Despite I am not using any other places in EEPROM, it is better to know the address where it will be stored. Then in the production case, I can consider packaging my whole  memory(APP+BOOT+EEPROM) to one file and program that file to my devices. Is there any option to attach the Fuse settings to that file too? Will I need to configure the fuse settings for my each device from the Device Programming Settings?

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

abdullahcinar wrote:
Is there any option to attach the Fuse settings to that file too?
"ELF production files". (but this is now going off-topic for this tutorial thread).

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

clawson wrote:

abdullahcinar wrote:
Is there any option to attach the Fuse settings to that file too?
"ELF production files". (but this is now going off-topic for this tutorial thread).

 

Thanks Cliff!

 

I was just wondering the keyword, now I can do my search for this :)

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

Hello,

Does eeprom.h read/write functions take care of eeprom_ready()?

or I will have to check first if eeprom is ready then do read write operation.

Also should i disable global interrupts before reading or writing manually.

 

 

Thanks in advance

Satish Rathod

Pune

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

Takes care of it.

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

I was wondering why read_byte and read_word use a different sized adress. 

uint8_t eeprom_read_byte (const uint8_t *__p)

uint16_t eeprom_read_word (const uint16_t *__p)

 

Which would mean you can't access bytes in EEPROM adresses > 256, right?

 

eeprom_read_byte((uint8_t*)500);

Would cast 500 to uint8_t, or am I not understanding pointers correctly here

 

 

Last Edited: Wed. Nov 16, 2016 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

remkooo wrote:
or am I not understanding pointers correctly here
So that!

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

clawson wrote:

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.

remkooo wrote:
or am I not understanding pointers correctly here
So that!

 

Thanks a lot, that has made it clear for me.

I'll go brush up on C pointers now :)

 

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

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??

...

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

sasan.riahi wrote:

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??

I love posts that start "I have heard". Can you post a link to a web page or cite a document where you have "heard" this. It is utter nonsense. The EEPROM mechanism has a "busy bit" that says when it is active and the driving software uses this to know when it's OK to perform an action. So, no, you don't need delays.

 

By the way, if you are curious, the source of EEPROM support in GCC is here:

 

http://svn.savannah.gnu.org/view...

 

The ee*.S files contain the code that you use to access EEPROM. If you look at something like eewr_byte.S:

 

http://svn.savannah.gnu.org/view...

 

then look at line 143/144.

143 	1:      sbic    _SFR_IO_ADDR (EECR), EEWE
144 	        rjmp    1b

That will hold in a loop there while the EEWE bit in EECR is set. That ensures the EEPROM is "ready" when it falls into the next bit. If a previous write is still in progress it will wait while that bit remains set.

 

BTW in this file:

 

http://svn.savannah.gnu.org/view...

 

62 	# if    !defined (EEWE) && defined (EEPE)       /* A part of Mega and Tiny */
63 	#  define EEWE  EEPE
64 	# endif

some AVRs have "EEPE" rather than EEWE so this defines one as the other.

Pages