Non volatile storage possibilities investigation
Harprit
Posts: 539
Is there a way to store a changing variable that can then be re-read on the next powering up of the Prop?
Is there a way to access the EEPROM to store this variable? Will this be viable (re read able) if the EEPEOM is then not disturbed?
On the other hand is it possible to store in HUB memory and will the variable be available on reload of memory if the Prop was not powered down?
I want to store the last position of a CNC machine just before shut down.
H
Is there a way to access the EEPROM to store this variable? Will this be viable (re read able) if the EEPEOM is then not disturbed?
On the other hand is it possible to store in HUB memory and will the variable be available on reload of memory if the Prop was not powered down?
I want to store the last position of a CNC machine just before shut down.
H
Comments
This object:
http://obex.parallax.com/object/23
lets you write to the EEPROM. You would probably want to write from $1FF down, ( top of the 32K EEPROM), or if you have a 64K EEPROM, you could use from $200 up.
EDIT: That would be $7FFF down in a 32K EEPROM and $8000 up in the 64K EEPROM
No, anything stored in hub ram will disappear when power is turned off.
If a large number of erase/write cycles are required you can take a look at various non volatile ram options like battery backed ram and fram.
eg in the Prop case a deep power down will corrupt the saved value, but a code reload with power sustained is ok.
Likewise on a EEPROM, a brand new part will have invalid XYZ data.
Data writes up to the Page size take the same time, so you can have quite a few bytes to play with.
If this changes a lot, or uncontrolled off is common, then FRAM can be better than EEPROM, as it has faster writes and no practical endurance limits.
On a machine, you might drop the write cycles, by saving LastX,NewX, on a rotating page basis
H
at boot time the propeller does not care about the checksum of the eeprom.
Now comes the funny thing. The content of the eeprom gets copied into the ram. Thus eeprom addresses and ram addresses are the same.
This leads to a quite nice feature in spin.
Lets say you have a variable with predefined content, say a long value in your dat section, named 'mySettingValue' containing - say - 12345 or whatever.
Programming the eeprom will write 12345 to that memory location of the eeprom and the propeller will load (boot) from the eeprom and has a value of 12345 at the memory location @mySettingValue in ram and in the eeprom.
So the address is the same in ram and eeprom.
At runtime your program can now write the value of the ram location at address @mySettingValue to the same address in the eeprom and after a reboot the NEW value of mySettingValue will be booted by the propeller into the same location in ram as 12345 was loaded before.
a simple eeprom.write(mySettingValue,@mySettingValue) will save the value from ram to eeprom. You will not need to do anything to retrieve that value, while booting the propeller will just populate the ram with the value saved in eeprom and you are good to go.
This is IMHO the easiest way to save persistent setting in the eeprom.
2 things to watch out for.
This method uses the standard eeprom size of 32K and manipulates the standard boot eeprom content So if your reload your program from PropTool or whatever you use the setting will be gone and overwritten by the standard value in the source.
To avoid that (say for calibration data or so) you need to save the persistent setting in the upper eeprom (>32K). Then it will survive reloading the eeprom with a new program but you also need to read in the setting from there at your application startup.
And not all Propeller boards have 64K eeproms. Some still have 32K an there is no upper half of eeprom available.
my two cents!
Mike
I've been using a DS1302 to save data between sessions. The attached file will give you an idea of what's required. The advantage of this approach is you don't have to worry about wearing out the EEPROM. You do have to include a standby battery for the DS1302 though.
Sandy
I am using second method (store in upper eeprom part), because first method for some reasons didn't worked for me. Bugs in my code?
CON 'User constants pixelcount=100 maxframes=50 CON ' System constants _clkmode = xtal1 + pll16x 'Standard clock mode * crystal frequency = 80 MHz _xinfreq = 5_000_000 '' Next two lines borrowed from JonnyMac '' Thank You, it great idea! CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq ' system freq as a constant MS_001 = CLK_FREQ / 1_000 ' ticks in 1ms txpin=30 rxpin=31 i2cSCL=28 i2cSDA=29 EepromStoreAddress = $8000 OBJ debug : "FullDuplexSerial" EEPROM : "I2C PASM driver v1.4" PUB Main | a debug.Start(rxpin,txpin,%0000,115_200) 'start proppulg serial EEPROM.start(i2cSCL,i2cSDA,400_000) 'init eeprom readeeprom 'read eeprom 'do some stuff like launch new cogs etc repeat a:=0 'do some stuff in loop DAT liveframe long $00_00_00_00[pixelcount] 'this will not be saved eepromsavestart ''selfexplain frames long $00_00_00_00[(pixelcount+1)*maxframes] 'this will be saved in upper eeprom part eepromsaveend 'selfexplain PUB wipe 'clear EEPROM storage and RAM longfill(@eepromsavestart,0,constant((@eepromsaveend-@eepromsavestart)/4)) writeeeprom pub readeeprom 'Load from EEPROM to RAM when booting eeprom.read_page(eeprom#eeprom,EepromStoreAddress,@eepromsavestart,constant(@eepromsaveend-@eepromsavestart)) pub writeeeprom|i 'save from RAM to EEPROM '' Loop for pagewrite because there are 64 bytes in one page repeat i from 0 to constant((@eepromsaveend-@eepromsavestart)/64-1) eeprom.Write_page(eeprom#EEPROM, EepromStoreAddress+i*64, @eepromsavestart+i*64,64) pub dumpram|i ''dump RAM contents to serial debug terminal repeat i from 0 to @eepromsaveEnd-@eepromsavestart-1 if (i//16)==0 debug.tx(13) debug.hex(@eepromsavestart+i,4) debug.tx(32) debug.hex(byte[@eepromsavestart][i],2) debug.tx(13) DAT {{ MIT licence bla bla bla }}It also have 3 timestamp memory to store when something happened.
This is RAM, but will not be lost as you supply a tiny battery that it auto-switch over to when main power is gone.
http://www.mouser.com/ProductDetail/NXP-Semiconductors/PCF85263ATL-AX/?qs=sGAEpiMZZMtpeOq%2f1QMb1R3j9P4FFFLvmvjwceenyyw%3d
if you need 64bytes of RAM
http://www.mouser.com/ProductDetail/NXP/PCF85363ATL-AX/?qs=%2fha2pyFadugCB5rfANsExNtXYfVl%2f4QeZ6stefccCRI%3d
H
H
How do I know the size of my propeller eprom? 32k 64k? I have an older board that was part of a learning package with the bread board and lots of components already onboard. I just received 5 of the Rev C Activity boards I bought with the defect..
I do have a need for non-volitile memory as well to store log files and since it will be in an automotive environment I do NOT want to use the SDcard to store a log file and I want it to survive power off cycles. (I will be logging the CAN BUS from my truck and saving it to a connected PC once in a while. Could stay off for up to a week but will have access to the secondary automotive battery which will remain separate from the primary battery and only power my computer devices when the vehicle is off. This vehicle has 10.3k baud rate and is actually GMLAN which uses a CANBUS type protocol but much simpler hardware.)
What is FRAM?
I would LOVE if I could get a gig of storage but I guess it all depends on what is practical.
I will likely setup a log file that rolls when it gets full.
Rodney