Shop OBEX P1 Docs P2 Docs Learn Events
Multiple programs. — Parallax Forums

Multiple programs.

FORDFORD Posts: 221
edited 2006-03-14 03:32 in Propeller 1
Hello All,

Assuming I am going to·use a 128Kb Eeprom, with the lower 32Kb for the Prop, and I have loaded my program into the Propeller,

Will it be possible to copy a new program (or·part of a program) from higher (above 32Kb)·in memory into the program space without crashing it ?
Or to copy new / different objects into the program space from higher in memory ?

I guess I am also asking is it possible to know the start and end address of each object in memory so that it can be done ?

If so, this would be extremely flexible with optional programs, language sets etc.
Cheers,
Chris
West Oz.

Comments

  • Guenther DaubachGuenther Daubach Posts: 1,321
    edited 2006-03-13 08:00
    Chris,

    as the Propeller releases the I²C bus lines to the EEPROM after copying the lower 32Kb from the EEPROM to the RAM, you can access other (higher) parts of the EEPROM later by your own I²C routines. One brute-force method would be copying a higher 32Kb block into the lower 32kB block of the EEPROM, and then issue a reset. This causes the Propeller to read the new contents of the lower 32Kb block into RAM, and run this modified application.

    Another way would be to read certain blocks of upper memory from the EEPROM, and writing them directly to areas in the RAM. There is no need to reset the Propeller in this case but you need precise information about what is stored where in the RAM. I'm pretty sure that it is possble to retrieve such information at run-time but it is up to the "Propeller Gurus" to tell us more about it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Greetings from Germany,

    Günther
  • FORDFORD Posts: 221
    edited 2006-03-13 08:13
    Thank you Guenther,

    I should have thought of that, I was thinking that the program would crash, but of course it won't, as it is running from RAM, until it is reloaded on reset.

    Well that is a fantastic way to just have say 4 different programs on an extra 128Kb Eeprom, and just load the correct program when required.

    Thanks again,
    I should have thought more deeply about that.

    Cheers,
    Chris
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-03-13 09:36
    If you work in Assembly it should be much easier as you would have full control of the memory.
    (You need a small Spin program to kick-start the Assembly routines, but after that you can recover that bit of RAM.)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • FORDFORD Posts: 221
    edited 2006-03-13 09:37
    Hey Gadgetman,

    Are you saying that I can't read / write any location in the Eeprom using Spin ?



    Thanks,

    Chris
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-03-13 11:22
    Yes, you can read/write the EEPROM with Spin.

    But if your program is completely in Assembler, you can use the entire HUB RAM as you see fit.
    no worry about overwriting programs accidentally or any of that.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-03-13 15:39
    To restate what Gadgetman has said, assembly routines when executed fit entirely inside of the memory in a cog (processor), it is not dependent upon contents inside the hub (central) memory. Spin routines have the interpretor in the cog's memory and keep the code that is run in the hub memory. So a spin program couldn't reload the entire 32K of hub memory from the EEPROM because it would be writing over its own code in the process.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
  • FORDFORD Posts: 221
    edited 2006-03-13 23:41
    Thanks Guys,

    I sort of see what you mean... well not really.

    I think when the documentation is released it will help, and I will rethink it all then.'

    Start at the Start - if you know what I mean.

    Thanks,
    Chris
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-03-14 03:32
    OK let me draw an analogy to the stamp, the stamp has two main parts: the interpretor on the microcontroller and an EEPROM to hold user programs. Now the interpretor has the capability to aquire a new user program and write it to the EEPROM, the entire contents of it with no difficulty. Now say you wrote a PBASIC program that tried to do the same thing, you would read the new program in and start writing it to the EEPROM, there would come a point where you would begin to overwrite the locations in the EEPROM that is actually performing the very function of loading the EEPROM, at this point your program goes haywire because the instructions performing the loading no longer exist because they have been overwritten with other instructions. Hence it can't be done. The same thing would happen in spin, at some point the instructions overwriting would over write themselves. Does this make more sense now?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·1+1=10
Sign In or Register to comment.