> I know the official figure from Microchip for the "A" version > 16F84 is >1,000,000 cycles, but I am writing to the eeprom > only ONCE per MINUTE. Will this extend the number of cycles > expected? No. It will extend the lifetime as expected. When you write once a minute your product will last 60 times as long as when you would write every second, for example. > Also the product is only powered up about 2 to 6 hours per week > expected, again will this raise the number of cycles? No. It will raise the lifetime by a factor of 28 (7*24 hours / 6 hours). > I am currently looking at spreading the workload between a number > of eeprom locations, the normal solution. My system writes once > per minute (as stated above) until a location has been written > 256 times, then uses the next location, (8 locations in total). > Again, will this extend the cycles over 1,000,000 as they are > given a long "break" between being written. It will spread the wear over the 8 locations, giving you 8 times as many writes before an expected failure. The max cycles per cell remain the same though. In total, your proposals will result in a lifetime of a few hundred years, or 15 years if your product is powered continously (not just 6 hours a week). Beware of dangerous situations, such as for example a watchdog failure. If your product remembers the location counter in SRAM, and the watchdog has a timeout of 1 second, your product might enter an endless loop in which it writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then resets, and then writes the first eeprom cell of the array, and then.. This will result in a lifetime of 11 days. :-) -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu