PropForth --- HOWTO write an image to a 64K EEPROM and reboot

LoopyByteloose

I think the title pretty much explains what I need. I have a Propeller Demo Board with V. 5.03 installed and want to know how to retain an image after I have modified the dictionary. Is this at all possible? Or do I need to create a .f file in a text editor and find another way to migrate that into the original image?

mindrobots

saveforth - copies the running image to the lower 32k leaving the upper 32k intact if it exists. This is used for development and EEProm version of kernel.

The SD kernel is expected to rebuild itself from the .f files you place out on EEPROM. boot.f can be modified to chain .f files together if/as needed. Saveforth if used with the current release has usually corrupted the SD kernel when I try it (or forget what it does).

LoopyByteloose

In other words. just use "saveforth' without any parameters and press reset to use new image, right?

I am actually thinking I should upgrade a Propeller Demo Board to a larger EEPROM just to take advantage of this.

mindrobots

Correct. saveforth copies the running image to the lower 32k of EEPROM. Any prop board with EEPROM should support this function and save a modified kernel to EEPROM. When you reset after the saveforth, you should be running your modified image. The EEPROM above 32k, if it exists, is usable as an EEPROM file system with the proper kernel loaded or with the EEPROM extensions added.

prof_braino

NOTE: saveforth takes the current dictionary, and write the image to the lower 32k eeprom. If you redefined any words, it only takes the most recent definition (the only one visible) and so "cleans" the dictionary.

saveforth only words with the regular propforthxxxdevkernel.spin images.

IF you are using the EEPROM or SD kernels, saveforth is not included as it doesn't (isn't supposed to) work. Because saveforth rewrites the dictionary, that would squash all the optimizations for EEPROM or SD, and wont boot. FOR THESE kernels, you just boot the kernel, and autoload your source as a script from EEPROM or SD. This way, we NEVER have to mod the kernel image, and risk bricking the device.

Of course if you did "brick" the device, all you have to do is to reconnect to your pc, and reload the kernel from spin via the proptool. The concern is for those installations where once the prop is installed, it can never be accessed again, like up on that mountain, inside the welded frame of the bot, or (eventually maybe) up on that satellite.

caskaz

Hi.
I used "saveforth" on my application(#170 in "Propforth 5.0 is available for download").
http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download/page9

Plese refer last lines inside DPM_6_main.f.

: onreset0 onreset DogPulseMonitor ;
: onreset1 onreset sigma_delta ;
: onreset2 onreset disp_sw ;
saveforth
reboot

prof_braino

caskaz's example demonstrates one technique for making a cog launch (an application) word on reset (also power up) automagicly.

onresetX where X is the cog number is called when the cog is reset (go figure)

saveforth uses the last definition, so the dictionary image that is written for onreset is the one you just defined, and the old one is no longer present in the dictionary.

You can you the command line or other constructs in other definitions to launch other words in a given cog, for example

: LaunchXinCong3 c" X " 3 cogx ;

called from the command line or any word would run function X in cog 3.

Power cycle or reset or reboot would again call the onreset word.

LoopyByteloose

Well it is working very nicely, but I was now thinking of adding larger EEPROMs, say 128K. Is there a limit to how much 'saveforth' will save?

You might include a paragraph about 'saveforth' early on in the html that you have created. I was thinking that I had to do something with all the lower level eeprom words. New users want to know about this right away, not have it hard to find.

And, am I right that using 'forget' after a 'saveforth' will allow one to revert to any earlier dictionary state?

mindrobots

Loopy,

Currently, saveforth save the 32k byes of Hub RAM into the lower 32k of EEPROM to create a bootable version of the kernel. As the professor mentioned, it will trim words and just take the latest (active) version of a word, in effect compressing any "development" versions of your words or any kernel/system words you redefined out. This will make your kernel smaller, which could be a good thing as you continue to develop your application.

You could add your own version of saveforth that would use whatever 32k block of EEPROM you specified to save the kernel but then you would need a way to copy that block to the first block so it would find the correct copy in reset. I've been meaning to something like this for a couple different reasons. One thing this would allow is multiple kernel versions in EEPROM.

I agree with you about the documentation. At some point, I intend to write tutorials and a user guide....as time permits and PropForth hopefully stabalizes with version 5.3?

Forget is very powerful and can be dangerous. It will forget everything from the word you specify forward in time to the end of the dictionary. If you define a new word called loopy and then define 20 more words after that, when you say "forget loopy", everything you defined from loopy inward will be GONE!! Be careful. If you say "forget forget" it will forget everything in the dictionary from where forget was define until the last word you defined....OOPS!! It kind of let's you revert like you said but not as if there are multiple versions in EEPROM created by saveforth. Only an earlier state of the dictionary in Hub RAM.

If you mess up the dictionary in Hub RAM, you reset to go back to the last dictionary you saved with saveforth. If you have done a saveforth on a bad dictionary, you reload from protocol and start rebuilding with your .f files.

Hope this helps.

Questions like this from a new user help me a lot with material for tutorials and the user guide.

prof_braino

Loopy Byteloose wrote: »

And, am I right that using 'forget' after a 'saveforth' will allow one to revert to any earlier dictionary state?

NO.

forget ThisWord

will forget all the dictionary back to and including ThisWord

You have to reboot to reload from EEPROM if you forget part of the dictionary you still need. Forget is very powerful and wickedly dangerous. IF you do something goofy like

forget <some-word-in-the-middle-of-the-kernel>

and then manage to do a saveforth, you will pretty much trash your image. Then you get to reload the kernel using spin.

What is typicallay done is:
Whenyou start a new development section, define

: MyStub ;

Then do all your development. When you find something you saved to the dictionary is incorrect and you want to remove it, type

forget MyStub

and this clears the dictionary back to your starting point.

Another way to get this done is to save your source to EEPROM or SD (using the EEPROM or SD kernels). When the prop boots, it can be made to auto load your "known good" files from source. Then you can develop on just the new parts, without having to manually reload twenty source files. And you know you always start with a clean kernel.

LoopyByteloose

Okay, I'll try to summarize and review.

My first impression with PropForth was that having the 64K EEPROM might allow me to store bigger dictionaries as I developed my own words. But now I realize that the fundamental architecture of the Propeller is to load a 32K image and never anything more.

So the extra 32K of EEPROM is not available for dictionary expansion - at least at this point. (Still, some of you have mentioned dreams of placing 32k images on higher locations in EEPROM and retrieving them in a multiple stored image model).

That leaves me with the remaining EEPROM capacity being available for data recording and retrieval, with some potential uses for applications that need to retrieve lots of data, such as audio output or sophisticated graphic display.

In other words, the PropForth dictionary, kernel, and all remain within a 32K boundary. And the implications are that if one grows larger than that, they need to discard unused words or features.

So the advantages of upgrading an EEPROM on a Propeller Demo Board - at this point in time - are only to the added data storage and retrieval, not to expanding the PropForth language to a larger footprint.

AND since 'saveforth' actually removes the older duplicates of words entered into a dictionary, the use of 'forget' will NOT always revert to an earlier state as these older duplicates no longer exist. In other words, one might have to just start over with a fresh downloaded image. So there needs to be some planning to save images elsewhere - EEPROM cannot be entirely relied upon to retain work in progress.

prof_braino

Loopy Byteloose wrote: »

summarize and review.

My first impression with PropForth was that having the 64K EEPROM might allow me to store bigger dictionaries as I developed my own words. But now I realize that the fundamental architecture of the Propeller is to load a 32K image and never anything more.

True - Prop can only ever hold 32K in RAM, and the propforth dictionary being in RAM adheres to this limit at any given time for speed. BUT there is a very nifty way around this, which allows programs and applications of unlimited size.

So the extra 32K of EEPROM is not available for dictionary expansion - at least at this point. (Still, some of you have mentioned dreams of placing 32k images on higher locations in EEPROM and retrieving them in a multiple stored image model). That leaves me with the remaining EEPROM capacity being available for data recording and retrieval, with some potential uses for applications that need to retrieve lots of data, such as audio output or sophisticated graphic display.

In other words, the PropForth dictionary, kernel, and all remain within a 32K boundary. And the implications are that if one grows larger than that, they need to discard unused words or features.

So the advantages of upgrading an EEPROM on a Propeller Demo Board - at this point in time - are only to the added data storage and retrieval, not to expanding the PropForth language to a larger footprint.

Correct, to the extent that the dictionary can physically only hold a max of 32k at any given time.

AND since 'saveforth' actually removes the older duplicates of words entered into a dictionary, the use of 'forget' will NOT always revert to an earlier state as these older duplicates no longer exist. In other words, one might have to just start over with a fresh downloaded image. So there needs to be some planning to save images elsewhere - EEPROM cannot be entirely relied upon to retain work in progress.

Here's the deal - The design decision is that we are an embedded system, NOT a general workstation OS. SO there is to be ONLY ONE "correct" firmware for a given application on a given hunk of hardware. (which can be argued to be true if proper design is applied)

THAT BEING SAID: the "correct" firmware CAN have the ability to load different sets of EXTENSIONS per the situation at hand.

This is the what the PAGED ASSEMBLER function, and the LOAD FROM SOURCE SCRIPT + "forget" come into play. You have at least two options for loading modules into your as-booted firmware, which can be unloaded (actually just overwritten) under program control.

So the model is, set up you firmware so that is is in your "known good" state at boot, and load whatever extension you want, do its act, then load the next one.

All the fun of an OS with no OS!

OK, its a little more effort on our part, but that's the fun.

The paged assembler loads small chunk of precompiled assembler into a buffer, it does its act, then returns its values, points, buffers etc. It remains in the buffer in case you call it agian, and stays until you overwrite the buffer with a next call.