|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
|
|
including default eeprom values in flash memoryHi, I am using winavr, and would like to include the default eeprom
values (normally output to .eep) in flash memory. I want to do this so that my application can easily default the eeprom. Whats the best way to do this? can it be done with a modification to the linker script? or should it be done in the makefile somehow? Regards, Michael. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
RE: including default eeprom values in flash memoryHi,
One method, which I have read on the net & also used by myself in my project is as follows. As per this we have to write the default eeprom values in our 'C' file. 1. Create one variable named eeload. 2. In your main program, if eeload !=250 (any random value) then put all your default values in EEprom. 3. And also load eeload = 250. 4. Because of this, next time eeload will be 250 & default values will not be reloaded. 5. Hence after you load your main hex file, at first instant all the default eeprom values will get loaded alongwith eeload=250. 6. This part of code will never get executed in future because eeload = 250. Hope this will help you. Good Luck Prashant India -----Original Message----- From: avr-gcc-list-bounces+pdkharade=adorpower.com@... [mailto:avr-gcc-list-bounces+pdkharade=adorpower.com@...] On Behalf Of Michael Clift Sent: 21 October 2009 15:04 To: avr-gcc-list@... Subject: [avr-gcc-list] including default eeprom values in flash memory Hi, I am using winavr, and would like to include the default eeprom values (normally output to .eep) in flash memory. I want to do this so that my application can easily default the eeprom. Whats the best way to do this? can it be done with a modification to the linker script? or should it be done in the makefile somehow? Regards, Michael. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.24/2449 - Release Date: 10/20/09 18:42:00 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
|
|
|
|
Re: including default eeprom values in flash memory
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memoryMichael Clift <michael@...> writes:
> Hi, I am using winavr, and would like to include the default eeprom > values (normally output to .eep) in flash memory. I want to do this so > that my application can easily default the eeprom. Whats the best way > to do this? can it be done with a modification to the linker script? > or should it be done in the makefile somehow? If you put the data into a struct like this: struct test { int i; char s[6]; }; struct test x PROGMEM = {7, "HELLO"}; then just read byte per byte from x for sizeof(x) times and write it into your EEPROM. Heike _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memoryOn Wed, Oct 21, 2009 at 07:40:50AM -0700, Parthasaradhi Nayani wrote:
> > >From: Michael Clift <michael@...> > > > >??? Hi, I am using winavr, and would like to include the default > >eeprom values (normally output >to .eep) in flash memory. I want to > >do this so that my application can easily default the >eeprom. > > Hello, > EEPROM data in FLASH memory? then the easy way is to use the PGM space > attribute to the variables you want in flash. Ditto. Declare the variables twice, once with a name that is obvious to you is EEPROM in the EEPROM space, and again with a name that is obvious to you is stored in FLASH. Then when/if you wish to restore EEPROM contents to their initial default values use the PGM modifier to read from FLASH and call the routine(s) used to write EEPROM. Duplicating the default data in your source code sounds wasteful but it will be easier to understand 6 months from now than an edit of the Makefile plus hacks to the memory segment definitions. I think it is possible that way to write the .eeprom segment to two places in memory, is just that you don't want to do it that way when there is an easier way that is also easier to understand. -- David Kelly N4HHE, dkelly@... ======================================================================== Whom computers would destroy, they must first drive mad. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memoryHi,
I am using for many years a system, I published as open source (LGPL like) at http://www.ethernut.de/en/documents/phat.html. Look for 'SPIFlashFileSystem' link to a zip file. This is a complete project, but there is a subdirectory eeparams, which can be extracted from it. Common problem is, that your variables in EEPROM changes between firmware revisions. Idea is to assign a unique ID to each data structure and to place a table with these IDs, offsets and lengths at the beginning of EEPROM area. Default table occupies space in flash. However this is not suitable for uPs with limited code, I found it usefull, because the code supports also fw downgrade, while preserving variables existing in both revisions and placing default values for new ones. At 11:34 21.10.2009, Michael Clift wrote: >Hi, I am using winavr, and would like to include the default eeprom >values (normally output to .eep) in flash memory. I want to do this >so that my application can easily default the eeprom. Whats the best >way to do this? can it be done with a modification to the linker >script? or should it be done in the makefile somehow? Dusan _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memory> Ditto. Declare the variables twice, once with a name that is obvious to
> you is EEPROM in the EEPROM space, and again with a name that is obvious > to you is stored in FLASH. Then when/if you wish to restore EEPROM > contents to their initial default values use the PGM modifier to read > from FLASH and call the routine(s) used to write EEPROM. I have been trying to find the origin of a story, without success so far, related to restoring default EEPROM settings to "factory" settings. Story goes like this: A lady took her car back to the dealer, and asked that they disable the front seat passenger air bags, as her son always road there. The dealer did as the lady asked. Some time later something happened, possibly a jump start due to dead battery, which caused the ECU to restore the EEPROM to factory specs, which included turning the passenger side air bag back on. There was then an accident, where boy was killed. Even if the story is not true, it still illustrates just how hard it is to do a "safe" embedded system. "Programming is a race between writing a program that any idiot can use, and the Universe building bigger and better idiots. The Universe is winning." -- http://www.wearablesmartsensors.com/ http://www.softwaresafety.net/ http://www.designer-iii.com/ http://www.unusualresearch.com/ _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memoryThanks for all the responses guys, some interesting ideas.
I don't really want to put all of my EEPROM data into one structure, as I have many eeprom variables with initializers distributed across a number of files. What I ended up doing, was to change the .eep output format to binary, then I copied this to an object file as described here http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata I then linked this object into my main code. It works a treat, only I have to build my code twice to get the initial values updated to flash, once to create .eep, and again to link in the object. The main reason for doing this, is that I have a boot loader that I want our clients to be able to use, only the boot loader does not support eeprom loading. It also saves me having to program the eeprom in production. Regards, Michael. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: including default eeprom values in flash memoryMichael Clift wrote:
> Thanks for all the responses guys, some interesting ideas. > I don't really want to put all of my EEPROM data into one structure, as > I have many eeprom variables with initializers distributed across a > number of files. > > What I ended up doing, was to change the .eep output format to binary, > then I copied this to an object file as described here > http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata > I then linked this object into my main code. It works a treat, only I > have to build my code twice to get the initial values updated to flash, > once to create .eep, and again to link in the object. > When you do this, are you 100% sure that the addresses of the eeprom variables don't change? You have no guarantees about this, unless you work very hard with segment names and linker files. Far and away the safest and most reliable method is to put your eeprom data within a single defined structure. It is better to have to restructure your program a bit at this stage, than to stick with your scattered data approach and have weird bugs later when the order of data in the final build does not match that of .eep file build. It also makes it far easier to put it in a single build without using external utilities. A poor but workable substitute would be to build in a check in your build process that confirms that that your linked .eep file matches the .eep file generated in the final build. You'll still get problems if you ever want to update the software in a system without reseting the eeprom to the flash defaults. > The main reason for doing this, is that I have a boot loader that I want > our clients to be able to use, only the boot loader does not support > eeprom loading. It also saves me having to program the eeprom in > production. > > > Regards, Michael. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
|
|
|
Re: Re: including default eeprom values in flash memoryThanks David for your help, I didn't think of that. I'll put the check
in, along with some warning notes for future reference. David Brown wrote: > Michael Clift wrote: >> Thanks for all the responses guys, some interesting ideas. >> I don't really want to put all of my EEPROM data into one structure, >> as I have many eeprom variables with initializers distributed across >> a number of files. >> >> What I ended up doing, was to change the .eep output format to >> binary, then I copied this to an object file as described here >> http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata >> I then linked this object into my main code. It works a treat, only I >> have to build my code twice to get the initial values updated to >> flash, once to create .eep, and again to link in the object. >> > > When you do this, are you 100% sure that the addresses of the eeprom > variables don't change? You have no guarantees about this, unless you > work very hard with segment names and linker files. Far and away the > safest and most reliable method is to put your eeprom data within a > single defined structure. It is better to have to restructure your > program a bit at this stage, than to stick with your scattered data > approach and have weird bugs later when the order of data in the final > build does not match that of .eep file build. It also makes it far > easier to put it in a single build without using external utilities. > > A poor but workable substitute would be to build in a check in your > build process that confirms that that your linked .eep file matches > the .eep file generated in the final build. You'll still get problems > if you ever want to update the software in a system without reseting > the eeprom to the flash defaults. > >> The main reason for doing this, is that I have a boot loader that I >> want our clients to be able to use, only the boot loader does not >> support eeprom loading. It also saves me having to program the eeprom >> in production. >> >> >> Regards, Michael. > > > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@... > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > > _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@... http://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
| Free embeddable forum powered by Nabble | Forum Help |