Shop OBEX P1 Docs P2 Docs Learn Events
Storing Calibration Data — Parallax Forums

Storing Calibration Data

steprogsteprog Posts: 227
edited 2010-07-03 15:38 in Propeller 1
Hello Guys,
I find that I need to store calibration data into the eeprom when I reset or turn off the prop.· Is there a good way to do that?· I only have a 32k eeprom in my system.· Is there a way I can reserve a block of memory and then write back and forth into this?·
Thanks,
Greg

Comments

  • MagIO2MagIO2 Posts: 2,243
    edited 2010-07-02 08:51
    I guess you already have variables for keeping the calibration data during runtime. Whenever such a variable changes you can write it to the same address in EEPROM that it has in HUB-RAM.

    Remember, the EEPROM is completely copied into HUB-RAM at boot-time. As variables are reserved during compilation they have a fixed place in HUB-RAM/EEPROM. If you overwrite the value in EEPROM it will immediately be there after boot - no need to read it by yourself.
  • steprogsteprog Posts: 227
    edited 2010-07-02 08:55
    How do you write the values in eeprom? Do you know of a bit of code that works out there?
    Thanks,
    Greg
  • LeonLeon Posts: 7,620
    edited 2010-07-02 08:57
    Try the Object Exchange.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Leon Heller
    Amateur radio callsign: G1HSM
  • steprogsteprog Posts: 227
    edited 2010-07-02 09:07
    I did look through many of the objects and didn't see anything that would simply write to a location. Now thinking about it perhaps Im looking at it in the wrong way. I do remember some i2c eeprom objects. I should check that. Its late..
    Thanks,
    Greg
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-07-02 09:36
    Not sure if this helps but take a look at this. http://obex.parallax.com/objects/493/ You'll need the 64k eeprom (24LC512) version & use the upper 32k for data storage instead.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Ken
  • steprogsteprog Posts: 227
    edited 2010-07-02 09:49
    Ken
    Have you used this? I was looking it over tonight. I wont have time to switch to 64k eeprom however. I'm hopping to be able to define a block of memory where I can write calibration data that automatically gets brought back on reset. These would be simple variables nothing fancy here.
    Greg
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-07-02 10:13
    Greg,
    Yes but I'm using this as a boiler-plate for my own project. Just remembered. Is this what you're looking for? http://forums.parallax.com/forums/default.aspx?f=25&m=219237

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Ken
  • LeonLeon Posts: 7,620
    edited 2010-07-02 10:15
    I've used that code, it works OK.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Leon Heller
    Amateur radio callsign: G1HSM
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2010-07-02 16:09
    In my opinion my Simple Database system (in my signature) is the easiest. You just have to come up with names for the values (heck they already have variable names). But the software will take care of where it is stored and how to access it. It can even do strings.

    It may be a bit overkill for your project if you only have a single profile of calibration settings or only a few settings. But the object also has read and write methods that could be used for stand alone processes, this may be more of what you are looking for. If you need to store a stack or string it will manage them across the EEPROM sectors; or just write and read byte/word/long size sections of the EEPROM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    April, 2008: when I discovered the answers to all my micro-computational-botherations!

    Some of my objects:
    MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
    Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
    String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
    Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
  • steprogsteprog Posts: 227
    edited 2010-07-02 20:31
    Thanks Guys,

    I got lots of sources and things to look at.· I can't believe how great you fellas are when it comes to helping everyone out.· I hope someday I will get wise enough to return the favor.· Have a happy 4th everyone.

    Thanks Again,

    Greg
  • localrogerlocalroger Posts: 3,452
    edited 2010-07-03 00:38
    Hi Greg -- I'd just like to add a suggestion. I used the EEPROM driver code from the Obex Settings object, but it's way overkill for most uses so what I did was to take the page read/write code from it, which works quite reliably. You can manually decide to store your values at certain addresses at the very top of RAM, and just manually save the EEPROM page that contains them when you make a change. The neat thing about that approach is you don't even have to manually read the changes back, because they'll be loaded when you boot the prop -- just read the RAM locations on app startup. Unless your app is very large it will leave everything above $7F00 pretty much unmolested so you can do whatever you want up there.
  • steprogsteprog Posts: 227
    edited 2010-07-03 02:05
    I'll take a look thanks
  • steprogsteprog Posts: 227
    edited 2010-07-03 08:01
    localroger said...
    Hi Greg -- I'd just like to add a suggestion. I used the EEPROM driver code from the Obex Settings object, but it's way overkill for most uses so what I did was to take the page read/write code from it, which works quite reliably. You can manually decide to store your values at certain addresses at the very top of RAM, and just manually save the EEPROM page that contains them when you make a change. The neat thing about that approach is you don't even have to manually read the changes back, because they'll be loaded when you boot the prop -- just read the RAM locations on app startup. Unless your app is very large it will leave everything above $7F00 pretty much unmolested so you can do whatever you want up there.
    localroger
    I looked through the settings.spin and there is alot of stuff not needed.· One routine PUB commit | addr seems like what you must have used.· Did you just strip everything else away?
    Greg
  • steprogsteprog Posts: 227
    edited 2010-07-03 08:08
    Bobb Fwed said...
    In my opinion my Simple Database system (in my signature) is the easiest. You just have to come up with names for the values (heck they already have variable names). But the software will take care of where it is stored and how to access it. It can even do strings.

    It may be a bit overkill for your project if you only have a single profile of calibration settings or only a few settings. But the object also has read and write methods that could be used for stand alone processes, this may be more of what you are looking for. If you need to store a stack or string it will manage them across the EEPROM sectors; or just write and read byte/word/long size sections of the EEPROM.

    ·Bobb,
    I looked through this object and it's a nice piece of work.· All I need is just 20 or 30 varables to store that I can bring back on reboot.· Im still a bit weak with spin however.· One question, how do you know where your putting these values in memory.· I only have the 32k eeprom and I need to make sure I'm putting the data in a known block where I don't overwrite my code.
    Greg
  • localrogerlocalroger Posts: 3,452
    edited 2010-07-03 14:32
    steprog, yeah, I just chucked most of it and used the raw EEPROM read/write object. There are a few other objects that have similar code but I found it easiest to lift from Settings because even though it's overcomplicated it's very similar to what I wanted to do, which in turn is probably even a bit more complicated than what you need.
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2010-07-03 15:38
    In the CON section at the top of the object is where you define the range that can be used. By default it uses the top portion of a 32K EEPROM. I don't remember exactly how much, but you can adjust that.
    steprog said...
    Bobb Fwed said...

    In my opinion my Simple Database system (in my signature) is the easiest. You just have to come up with names for the values (heck they already have variable names). But the software will take care of where it is stored and how to access it. It can even do strings.

    It may be a bit overkill for your project if you only have a single profile of calibration settings or only a few settings. But the object also has read and write methods that could be used for stand alone processes, this may be more of what you are looking for. If you need to store a stack or string it will manage them across the EEPROM sectors; or just write and read byte/word/long size sections of the EEPROM.

    Bobb,
    I looked through this object and it's a nice piece of work. All I need is just 20 or 30 varables to store that I can bring back on reboot. Im still a bit weak with spin however. One question, how do you know where your putting these values in memory. I only have the 32k eeprom and I need to make sure I'm putting the data in a known block where I don't overwrite my code.

    Greg
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    April, 2008: when I discovered the answers to all my micro-computational-botherations!

    Some of my objects:
    MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
    Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
    String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
    Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
Sign In or Register to comment.