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.
Posted by chrislundberg: Wed. Mar 11, 2015 - 09:18 AM(Reply to #303)
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 .
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.
Didn't find this anywhere else. Not even in the Atmel Docs
Isn't this the stuff one learns at computer kindergarten? 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.
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.
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).
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.
Posted by mfeinstein: Wed. Oct 21, 2015 - 06:33 PM
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.
Posted by JohanEkdahl: Wed. Oct 21, 2015 - 07:08 PM
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
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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
Posted by mfeinstein: Wed. Oct 21, 2015 - 07:34 PM(Reply to #324)
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_ADDRESS1", 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.
Posted by JohanEkdahl: Wed. Oct 21, 2015 - 07:53 PM
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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
Posted by mfeinstein: Wed. Oct 21, 2015 - 07:59 PM(Reply to #326)
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.
Posted by JohanEkdahl: Wed. Oct 21, 2015 - 08:09 PM
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. :-)
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
#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
Posted by JohanEkdahl: Fri. Nov 27, 2015 - 07:48 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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
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?
Posted by JohanEkdahl: Sun. Feb 28, 2016 - 09:24 AM
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)?
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
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.
Posted by abdullahcinar: Mon. May 23, 2016 - 04:26 PM(Reply to #75)
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);
.
.
.
}
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.
Posted by abdullahcinar: Tue. May 24, 2016 - 06:42 AM
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?
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:
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.
Posted by abdullahcinar: Tue. May 24, 2016 - 09:36 AM
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:
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?
Posted by sasan.riahi: Wed. Oct 18, 2017 - 06:41 AM
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??
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:
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.
Did you miss the sticky on top of the forum https://www.avrfreaks.net/forum/p...
particularly the bits in Red.
John Samperi
Ampertronics Pty. Ltd.
https://www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
Topyes 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.
- Log in or register to post comments
TopI 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 .
- Log in or register to post comments
TopI did miss that big red sticky at the top . I will pay more attention to forum usage in the future .
Thanks
- Log in or register to post comments
TopMake 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.
- Log in or register to post comments
TopThank you for pointing that out , I will use update to make it live longer .
Thankful that this forum is here.
- Log in or register to post comments
TopI 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
- Log in or register to post comments
TopVolatile or non-volatile?
- Log in or register to post comments
TopThe 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
- Log in or register to post comments
TopThen why in the name of all that is holy have you posted on the end of this tutorial?
- Log in or register to post comments
TopIs there any tutorial to write into the ram and read from it?
- Log in or register to post comments
TopSurely you are making fun of us?
John Samperi
Ampertronics Pty. Ltd.
https://www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
Topyou could have posted the link instead..!!
- Log in or register to post comments
TopYou do realise that in C if you write
int x;
x = 12345;
then that is stored in volatile memory?
- Log in or register to post comments
TopThank 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.
- Log in or register to post comments
TopIsn't this the stuff one learns at computer kindergarten?
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.
https://www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopDean,
Great tutorial, but I miss a quick example on how to use EEMEM with write or update functions, there are only read examples.
- Log in or register to post comments
Topplease 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
- Log in or register to post comments
TopWhen 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).
- Log in or register to post comments
TopThanks 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.
- Log in or register to post comments
Topmfeinstein,
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
- Log in or register to post comments
Topmeslomp,
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.
- Log in or register to post comments
TopThe 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
Do you understand now?
Looking into the PDF there is
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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
- Log in or register to post comments
TopOk, 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:
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.
- Log in or register to post comments
TopYou 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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
- Log in or register to post comments
TopYep, 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.
- Log in or register to post comments
TopMylord! I bring before this court exhibit "A", the second proverb in my sig/footer! And with that I rest my case. :-)
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
- Log in or register to post comments
Tophahaha I agree, but not on introductory tutorials....
- Log in or register to post comments
TopAnyways it was just a suggestion for "others", if you think it's too much, it's fine, never mind.
- Log in or register to post comments
Topbut the warning said
How did it happened?
I like logic and such a programming :)
- Log in or register to post comments
TopHow 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.
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
- Log in or register to post comments
TopApologies 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?
- Log in or register to post comments
TopIt 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)?
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"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]
- Log in or register to post comments
TopOK that makes sense, thanks. I was misreading an error message in studio.
- Log in or register to post comments
TopSmall remark, but I believe it should be
instead of
http://www.nongnu.org/avr-libc/u...
- Log in or register to post comments
TopIf 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.
- Log in or register to post comments
TopI 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:
And thanks for such a good tutorial :)
- Log in or register to post comments
TopYou can do it like that if you like. But just as you don't normally do this in RAM:
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.
- Log in or register to post comments
TopYes, 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?
- Log in or register to post comments
TopNot 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:
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:
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.
- Log in or register to post comments
TopI 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?
- Log in or register to post comments
Top- Log in or register to post comments
TopThanks Cliff!
I was just wondering the keyword, now I can do my search for this :)
- Log in or register to post comments
TopHello,
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
- Log in or register to post comments
TopTakes care of it.
- Log in or register to post comments
TopI 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
- Log in or register to post comments
TopYou 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:
then pFoo would be a 16 bit pointer to 12 byte (96 bit) data.
- Log in or register to post comments
TopThanks a lot, that has made it clear for me.
I'll go brush up on C pointers now :)
- Log in or register to post comments
TopI 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??
...
- Log in or register to post comments
TopBy 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.
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...
some AVRs have "EEPE" rather than EEWE so this defines one as the other.
- Log in or register to post comments
TopPages