programming a program that allows for updates

grasshopper

My question is how would I design my firmware in the propeller to be updated? Do I need to create arrays that themselves are arrays? Any ideas will be appreciated.
I am speaking about “code structure” not actually getting updates off of the web. Currently I have a way to store data from a text file, this makes it somewhat dynamic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit my site -> [url=Http://www.rawcircuits.com]www.rawcircuits.com[/url]

mctrivia

you need to write some code into your code that rewrites the apropriate code in the eeprom. check out my id object in the obex it rewrites the top 32bytes of eeprom to add in an id number. if you rewrote the entire eeprom on next boot your code would be new.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.

Mike Green

A lot depends on just what has to be updated. If you're going to replace your actual program rather than update some tables or variables in the program, the simplest scheme is to use a 64K byte EEPROM and have a routine in your program that reads a block of information into the 2nd 32K of the EEPROM. Once that block is read correctly and any checksums or other checks are ok, then that 32K gets copied over the existing 1st 32K of the EEPROM where the "old version" of your program is stored and your program does a REBOOT which essentially restarts the Propeller with the new program.

Have a look at the YBOX2 software which can download different application programs via the Internet.

Mike Green

The Propeller can't realistically do the same kind of updating that something like Windows or Linux or the MacOS can do. That sort of thing takes a lot of resources. Its not like the Propeller has a couple of megabytes of main memory and a couple of hundred megabytes or a few gigabytes of attached storage to spare. The Prop2 ought to be able to do it with an SD card or large flash memory module attached, but I don't think it will come that way and whatever software is in ROM will not include that ability.

rjo_

mctrivia,

I was recently looking for something like your object and simply didn't see it.

There it is!!!: http://obex.parallax.com/objects/410/

Grasshopper,

I'm not sure I completely understand your question. So, I'll just paraphrase mctrivia... to flesh it out his comments a little and if I'm wrong... then I need to be corrected.

You could write an EEPROM loader into your application code, which has one feature: to take an update from an SD card and load it into the EEPROM. This could look a lot like a stripped down version of PropDos... with no menu structures, no instructions, and no keyboard... all you would need is a button, which would trigger the event. And it would also look a lot like Chip's PropLoader. Right now both PropDos and PropLoader load files to HUB RAM. But with a few hints from mctrivia's ID object, and the "read" functions built into the SD demo routines, you should be off to the races.

If you put your result into the OBEX, I would predict that it will jump to the top 20 downloads in no time.


Rich

Mike Green

A number of different people have suggested this scheme at various times.

heater

Be careful. Programs that download new copies of themselves and then overwrite themselves invariably go wrong more often than you might think. Leaving you with a system that is unusable and can no longer download good code. This now needs a normal Prop tool set up to remedy which can be a pain if your system is at a remote location.

I've had the misfortune to work on a number of projects that employed this kind of thing for updating embedded code and it always led to problems. Even in the "sophisticated" world of avionics systems.

Seems to me it's best to have a bootloader program in your EEPROM that is never changed. Have that load application from SD card or high end of EEPROM on reset. Have it do updates to SD card or high end of EEPROM and do something to verify the update is valid. Best use SD card and use the space to keep the old app version as a fallback when the new app version download is screwed.

Now if the Prop you are updating is at a remote location you have to be even more careful. Perhaps the update is valid but for some reason it no longer communicates back to base. How do you get it to reboot and switch back to the old working code ?

Well here we might want to have the bootloader run in a dedicated COG as PASM with minimal communication back to base. The application would be loaded from SD card and started from the bootloader. The app would not use the bootloader COG so that COG could still get commands form base to reload a previous version.

How complex do you want this to be?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.