Shop OBEX P1 Docs P2 Docs Learn Events
Save that for later... — Parallax Forums

Save that for later...

CumQuaTCumQuaT Posts: 156
edited 2009-07-17 00:48 in Propeller 1
Hello hello,

Still kinda new to the Propeller, but I'm very slowly getting the hang of it, and enjoying the fact that I'm becoming more and more impressed the more I learn...

I'm using the standard by-the-book Propeller circuit with the standard 8 pin 32k EEPROM chip, and I'd like to be able to save a variable to the EEPROM so that the next time I turn my circuit on, it will be able to retrieve the data for later.

Is there an easy way to do this? Does anyone have a code example? Do I need more parts?

Any help would be great! Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who are you, and why are you reading my signature?

Comments

  • TimmooreTimmoore Posts: 1,031
    edited 2009-07-16 06:24
    Take a look at the ybox source www.deepdarc.com/ybox2/ the file settings.spin it stores its settings in eeprom. You can probably use that.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2009-07-16 06:54
    CumQuaT,

    Check out Andy Lindsay's excellent application notes and example Propeller code on EEPROM Datalogging

    http://forums.parallax.com/showthread.php?p=678271

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • SRLMSRLM Posts: 5,045
    edited 2009-07-16 07:04
    Has anybody ever thought about saving a variable within the first 32K of EEPROM space? Specifically, saving the variable right where it's address is (in relation to where Spin expects the variable to reside in RAM). Seems like that would be a good way to get "default" values without using an assignment operator.
  • BradCBradC Posts: 2,601
    edited 2009-07-16 07:35
    SRLM said...
    Has anybody ever thought about saving a variable within the first 32K of EEPROM space? Specifically, saving the variable right where it's address is (in relation to where Spin expects the variable to reside in RAM). Seems like that would be a good way to get "default" values without using an assignment operator.

    Absolutely, and it works a treat. The problem is each time you download a revised program you lose the data (but that happens no matter where you store the variable in the bottom 32k anyway)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Release the hounds!
  • Nick MuellerNick Mueller Posts: 815
    edited 2009-07-16 07:48
    > The problem is each time you download a revised program you lose the data (but that happens no matter where you store the variable in the bottom 32k anyway)

    It's a bit of a pain (because of extra steps required), but one could use 3PClient + 3PConv to flash only the part that actually contains code. You could also flash the persistent vars in the same go.


    Nick

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Never use force, just go for a bigger hammer!

    The DIY Digital-Readout for mills, lathes etc.:
    YADRO
  • BradCBradC Posts: 2,601
    edited 2009-07-16 08:15
    Nick Mueller said...
    > The problem is each time you download a revised program you lose the data (but that happens no matter where you store the variable in the bottom 32k anyway)

    It's a bit of a pain (because of extra steps required), but one could use 3PClient + 3PConv to flash only the part that actually contains code. You could also flash the persistent vars in the same go.

    Yes and no.. It's quite likely that if any code is changed the variables will be located in different places. Remember the VAR block begins long aligned after all the DAT and spin code. If the code changes size over or under a long boundary the position of the VAR block will change anyway.
    If you are going to do it your way, the best way to do it is start at $7FFF and work down. Then your data is always in a fixed position and you just load the eeprom with the program up to that point. As long as you don't smack into it with the stack you are all good to go.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Release the hounds!
  • Nick MuellerNick Mueller Posts: 815
    edited 2009-07-16 10:00
    > Yes and no.. It's quite likely that if any code is changed the variables will be located in different places.

    I meant to have the persistent var well outside of the reach of the program image and in a fixed position.
    This requires to read the var by some EEPROM-routines.
    You have the least headaches with a bigger EEPROM and writing the data starting at 0x8000.
    One might try my NVVar (use the seach function). It's not very simple, but has the advantage to detect new versions of the persitent vars and being able to handle that.

    Nick

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Never use force, just go for a bigger hammer!

    The DIY Digital-Readout for mills, lathes etc.:
    YADRO
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-07-16 15:09
    From the sound of this discussion, the Propeller apparently ignores the checksum on reboot ... right?

    -Phil
  • RaymanRayman Posts: 14,844
    edited 2009-07-16 15:40
    As Beau, pointed out... The datalogging code can be used to update code variables in EEPROM using these commands:

    eeprom.VarBackup(@values, @values[noparse][[/noparse]31] + 3) ‘ Backup
    eeprom.VarRestore(@values, @values[noparse][[/noparse]31] + 3) ‘ Restore

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • BradCBradC Posts: 2,601
    edited 2009-07-16 23:45
    Phil Pilgrim (PhiPi) said...
    From the sound of this discussion, the Propeller apparently ignores the checksum on reboot ... right?

    Right. The only time it looks at the checksum is immediately after download to ram.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Release the hounds!
  • CumQuaTCumQuaT Posts: 156
    edited 2009-07-17 00:48
    Wow, thanks guys! This should at least get me started!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Who are you, and why are you reading my signature?
Sign In or Register to comment.