Lpc2000

> affect endurance cycles.  But writing value that is different 
> to the erased state does consume endurance cycles even if the 
> cell is already in the state that is being written into.  

Interesting. I'll make sure I do this.

> I would like to add -- be careful about using flash as 
> replacement for EEPROM.  It will work well for initial tests 
> but it fails in the field because EEPROM and FLASH 
> technologies have very difference endurance limits.
> 
> In this sense, as someone else said, the EE_Demo IMHO is an 
> example of perfect demo -- works only for the purpose it was 
> designed for but is of little or no use in real life otherwise.

I'll have to disagree here. Surely it depends very much on what you are
using the Flash-EEprom *for*; that is, how often you write to it ?
If you have user settable parameters that may be changed only a few
times in the lifetime of the product, I can't see a problem with using
Flash instead of EEprom on the endurance issue. It's still an
application you'd formerly have used EEprom (or equivalents) for.
Even for some system-state EEprom applications, you can often hold off
updating the non-volatile storage till just before imminent power loss
(or some really-long time interval as a just-in-case backup). These are
just examples of ways to cut down the write-times, and should be applied
to EEprom also.

> PS:  If flash can be used as EEPROM, manufactures will not 
> bother to have both flash *and* EEPROM embedded in the same SoC.

Also, look carefully....often EEprom quoted write endurance is similar
to what is quoted for Flash. The main advantage for EEprom is byte-only
write access, not endurance cycles at all.

Cheers,
Bruce