Propeller Programming Question
oscarstephens
Posts: 2
I am new to Propeller and have a question which has probably been answered in the past, and is buried in the forum base.
I've read the docos and understand the basic compile-download process. I understand program storage in RAM vs EEPROM, and loading from EEPROM at bootup time. I've also read the section in the Propeller Help where it says ....
... On the Propeller, the objects are created at compile time and are never created or destroyed at run time because the act of doing so would fragment memory and cause indeterministic behavior in real-time embedded systems. ...
However, what I would like to do is to make firmware updates "in the field" by downloading compiled object code over the RS232 port (rather than having to attach a Prop Plug), to be read by the currently executing program, and to have that program then store the new object code in the high 32 Kbytes of a 64KB EEPROM.
My plan is to have a default program always in the low 32KB of EEPROM to always bootup. It would then interrogate the high EEPROM pages to see if a new program is stored there, and then load that for running. Alternatively, it would be nice to be able to boot out of the low 32KB of EEPROM, or out of the high 32KB, but I don't see how to do that.
I would actually have preferred it if I could just store new program objects for execution on a "single" COG only, but the paragraph mentioned above appears to rule that out.
If someone could point me in the right direction on implementing something like this, or to a pertinent forum thread, that would be most helpful. Thanks.
I've read the docos and understand the basic compile-download process. I understand program storage in RAM vs EEPROM, and loading from EEPROM at bootup time. I've also read the section in the Propeller Help where it says ....
... On the Propeller, the objects are created at compile time and are never created or destroyed at run time because the act of doing so would fragment memory and cause indeterministic behavior in real-time embedded systems. ...
However, what I would like to do is to make firmware updates "in the field" by downloading compiled object code over the RS232 port (rather than having to attach a Prop Plug), to be read by the currently executing program, and to have that program then store the new object code in the high 32 Kbytes of a 64KB EEPROM.
My plan is to have a default program always in the low 32KB of EEPROM to always bootup. It would then interrogate the high EEPROM pages to see if a new program is stored there, and then load that for running. Alternatively, it would be nice to be able to boot out of the low 32KB of EEPROM, or out of the high 32KB, but I don't see how to do that.
I would actually have preferred it if I could just store new program objects for execution on a "single" COG only, but the paragraph mentioned above appears to rule that out.
If someone could point me in the right direction on implementing something like this, or to a pertinent forum thread, that would be most helpful. Thanks.
Comments
I seem to recall Parallax saying they want to write an Appnote about field upgrades this way, but I haven't seen anything yet.
Still, it's not too hard to do yourself. Mike Green has EEPROM code in OBEX.
Also, there is a Bootloader around that I believe can load code from the upper 32kB...
If you are open to using forth, propforth can do most of what you describe. Propforth can run a script at boot time, and the scripts are just text files in EEPROM. The programs can be up to the size of the EEPROM, and you can have as many EEPROM as you need.
The current version can load about 2000 lines into the interpreter in something like a minute (from an SD card, I don't have such a big EEPROM rig), after it interprets the program executes at full speed. Additional scripts can be run on the fly if needed, and routines can be "forgotten" from the dictionary on the fly as needed.
The next version will be out in a couple a weeks or so, and is much faster, and allows paged assembler routines.
BUT its in forth, not Spin, and not C.
There are similar programs on the forum and on the obex doing what you describe using a SD card and spin.
The lower 32k program loads the SD reader, and checks for appropriate file names (images), then it can load from upper memory, from SD or rewrite the upper memory using an image on the SD.
Quite close.. :-)
If you search for "loader" in the obex you'll find 3 pertinent objects, as a starting point.
Massimo