[Flashforth-devel] Pic18 change system protection addresses?

[craig b. <dab...@ya...>]

I've built one of our in-house tools around a PIC 18F46K22 and FlashForth 5.0 just because I think a smart user should be able to tweak their tool to do what they want it to do.  This actually hasn't worked out badly except that I'm now getting the occasional complaint that whenever they have to fully re-load the programs for whatever reason; they have to replace the calibration numbers that were stored in eeprom.  (They get re-initialized when declared as eeprom "value".)  I completely understand and agree with the design decisions that led to ram and eeprom "here" pointers only being reset by an "empty" and not by "forget", but I need a work-around of some sort for this problem.

My first and worst idea was to put all of the ram and eeprom allocations at the start (like cobol) and then just use "forget" with a marker after them.  The snag is that anything after that point that allocates memory other that flash will have to be separated out and moved to the top and the marker moved.  Messy, clumsy, and prone to error when trying to maintain.

The next thought was to still use the "empty" but start the load off by checking the eeprom "here" address to see whether the location was initialized or blank.  If blank, the eeprom values could be assigned and allocated normally.  If already initialized, the named could be re-established using a variant of "value" that just didn't store anything to the locations.  Once done with that the clean re-load could proceed normally.

What seems the best approach to me would be a word that could be invoked after the driver extensions and calibration allocations were loaded the first time that would update the default pointers to make them part of the base protected system.  A hex image could then be saved for programming a new chip and the old one could have as many reloads as it could stand without unnecessary re-calibration.

So, have I analyzed the problem correctly?  How many things would I need to chase down in the disassembly to change the system self-defense?  The final state of the pointers and where they get their power-up initializations from aren't obvious to me from reading the assembler code, but I know they have to be there.

Thanks for your time and any thoughts you might have on this matter,
Craig Bair, binary behaviorist