Есть значение, которое очень важно для функционирования всего прибора.
Оно хранится в EEPROM и может иногда изменятся (калибровочный коэфф.). Необходимо при старте определить их правильность.
Конечно, самое простое это записать его несколько раз в EEPROM, потом, считав данные методом сравнения определить, что данные правильны. Например, 2 из 3 совпали.
Интересует, есть ли более элегантные способы хранения данных, которые на 99.9999% гарантируют их целостность?

А Вы себе представляете, что может их испортить и как?
То есть, если нет модели ошибок, как можно говорить о защите от них?

To Pat - применимы все методы контроля, используемые при передаче по каналу связи (бит паритета, CRC и т.п.).
Есть и корректирующие коды (исправляюшие n-кратную ошибку) - вот тут хорошо бы знать модель ошибок.

Я, конечно, извиняюсь, ибо в этой области я серый, как штаны пожарника.
Наверное, я сильно переживаю за данные в EEPROM, так как там модель ошибки очень случайная. Просто в народе бытует мнение о том, что данные в EEPROM могут иногда повреждаться. Многие причины этого повреждения известны и они учтены в самой конструкции и софте, но все равно хочется сделать некоторую избыточность так на всякий случай. А случаи как говорится разные бывают .

Это все понятно (относительно EEPROM и ошибки, а не штанов пожарника ) .
Исходя из этого и был мой совет. Если не хотите лезть в книжки по системам связи, то возьмите самый известный CRC16 (используемый, например, в протоколе ModBus), посчитайте циклический код над байтами калибровочного коэфф-та и используйте его в Вашей операции сравнения. Этот подход оправдывается в тех случаях, когда калибровочные коэфф-ты занимают достаточно большую область памяти. Если же коэфф-т занимает 1-2 байта, то более целесообразен Ваш первоначальный алгоритм.
Тут на местном ftp - книжка старинная есть. Уильямс "Отладка микропроцессорных систем" 1988 г. Там, в частности, должен и этот вопрос рассматриваться.

Сама уже заглянула в книгу - там только предлагается расчет контрольной суммы области памяти, запись байта контрольной суммы и сравнение его с рассчитанным в программе. Контрольная сумма в книге - это сумма всех байт области без учета переполнения.

Использование CRC16 - все точно также, но алгоритм вычисления контрольной суммы (CRC16) чуть-чуть посложнее. Если что, свистните , выложу исходник на Си.

Спасибо вы правы пойду по первому пути.

Еще присоветую. Так как ошибка в коде может потереть кусок памяти одинаковым значением, или же микросхема может быть повреждена, троирование здесь может не помочь.

Запишите коэффициент через некоторые интервалы, которые будут заполнены сторожевым значением 0xDADA...DA<val>DA...DA<val>DA..DA<val>DA..DA и после этого наложите и запишите после этого CRC.

Еще вариант: записать само значение и его инверсию. Минимум накладных расходов.

Также, если в EEPROM достаточно свободного места, можно организовать что-то типа отказоустойчивой системы с транзакциями : кольцевой буфер, в "голову" которого пишется пакетик данных, затирая "хвост". Преимущество: если последняя "транзакция" не удалась (например, питание ушло), можно вернуться к предыдущему значению (если это калибровочный коэффициент, то он обычно между калибровками уплывает ненамного, и со старым его значением прибор будет хоть как-то работать).

данные в EEPROM типа 93Cxx действительно могут быть испорчены, если в момент записи пропадет питание, или на ноге CS будет активность (при сбросе процессора), при чтении - все ok
я делаю так:
в EEPROM записываю дополнительно два счетчика.
каждая запись состоит из следующих этапов:
1. считать, инкрементировать и записать счетчик 1.
2. записать данные
3. считать, инкрементировать и записать счетчик 2.
если значение счетчиков FF, то оно меняется на 01 (т.е. 00 и FF - запрещенные значения)

при считывании сравниваю счетчики

преимущества: не надо считывать всю информащию и рассчитывать контрольную сумму или СRC
недостатки: работает, если данные портятся только в момент записи.

Самый тривиальный алгоритм подсчета контрольной суммы CRC16:



Последний элемент массива - значение CRC16 массива при проверке (возвращается 0 при правильной CRC16), 0 - при подсчете. Оптимизируйте при необходимости - я написал в свое время за 15 минут, совершенно не думая о производительности.

записывай на бумажку)))