'PIC to change Code as it runs? Endurance issues.'
"M. Adam Davis" wrote:
> FLASH memory is EEPROM memory (ie, electrically erasable), except instead of
> erasing each bit (byte, word) seperately/sequentially, you can 'flash' the
> entire memory at once. This takes longer than a single bit/byte/word erase, but
> much less time than doing a sequantial erase.
It would be nice if the MPLAB ICD driver was smart enough to
erase/program ONLY the bytes that have changed rather than
erasing and reprogramming EVERY word EVERY time (as it currently
does if you don't 'erase' the part each time you program it (which
wastes cycle life).
It is a LOT quicker to read a byte and test for change than it
is to rewrite the exact -same- data and waste 10msec.
> This is referred to a bulk erasing in microchip's literature. The new PICs can
> read and write directly to their own program area, but they cannot perform a
> bulk erase (flash) on themselves. While this would make sense (where
> program go now that it's erased itself) it would be nice to have for secure data
A very good idea, actually. Tamper resistance made easy.
Of course this also raises the risk of self distruct by accident
but I can live with that. Enter the wrong password three times
and 10msec later your code IS secure... forever.
Perhaps a bit exists in an 'undocumented' register.
> It is possible to write self-modifying code with these PICs.
There are those who would suggest that self modifying code is
a bad thing. Is it?
> Alas, like eeprom memory, there is a limited life span, often expressed in how
> many times it can be written to before experiencing a bit error (usually greater
> than 10 million).
That number only applies to the 'high endurance' serial EEPROMS.
The spec for the 16F87x series is -ONLY- 1000 cycles for the
flash ROM and 100k for the 'data' EEPROM.
(page 162 of DS30392A.pdf)
1000 cycles isn't a whole lot if you're doing a lot of development
work in a complex embedded system. Clearly one should rotate
one's parts through the development station if you want to
> Ian Wilkinson wrote:
> > I've just been reading the documentation on the 16C877, does the part where
> > it says the PIC can write to the Flash mean that you could get the PIC to
> > write a data into the flash and then run what the PIC had written as if it
> > had been programmed in the first place??
Yes. The Microchip ICD kit supports easy firmware upgrades if you change
the supplied part to a 16F876.
> > And while I'm on the subject can someone explain the difference between
> > Flash and EEPROM as I can see very little difference (It's been two years
> > since I've done anything with memory :)
-----BEGIN PGP SIGNED MESSAGE-----
>> It is possible to write self-modifying code with these PICs.
>There are those who would suggest that self modifying code is
>a bad thing. Is it?
Only if done badly :)
There's a bunch of banking terminals out there that use it.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
-----END PGP SIGNATURE-----
|Robert Rolf <MITVMA.MIT.EDU> wrote: PICLIST
> There are those who would suggest that self modifying code is
> a bad thing. Is it?
Self-modifying code isn't always a bad thing... But like most other
programming techniques, neither is it always a good thing.
It's usually used in order to speed the operation of a program. For
instance, if you're working with a microprocessor whose literal-
addressing instructions execute faster than its direct register-
addressing instructions, a self-modifying program can be used to pre-
read register contents and plug those numbers into literal-addressing
instructions. This sort of thing used to be done all the time in,
for example, high-speed graphics routines for simple desktop
For an example that applies to PICs, there was a recent thread here
that began with a guy asking whether he could do "BTFSC REG,BIT",
where "BIT" was a register containing a number from 0 to 7. Without
self-modifying code, that sort of thing is a pain; with it, it's
trivially easy... And if you need a BTFSC sometimes and a BTFSS other
times, you can do that, too.
The benefits of self-modifying code are lessened, somewhat, when it
takes a long time to perform the modification (as it does on the
PICs, with their slow EEPROM-write cycles), but I'm sure there are
still applications where the technique is useful.
=== Andrew Warren - ix.netcom.comfastfwd
=== Fast Forward Engineering - San Diego, California
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...