saving values through power off cycles
grouchy
Posts: 16
Could someome point me to a snippet of code or a thread that shows the use of the settings object.
I need to save a floating point value though power off cycles, so far it's not working for me
thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Rudy's CNC Freeware·· http://www.enter.net/~schleinkofer
I need to save a floating point value though power off cycles, so far it's not working for me
thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Rudy's CNC Freeware·· http://www.enter.net/~schleinkofer
Comments
Is there a memory space in the eeprom used for code storage that you can use to store non-volatile data, or do you need a seperate eeprom for this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In the propeller tool. If you hit F8 it will bring up a informational window with used space. Above the program and variable space is stack space. This can be used (in EEPROM or RAM) as general storage. It is best to start at the highest bytes and work your way back (to give the best chance of not interfering with the program's functionality).
@grouchy: I am working on an object that will let you easily store values to the EEPROM based on a name...a beta version is up on the OBEX, but a much better version is in the works as I type (well, before and after I type here). This may be all you need. A simple way to do it (based on EEPROM addresses) is to grab the basic i2c driver object and use it's read/write commands.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Post Edited (Bobb Fwed) : 8/20/2009 5:51:24 PM GMT
Read more here: obex.parallax.com/objects/493/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
Not every project requires eeprom storage, but many do - configuration info, data logging etc.· I'm still warming up to the Prop, and occasionally I have to figure out ways to accomplish things like this that I've taken for granted for so long with uc's like the avr.
Am I correct that a cog needs to be dedicated to the I2C communication?
edit -
@ Jim Fouch : That's a good suggestion.· I knew those chips had some free user ram, but never had to use it because I had easy access to eeprom.· Of course, eeprom has finite write limitations as you point out, so any non-volatile data that is frequently updated may be better housed in something like that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Agent420) : 8/20/2009 7:46:34 PM GMT
I have a question about this topic.
On·the PPDB development board there is a 32K EEProm chip (24LC256)that can be easily replaced.
My question is can I just remove it and put a 64K one instead (24LC512)???
Sam
·
You don't need to dedicate a cog to I2C. Basic_I2C_Driver is written in Spin and works fine just called from your program. It doesn't start another cog.
There are I2C assembly routines that use a separate cog for speed like sdspiFemto.spin which is used by FemtoBasic.
SamMishal,
Yes, you could directly substitute a 24LC512 or Atmel 24C512 for a 24LC256. You can even substitute an Atmel 24C1024B for a 24LC256 and get 128K of EEPROM.
Now the next question is this:
If you have a larger EEPROM than 32K and you have data in the
memory below 32K...does it get erased if you reprogram the propeller?
Does the Propeller tool erase the entire EEPROM or does it just overwrite
the top 32K and leaves any extra memory alone?
Cheers!
Sam
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Now I can see that the solution is to just replace the 32K for something bigger and use that
over pins 29 and 28 with an I2C driver and there would be no need to add any other chips.
·
Of course you have to be careful to only write to memory below 32K and you won't have
to worry about finding out the size of your program etc.
·
However on some dev boards you do not have the option to change the EEPROM since it is
soldered in. In these cases you need to either add another chip or just use the remaining
memory below your program.
·
This is another example why a separate replaceable EEPROM is actually a good idea....more versatility.
·
Sam
·