> But doesn't this mean you're using something which has 1/10th of
> the endurance (10k/100k vs. 100k/1M)?  And does program
> memory suffer the same "rewrite of something degrades the rest"
> problem of data EEPROM?

Hmmm, good question. I'm guessing NOR-based, but Microchip
may use something completely different

From

http://www.linuxdevices.com/articles/AT4422361427.html

"Maximize media lifespan -- When some blocks of memory contain
fixed content, such as binary code, the remaining blocks will experience
increased demand for erase and write operations, leading to earlier
failure. Wear-leveling algorithms can prevent overuse of memory blocks
and prevent a "stalemate" scenario in which a small region of memory
becomes locked in a pattern of repeated writing and compaction. Wear
leveling software can monitor block usage to identify high-use areas and
low-use areas containing static data, then swap the static data into the
high use areas. It can also balance write operations across all available
blocks by choosing the optimal location for each write operation"

>  Surely if it does, you're better using
> EEPROM since it has ten times the endurance to start with?  (OK,
> I'll stop calling you Shirley! :-)

"Joey, do you like gladiator movies ?"

Well, Betty, I think the point being made was to store static or
infrequently-written data outside of EEPROM so that it doesn't
get corrupted by all the other EEPROM writing. 

"The typical case where you do have a problem is where some
EEPROM locations are quite static and seldom written, while others
are actively written. A primary example of this is where configuration
or calibration data is stored in part of the EEPROM and logged
data in the rest. In this case you would have to perform a periodic
refresh of the configuration/calibration data (before doing 1M writes
to the logging data area)"

However you use EEPROM, it behooves you to know how each
location will be used and affected

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist