Parallax Propeller I - EEPROM Constants

sobakava · 2013-12-12 03:19

I'm low on memory for a product design with Propeller. I'm using basically SPIN and just learned some Parallax assembly programming.

I needed to reduce composite video resolution to 320x240 and re-written a low level SPI like read-write routines with assembly. With the assembly, serial routine runs 100 times faster now.

In the EEPROM I store some constant values, strings, data tables like this:

DAT


menu  byte  "MENU", 0
settings  byte "SETTINGS",0 
clock   byte  "CLOCK",0

mytable  byte  0,1,0 .......
mytable2 byte 0,1,0 .......

I'm using these strings with gr.textfunction.

gr.text( 10 , 10 , @menu )

I'm accessing tables like this:

result :=  byte[ @mytable ][ n ]

Whenever I need to modify these data, I'm using a simple I2C read/write object to write to the EEPROM.

My display base address is at $3400. When I press F8, I can see the yellow (variables) section of the code ends before $3400. And my strings are allocated at the top of the memory. I read that when the propeller boots up, it copies the EEPROM to RAM.

So, probably I misunderstood or confused with the Parallax memory allocation completely; I think in my case, I don't need the constants to be copied to the RAM directly. I can access them with I2C whenever I need with temporary values in the RAM. I mean, when I need to use MENU string, I can pull it to a byte array in the RAM with I2C. After I finish gr.text operation, I can pull SETTINGS to the same byte array. Right?

Do these data fill my RAM unnecessarily? Can I locate them at the end of the EEPROM and prevent to be copied into RAM on boot?

Here is how I imagine Parallax RAM and ROM (eeprom):

RAM :  $0  [  CODE      .  VARS     .  DISPLAY BUFFER MEM    ]  $7FFF
ROM:  $0   [ CODE       .  VARS     .  EMPTY  ???????????????]  $7FFF

T Chap · 2013-12-12 05:55

What are you compiling with? Have you tried compiling with the BST program using the optimize features under Tools>Compiler Prefs then check Eliminate Unused + Generic Safe? If you already have all the data on eeprom, and you only need to access values a la carte, then there is no real need to copy all the data to ram. Just read the epprom address as needed into a variable.

sobakava · 2013-12-12 06:28

T Chap wrote: »

What are you compiling with? Have you tried compiling with the BST program using the optimize features under Tools>Compiler Prefs then check Eliminate Unused + Generic Safe? If you already have all the data on eeprom, and you only need to access values a la carte, then there is no real need to copy all the data to ram. Just read the epprom address as needed into a variable.

It is Propellel Tool / SPIN... I'm not compiling.

T Chap · 2013-12-12 06:57

If you are not compiling, then how do you know you are low on memory? If you have only a 32k eeprom, then if you copy the data to the unused space on the eeprom, it will only survive until you reprogram the Propeller to eeprom, so you will have to re-copy the data to the end of the eeprom after each Propeller Eeprom update. Otherwise change to a larger eeprom and the data will be safe after each program.

jazzed · 2013-12-12 07:37

Many Propeller boards have a 64KB EEPROM.

Text strings and other data can be saved/loaded in the upper 32KB and accessed via Spin I2C methods.

sobakava · 2013-12-12 07:44

T Chap wrote: »

If you are not compiling, then how do you know you are low on memory? If you have only a 32k eeprom, then if you copy the data to the unused space on the eeprom, it will only survive until you reprogram the Propeller to eeprom, so you will have to re-copy the data to the end of the eeprom after each Propeller Eeprom update. Otherwise change to a larger eeprom and the data will be safe after each program.

Since the propeller runs the "interpreter code" from ROM, I don't count SPIN tool as an assembler. It just show you the final memory allocation with F8 key and but it is not "native binary" code of course. This is why I'm telling I'm not compiling.

I have only 32KB EEPROM and I can see my code + vars end before $3200. So I want to locate contants after $3200. How can I do that?

DAT

org $3200
menu byte "MENU", 0
settings byte "SETTINGS",0
clock byte "CLOCK",0
mytable byte 0,1,0 .......
mytable2 byte 0,1,0 .......

simply does not work because according to my understanding, it is for allocating data relative to HUB memory addreses.

My question is, is there a way to place pre-defined values at the end of 32KB EEPROM using SPIN tool? Of course I can always write those locations with SPIN I2C object or using an EEPROM programmer. But I want to load my initial data while I'm loading my code using Spin tool.

jazzed · 2013-12-12 08:27

Hi,

Your example (quoted) does not put memory at address $3200 (because ORG doesn't work that way with Propeller).

It will however load the values you ask for in hub ram, and you can use the symbols to find the offsets for saving new values.

Whatever is in 32KB EEPROM will be loaded on reboot.

sobakava wrote: »

DAT

org $3200
menu byte "MENU", 0
settings byte "SETTINGS",0
clock byte "CLOCK",0
mytable byte 0,1,0 .......
mytable2 byte 0,1,0 .......

simply does not work because according to my understanding, it is for allocating data relative to HUB memory addreses.

When you press F8,9,10,11 Propeller Tool "compiles" the program down to byte-code and assembly.

Don't assume Propeller Tool or Spin/PASM will behave any certain way until you've had some quality time with the documentation.

sobakava · 2013-12-12 10:12

Then, using Propeller Spin tool, there is no way to locate data blocks at specified location (address) within the SPIN or ASM code right?

Everytime we load new firmware to the boards, after the programming, we need to put our constant data at the end of memory using an Eprom programmer hardware or using code being executed in the Parallax processor.

We are manufacturing a couple of hundred devices per month and I would prefer to program the code + data in one round. I will try to export my final code as an EEPROM file and inject my data blocks into it externally and load it to EEPROM.

Is there a more effective way to do it?

sobakava · 2013-12-12 10:15

jazzed wrote: »

Many Propeller boards have a 64KB EEPROM.

Text strings and other data can be saved/loaded in the upper 32KB and accessed via Spin I2C methods.

To have a 32KB EEPROM would be nice but there are almost thousand devices in the field already. Returning them into the factory and replacing the EEPROMS is one of the last things we prefer to do.

Mike Green · 2013-12-12 10:48

I think you're trying to solve the wrong problem. As I understand it, you have tables that you're using as part of your program and you want to modify these tables in EEPROM as your program runs so that, when your device resets, the values saved in EEPROM will be the values used instead of the initial values written in your source code. Your program doesn't know the addresses of these tables in EEPROM, so you have to move them around to fixed known locations so you can locate them in EEPROM.

When the Propeller is reset or powered on, the first 32K of EEPROM gets copied into RAM for execution. At this point, the RAM is a direct image of the EEPROM with locations 0-32767 of RAM corresponding exactly to the same locations in the EEPROM. If you want to overwrite the copy of the program (and its data) in EEPROM, you just use the same locations in EEPROM as are used in RAM. You have a byte table "mytable" in your program (without the ORG statement). When the program is executing, the address of this table (in RAM) is @mytable. The address of this table in EEPROM is the same (@mytable) and, if you write new data to EEPROM at the address @mytable, it will be loaded to RAM the next time the Propeller is reset.

Note that, when updating your software, you will not be able to preserve existing values in the EEPROM because the process of loading a new update to EEPROM causes the complete replacement of the 1st 32K of EEPROM with the new program regardless of the size of the program. The only realistic way to do this would be to use a 64K EEPROM with the 2nd half used to hold the data / tables / strings. You could also add a feature to your program that would upload the data to a PC prior to updating, update the software, then restore the data from the PC. You'd need a program for the PC as well as changes to your Propeller program to do this.

jazzed · 2013-12-12 16:16

Assuming you're not using all of the Propeller RAM for code and data, the best approach is probably to use a hard-coded address in the upper part of the memory map like 0x7c00 or higher.

MagIO2 · 2013-12-15 12:54

You can have the data in an external file and include it in the source code using the file statement.

dat
mydata  file "data.bin"

pub
  x:=mydata[0] ' reading first byte
  y:=long[ @mydata ][ 5 ] ' read 6th long which is at location @mydata+20

To make access more readable it makes sense to work with constants, which define the relative address in the file.

T Chap · 2013-12-15 14:20

If you really need the data to reside on the eeprom, the question is whether there is valuable data already stored on the eepom that you do not want to lose each time you update the program. If this is the case, I would create an app for the PC using Xojo (formerly Realbasic). Get the data from the eeprom into the PC with the app using an opcode to tell the Propeller to transmit the data out serially via the USB cable. The app on the PC can store permanently on file the data for later use. After retrieving the data, you can update the program, then send the data back to the Prop for it to write the original settings to the eeprom. This way, you never lose the settings in the eeprom, and it is a simple process to retrieve any user data as well as reload the data after it gets wiped.

cavelamb · 2013-12-15 18:04

T Chap wrote: »

If you really need the data to reside on the eeprom, the question is whether there is valuable data already stored on the eepom that you do not want to lose each time you update the program. If this is the case, I would create an app for the PC using Xojo (formerly Realbasic). Get the data from the eeprom into the PC with the app using an opcode to tell the Propeller to transmit the data out serially via the USB cable. The app on the PC can store permanently on file the data for later use. After retrieving the data, you can update the program, then send the data back to the Prop for it to write the original settings to the eeprom. This way, you never lose the settings in the eeprom, and it is a simple process to retrieve any user data as well as reload the data after it gets wiped.

Can you do that, T Chap? Can you make an app that would show what the EEPROM contains?
That might be pretty handy.

T Chap · 2013-12-15 18:18

There is nothing to having the Prop read eeprom content and send it over USB. Xojo is an easy format to get a mac/pc/linux app up and running that would manage this. If you are speaking about the eepom content of the binary, that is easy to do already in the Prop Tool under show info.

Parallax Propeller I - EEPROM Constants

Comments