How can I determine where data is located in EEPROM

Bean

I have a program that has a large data section.
How can I determine where that data section is located on the boot EEPROM ?

In other words, I want to modify this data at runtime and store it back onto the EEPROM so that when the propeller boots next time, the new data is loaded.

I tried just using the HUB address of the table as the EEPROM location, but that doesn't seem to be quite right. It looks like there is some kind of offset from the HUB memory address.

Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman

Luis Digital

A solution can be to write a constant one and then to see where is (with the eyes ), and then to note the direction.

DAT
Reserved_9_Bytes Byte "RESERVED9"

Paul Baker

For this, you need to use @@ instead of @ to generate the address, @ only provides the relative offeset of the variable wrt the object. @@ provides the absolute address.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Bean

Thanks Paul, I will try that.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman

cgracey

Actually, @variable will return the absolute RAM address which is the same as the EEPROM address. @@ is used to add the current object's base address to some offset value so that you will then have an absolute address:
·
PRI StringAddress(Efficient, StringNum)
·
· if Efficient
····return @@strings[noparse][[/noparse]StringNum]··· 'Get the absolute address of string1, string2, or string3
· else
····return lookupz(StringNum : @string1, @string2, @string3)··· 'Do the same thing less efficiently
·
·
DAT
·
strings·· word·· @string1, @string2, @string3
·
string1·· byte·· "Ay",0
string2·· byte·· "Bee",0
string3·· byte·· "Sea",0

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Remy Blank

Chip Gracey (Parallax) said...

DAT

strings word @string1, @string2, @string3

string1 byte "Ay",0
string2 byte "Bee",0
string3 byte "Sea",0

Now I'm confused. Does this mean the "strings" line above stores three offsets relative to the current object's base address? How can I then store three absolute addresses? With @@string1?

-- Remy

cgracey

Remy Blank said...

Now I'm confused. Does this mean the "strings" line above stores three offsets relative to the current object's base address?

Yes. While, @label is usually used in Spin, @label can be used within DAT/word declarations to store offsets of DAT variables within the object.

How can I then store three absolute addresses? With @@string1?


@@ is only usable at run-time in Spin. For example, @@0 will return the base address of the object. Because objects are entities unto themselves and relocatable during compilation/mixing, they don't know their absolute address at compile-time. It can only be learned at run-time. While it is possible to make the compiler patch addresses, it would complicate its internals greatly. During development of the Spin language, the door to live setup/takedown of objects was left open through some potential operating system, requiring that objects work wherever they are placed, but now, in practice, objects do have stable addresses, they just aren't known at compile time.

-- Remy

O

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Remy Blank

Thanks Chip, now I understand.

Is that why data addressed by RDLONG/WRLONG and friends is always defined in the VAR section, even if it is only used by assembly code? Because in that case, the @ operator returns an absolute address? But that would mean that the address of VAR sections is known at compile-time?

Anyway, the current implementation in my assembler is buggy

-- Remy