On Thu, 9 Mar 2000 16:27:40 -0500 "M. Adam Davis" <adavis@UBASICS.COM>
writes:
> Actually, I was even thinking of a more complex program which would
> 'save' the
> flash, so to speak.
>
> The flash is limited by how many times it can be erased/written, so
> if my app
> only takes 2k of code, the first version goes in the first 2k.  If I
> revise it,
> rather than overwriting the first 2k, it will assemble and write it
> for the
> second 2k.  The only location that would need to be reprogramed
> every time is
> the jump to user code, which can be ameliorated by a series of nops
> followed by
> the jump.  Just overwrite closer and closer nops, and when you run
> out,
> overwrite all the jumps with nops and start again.  This requires
> the program
> writing to the chip to know where the old code is, and then assemble
> (or
> reassemble?) the code just before programming it.

Nice  concept!

> This would lend naturally to your bad download situation, since the
> original
> code is not overwritten.  The last location programmed is the jump
> to user code,
> and only after a correct verify.  Of course, if your code takes up
> the entire
> flash, then all bets are off... ;-)
>
> This would be important for products which write to the flash
> frequently, for
> whatever reason.  Chances are the casual hobbyist won't run into a
> bad code
> location even if they reprogrammed their entire flash every week.
> It would
> still take several years for them to wear it down.  A data-logger
> which uses the
> internal flash for storage should follow such a scheme though.

I did it to an 16f84-10/p!

> TI uses a similar approach on their TI-89 and TI-92+ calculators
> with FLASH.
> When a program or code is copied from flash to working memory,
> changed, then
> copied back to flash it doesn't overwrite the old location, it finds
> the first
> non-used location and writes it there.  The old location is marked
> used-but
> empty.  When there aren't enough non-used locations, it performs a
> 'garbage
> collection' which re-allocates some of the flash, and marks
> everything empty as
> non-used.

Cool!

> -Adam
>
> "Quitt, Walter" wrote:
> >
> > I've done this with other RTUs (Remote Terminal Units.)
> > It can get a bit tricky loading and running code on units
> > with different configurations.  You must allow for bad
> > downloads and allow the old code to run again.  It can get
> > tricky.  Utility customers get real pissed if a substation
> > goes down because of a software screw up.
> >
> > GL,
> > Walt...
> >
> > -----Original Message-----
> > From: M. Adam Davis [mailto:adavis@UBASICS.COM]
> > An even nicer advantage is being able to update the code remotely.
Andrew
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.