Shop OBEX P1 Docs P2 Docs Learn Events
eeprom memory map? — Parallax Forums

eeprom memory map?

DomanikDomanik Posts: 233
edited 2014-11-07 20:21 in General Discussion
Is there a memory map of the upper half of the ActivityBot eeprom memory. I understand there's free space beginning at 32768 up to perhaps 63398. Currently two cal routines store data in 63400 upwards and there may be others I don't know about. I'd like to avoid overwriting cal data and find a safe place in the upper end to put my cal data.
Thanks,
Dom..

Comments

  • T ChapT Chap Posts: 4,223
    edited 2014-11-04 05:08
    It would be very easy to print the eeprom with a serial terminal so you can see what is any eeprom address.
  • ValeTValeT Posts: 308
    edited 2014-11-04 05:22
    In BASIC Stamp, there is a memory map option that will let you see what is going on in the EEPROM. Maybe there is an option like that in SimpleIDE that will allow you to see what is going on.
  • DomanikDomanik Posts: 233
    edited 2014-11-04 08:54
    A couple of Parallax device drivers use the upper sections of eeprom (63400 +++). Are there other drivers or common programs that store calibration data in upper eeprom? A memory map document would clarify what's available. Does one exist anywhere?

    Dom..
  • PublisonPublison Posts: 12,366
    edited 2014-11-04 09:23
    You might try try the EEPROM Monitor in the OBEX. I have nor tried it, so I do not know what it reports.

    http://obex.parallax.com/object/221
  • JonnyMacJonnyMac Posts: 9,105
    edited 2014-11-04 10:45
    The Memory Map feature in Propeller Tool -- like that in the BASIC Stamp editor -- is a map of the image to be downloaded to the device. Since the Propeller compiler doesn't use EE space about $7FFF, it doesn't know about it. You'd have to create an application to read the data out of the upper EE for display.
  • DomanikDomanik Posts: 233
    edited 2014-11-04 12:03
    It's pretty straight forward to read and write to eeprom, not a problem for me. What I'm looking for is a Parallax document that defines reserved memory for all users, not just my application. In the simpleIDE library there exists:



    #define
    _ActivityBot_EE_Start_ 63418



    ActivityBot EEPROM calibration data start address.



    #define
    _ActivityBot_EE_Pins_ 12


    #define
    _ActivityBot_EE_Trims_ 28


    #define
    _ActivityBot_EE_Left_ 52


    #define
    _ActivityBot_EE_Right_ 1052


    #define
    _ActivityBot_EE_End_ 63418 + 2052



    ActivityBot EEPROM calibration data end address.




    AND in abvolts.c



    #define
    _abvolts_EE_start_ 63400



    abvolts EEPROM calibration data start address.



    #define
    _abvolts_EE_end_ 63400 + 16




    abvolts EEPROM calibration data end address.




    After these routines run what happens to the cal data? Does it move to the lower half of the eeprom or stay in high memory? What's to prevent a future SW driver from overwriting another routine's info?

    Dom..
  • GenetixGenetix Posts: 1,754
    edited 2014-11-04 14:53
    This message should be moved to the Learn forum so Andy can answer your question.

    Generally EEPROM data is saved from the highest memory address downward but you might want to start at 32K (32768 or $8000) and move upward since you noticed EEPROM values are stored near the top. As Jon mentioned only the lower 32KB are affected by programming the Propeller chip so anything in the upper 32KB is safe unless a program writes over it.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2014-11-04 15:20
    Domanik wrote: »
    What I'm looking for is a Parallax document that defines reserved memory for all users, not just my application.

    I agree, this would be a good document to have.

    I personally use sections of the upper EEPORM for my own purposes. One thing I usually add to the upper EEPROM is an ID # for the particular Propeller board. This way I can use the same program on multiple Props which behave a bit different depending on their assigned ID. This is useful in Prop to Prop communication projects.

    I keep a header file were these locations are assigned. It would be nice if these locations were easily identifiable with the ActivityBot code examples.

    You can find these location by digging through the source code (as it looks like you've already done) but I agree, it would be nice if this information were easier to find.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-04 16:28
    Domanik wrote: »
    It's pretty straight forward to read and write to eeprom, not a problem for me. What I'm looking for is a Parallax document that defines reserved memory for all users, not just my application. In the simpleIDE library there exists:

    After these routines run what happens to the cal data? Does it move to the lower half of the eeprom or stay in high memory? What's to prevent a future SW driver from overwriting another routine's info?

    Dom..

    Having fixed locations specified for "all users" is impractical as applications vary so much, as do users and uses. I have a unit that records log files in on section of EEPROM, holds a access ID database in another etc. For my networking systems I use the very top of 64K for holding IP config data etc including a soft MAC address, I even use the upper 32K for print strings that would otherwise consume valuable RAM. So for networking systems I could say "use these addresses and we will all be happy" but even then I doubt that this would be the case.

    Your concern about a future SW driver overwriting is perhaps unwarranted though as you are the programmer, you should know what you are doing and where everything goes. If you say "use this address" then it is just going to do that.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2014-11-04 16:35
    Peter Jakacki wrote: »
    Having fixed locations specified for "all users" is impractical as applications vary so much, as do users and uses. . .

    Your concern about a future SW driver overwriting is perhaps unwarranted though as you are the programmer, you should know what you are doing and where everything goes. If you say "use this address" then it is just going to do that.

    I think Domanik is hoping for the locations used by the ActivityBot tutorials.

    I haven't spent a lot of time with the AB tutorials but I also wondered where the calibration data was being stored. IIRC, these locations weren't easy to find. I agree it would be nice to have a way to easily find which locations are being used.

    While I agree having fixed locations for "all users" isn't practical, I don't think it's unreasonable to hope one AB tutorial wont overwrite calibration data saved in from an earlier tutorial.
  • DomanikDomanik Posts: 233
    edited 2014-11-05 15:11
    Duane Degn wrote: »
    ...one AB tutorial wont overwrite calibration data saved in from an earlier tutorial.
    For me the tutorials are a nice learning tool but ... The Parallax SimpleIDE lib stores data in high eeprom and this cal data might be used by several users. By using the Parallax lib (which has support, fixes,etc.) it would be nice to know where things are stored. On another note, if submissions to OBEX have a consistent strategy for important eeprom data, it could make it easier to share code with various users without mangling things. All that said, there doesn't seem to be a scheme at this point in time so I'm ready to move on.

    Duane: I like your approach and your idea about a unique identifier for each robot. Also I'd like to thank you for ALL the posts you've done over the years on this forum. I've learned a lot from your posts and it's greatly appreciated.

    Thanks to you too Jack-- you have a wealth of knowledge and a no nonsense approach to things, I read your posts carefully looking for nuggets in each (found several).

    Dom..:smile:
  • Andy Lindsay (Parallax)Andy Lindsay (Parallax) Posts: 1,919
    edited 2014-11-07 14:58
    Libraries that store EEPROM values take the highest available addresses that are not already in use by other libraries. Since library calibration data builds from 65535 downward, we recommend that applications build from 32768 upward.

    Up to now, avoiding overwriting library calibration data has been a matter of checking the Macros section in the documentation pages of each library the application uses. Reason being, if it uses EEPROM, it'll have #defines there. Moving forward, it seems like it would be better to have a single page that inventories all libraries with EEPROM calibration data. How's this look?

    https://propsideworkspace.googlecode.com/hg/Learn/Library%20Cog%20and%20EEPROM%20Usage.html
  • Duane DegnDuane Degn Posts: 10,588
    edited 2014-11-07 20:21
    Andy Lindsay (Parallax) wrote: »
    How's this look?

    https://propsideworkspace.googlecode.com/hg/Learn/Library Cog and EEPROM Usage.html

    I think that looks great!

    I think I'll find this information very helpful in my C projects.

    Thank you!
Sign In or Register to comment.