Предложете начин за подигуряване на записаните данни (вграден ееп на пик16Ф) , актуализират се примерно 48 пъти на денонощие.
По хардуерна причина пазенето в рам и записа при отпадане на захранването не е изпълним ( за сега). Смятам да дублирам данните няколко пъти (3 или 4) , да проверявам за съвпадение и отделно да пазя чексума за всеки запис , при настъпване на събитие се ъпдейтва записа и чексумата , да правя проверка след това, чексумите ще ги пиша в такава последователност че да мога чрез тях да знам не само кой запис е безгрешен но и кой е последен .Мога да добава байт сочещ адреса , и при грешка да премествам данните за да удължа живота на паметта ..
Дали не е разумно да пазя данните дублирани и отделно при невъзможност за правилен запис да ги местя на друг адрес ?

Едва ли и година ще изкара с такова темпо на писане.

По спецификация на епрома му дават 1млн. цикъла на запис ,което при твоя темп значи 50години. Грешките идват по-скоро от недобра процедура за запис, а не от развалени клетки. Не ми се вярва Микрочип да са писали даташита наизуст защото хич не е трудно да се провери реално. Например ако правиш запис всяка секунда, лимита от 1млн. се изчерпва за 11.5дена. Може и сам да си направиш такъв тест да видиш колко ще ти изкара конкретния епром.

Абе, вярно че 1 000 000 цикъла пише, аз защо бях останал с убеждението, че са 10 000?!?

10'000 беше за Флаш паметта, даже по едно време и само 1000 беше, но сега гледам пишат 100'000. Само да не стане като ватовете на китайските тонколонки. Ако е толкова критично приложението ,нищо не струва да се жертва един чип с реален тест.
Иначе проблема с чексумата е ,че ще се обновява още по-често и ще изгори първа, затова трябва да се пази в рам и да се записва по-нарядко.

Мога да пазя това което се променя често в заделени адреси за и при грешка да го местя и отделно да си пазя дублирана последната сигурна стойност за да я променям доста по-рядко ( или само при достигане на определена стойност и/или настъпване на определено събитие) ?

Имах проект в който трябваше често да се съхраняват данни в EEPROM-a. Направих си опитна постановка и тестова програма която записваше различни числа в една и съща клетка като всеки път се проверяваше коректността на записа. Процесора изкара 2 500 000 цикъла на презапис без проблем опитите ги прекратих. Микрочип има апликейшъни за това, като тези презаписи 1 000 000 са за захранващо напрежение 5 волта. Ако процесора работи на по-ниско захранване циклите на презапис се увеличават.

Проекта все още не е реализиран до край така, че не мога да кажа дали това ще е валидно за повече от два процесора с които съм пробвал тестовата установка. Процесорите за проба бяха ПИК 12Ф675

При чест запис в една клетка тези клетки в които не се записва трябва да се рефрешнат на определен брой цикли
(http://mientki.ruhosting.nl/data_www/pi ... blems.html), аз пусках пробен запис през 10 мс ( без да отчитам времето нужно за еепрома) и го циклих това към час без да даде грешка , смятам да си остана с просто дублиране на записа + чексуми и писане ама на по-нарядко. Е ще трябва да му мисля на кое от всичките да вярвам когато се окажат различни ...
Та оказва се че клетките в които се пише често не са толко проблем , проблема е в останалите ако там се пазят важни константи , аз имам такива но при първото стартиране пика ще ги копира на флаша си , след това ще сетне един флаг и чексумата на еепрома.

Правих с подобни съображения следното: EEprom-a примерно го бях разделил на 8 дяла . Клетка която е извън тези 8 дяла , помни кой дял е актуален.
След всеки ресет , чета последния дял , пиша го в следващия и увеличавам "Клетка N-дял" . Ако се прецака нещо-се връщаш на предишния дял.

И един полезен съвет, който и друг път съм го давал . След всяко писане или четене записвай в EEADR адрес който никога няма да ползваш - дано да не ти трябва целия . Проблема (както се описва по разни форуми на Microchip) е, че при отпадане на захранването, се случвало чипа да скочи на частта дето пише в еепрома и да ти запише нещо незнайно. Този проблем може да се отстрани и с BOR, ама не е излишно. Аз имах точно такъв проблем и направо бях полудял - след дълго ровене по форумите го намерих това, направих го и оттогава не съм имал такива случаи.

Да запознат съм с този проблем началните адреси ми се освобождават след първият пуск на устройството ,отделно и бор ми е включен ( пак поради хардуерна особенност има ситуация при която ПОР не сработва , кученцето за сега е офф , кода е доста чистичък и праволинеен тане очаквам да джафка псето ).

Интересен проблем имаш, първо не да те отчайвам но да занеш, случайността е голямо нещо, точно в таква ситуация с 3 записа и чексума, се казва че и записите и чексумата излизат, но това не е регулярен запис защото и самата процедура се логва преди д започне и като свърши а лог няма, та случайността е голяма работа, това обаче с просто crc.

Иначе това е сравнително надежден, да не кажа много надежен начин, това което ти казвам се случи, но веднъж от над 200 хил проддени изделия за период от над 8 години, може да е имало и други но не се е разбирало.

Сега може би имаш някаква причина, ама що не позлваш външен епром, и най-вече защо не пробваш fram, ако търсиш надеждност, мисли за външни памети, дали фрам, дали батерийно резервиран рам . нещо такова.

зависи - ако пишеш на различни адреси ще живее повече

Може така:
Правиш 2 еднакви области в EEPROM, където да се пишат данните. Отделно един указател, който помни областта с валидни данни. Проверяваш указателя и пишеш в другата област. Проверяваш данните и ако са ОК, променяш указателя. И накрая пишеш 0х00 в някоя клетка за защита от случайна промяна.

relsys , точно за това говорех редувам записите и си пазя за всеки случай чексум , дори при скапване на указателя по чексумата мога да хвана правилната стойност и/или да имам предишната сигурна стойност, при липса на проблем запсисите ще съвпадат. За да намаля циклите ще пиша само при определени условия. Може да се помъча да ползвам сигнал от периферно успройство ( или просто да добавя едно МЦП120 към РБ.0), жалко че bor не може да се сетне като прекъсване) за да засичам отпадане за тока и ако има текуща промяна в данните да ги пиша ( на друг адрес.Хубавото е че спиране на тока е малко вероятно.Хардуера за сега няма да се пипа иначе бекъп захранване или добавяне на фрам си е стабилното решение.