On Fri, 11 Dec 1998 02:02:12 -0500, you wrote:

>Hi Dave,
>
>At 10:52 PM 12/10/98 PST, you wrote:
>>Hum,
>>>Processor read/write access to program memory  !!!!!
>>
>>This will be very interesting to play with.  What does this mean,
>>exactly?  What will we be able to do with this?
>
>Your PIC will now be able to act like Win95/98 <G>, writing all over its
>own code as it runs! Actually, even though that would be possible and could
>make for some very interesting debugging sessions, I am of course very glad
>that Mchip has introduced this. It means, AFAIK, that your code will now be
>able to write to the program memory in the middle of execution, so a PIC
>could modify its own code at runtime. This has some great possiblities for
>speeding up algorithms (instead of having bunch of conditional statements,
>you might now be able to set up an extra area of memory, load it with code
>depending upon the conditions, and then jump to that code and run it. You
>will still probably be limited by the 10Million FLASH erase/write cycles or
>whatever reliability level they have it up to now). I DO hope that there
>are several security bits or some such that prevent writing to the code
>memory during brownout. I haven't read the datasheet on it yet. IIRC, there
>was only one EEPROM disable bit in previous PICs. I would think that more
>than one would be waranted in this case.
The REAL usefulness about CPU writeable flash as opposed to ISP
(assuming this is the case with this part) is that it greatly
increases the options for firmware updates in the field, as they can
use whatever interface is built into a particular product - modem,
infra-red, radio, memory card etc. AFAIK only Hitachi offered this in
the past. The main problem is where the code doing the programming
runs - in the Hitachi parts you had to put it in RAM and hope the
power didn't disappear during programming!