rom : "I2C_ROMEngine.spin" usage

I have a prop1

I just need to store and retrieve 2 values, and then use those values in the code.

I'm using the "I2C_ROMEngine.spin"

I'm using the code as follows

FillBottle := rom.readword(5000)
wait_ms(20)
Minutes := rom.readword(5080)


so the way I understand this is that it should just put the contents of the word at mem location 5000, and 5080 in the the declared word's that I'm using.


I am getting erratic results, sometimes it works perfect sometimes it just locks up




Comments

  • 5 Comments sorted by Date Added Votes
  • JonnyMacJonnyMac Posts: 6,092
    edited July 18 Vote Up0Vote Down
    Do you have a pull-up on the SCL pin? Some drivers (like mine) need them, others don't. There are a lot of Parallax reference designs that show the pull-up only on the SDA line because the boot-up process drives the SCL pin. In either case, putting a 10K pull-up on the SCL pin will not hurt anything if you don't have one now.

    If you want to try another driver I've included my EEPROM object (which does require a pull-up on the SCL line). It's set for 64K which most boards use. If you are storing your values in the lower EEPROM you can use the variable location so that it will auto-load on the next booth. For example, using my driver you can save a variable so that it will auto-load after the next reset.
      ee.wr_word(@fillBottle, fillBottle)
    
    This writes the value of fillBottle to the address (@) of fillBottle which will cause it to auto-load; this is a very handy technique.

    As with the driver you're using, you can read the EE using the appropriate method and a valid address. Of course you can read from or write to any valid address in the EEPROM -- just be mindful not overwrite code, and only overwrite variables using the technique demonstrated above.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • I'm assuming you used writeword to write the values to 5000 and 5080 prior to calling readword. Also, is your program stored in EEPROM? If so, you will be writing over the program in EEPROM if it is larger than 5000 bytes. To avoid that you would need to use addresses at the high end of the EEPROM, such as $7FFC and $7FFE.

    Another trick to avoid having to read the values from EEPROM is to just write the locations of FillBottle and Minutes in the EEPROM. They would have be located in the DAT section. You would then write them as rom.writeword(@FillBottle, xxx) and rom.writeword(@Minutes, yyy). Then when you boot up from EEPROM FillBottle and Minutes will contain the values that you previously wrote to EEPROM.

    Keep in mind that the values you write to EEPROM will be overwritten if you re-write your program to EEPROM. To avoid this you would have to use a 64KB EEPROM instead of a 32KB one. Then you could store your values in the upper half of the EEPROM, which will be unchanged when re-writing the program.
  • ee.wr_word(@fillBottle, fillBottle)
    This writes the value of fillBottle to the address (@) of fillBottle which will cause it to auto-load; this is a very handy technique.


    I think I'm being dense on something, when you use the @ symbol to designate the memory address do you have to specify the memory address anywhere else? I am getting hung up on how does the program know after the next power on knowing where you stuffed the variable value.

    Keep in mind the only formal software classes I took were in 1985 and I learned FORTRAN and I wrote in FORTRAN and HPBASIC for the first 10 years of my work life and I've had a bit of a hiatus and back into a small bit of programming and I am trying to wrap my head around obtaining the memory locations. I"m really trying to get my aged brain to learn new things
  • msrobotsmsrobots Posts: 2,045
    edited July 20 Vote Up0Vote Down
    This is simply a side-effect of how the propeller loads the program out of the lower 32k of the eeprom.

    Stupid as it is, the addresses in HUBram are the same as in the eeprom.

    So if you have a DAT variable fillbottle the actual HUBadress of fillbottle is the same address in the eeprom.

    if you have

    DAT
    fillbottle long 12345

    and program that into the eeprom at address @fillbottle in the eeprom is a long containing 12345.

    if you now in your program overwrite the 12345 in the eeprom at address @fillbottle with say 22222 then on the next start of your program it will load as usual from the eeprom, but will have 22222 instead of 12345 at that address.


    As if you would have written

    DAT
    fillbottle long 22222

    in your source.

    neat trick,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • I think I'm being dense on something, when you use the @ symbol to designate the memory address do you have to specify the memory address anywhere else? I am getting hung up on how does the program know after the next power on knowing where you stuffed the variable value.
    You've probably caught on by now, but the Propeller loads the contents of the EEPROM into RAM. The original EE image contained reserved (and cleared) space for your variables. The @ operator returns the runtime address of a variable which corresponds to the reserved space in the EEPROM. If you write to the EEPROM as I demonstrated, the updated image will pre-load your variable(s). It's a really handy technique that I use quite often.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
Sign In or Register to comment.