Есть значение, которое очень важно для функционирования всего прибора.
Оно хранится в EEPROM и может иногда изменятся (калибровочный коэфф.). Необходимо при старте определить их правильность.
Конечно, самое простое это записать его несколько раз в EEPROM, потом, считав данные методом сравнения определить, что данные правильны. Например, 2 из 3 совпали.
Интересует, есть ли более элегантные способы хранения данных, которые на 99.9999% гарантируют их целостность?
Полная версия этой страницы: Определение целосности данных
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
А Вы себе представляете, что может их испортить и как?
То есть, если нет модели ошибок, как можно говорить о защите от них?
То есть, если нет модели ошибок, как можно говорить о защите от них?
To Pat - применимы все методы контроля, используемые при передаче по каналу связи (бит паритета, CRC и т.п.).
Есть и корректирующие коды (исправляюшие n-кратную ошибку) - вот тут хорошо бы знать модель ошибок.
Есть и корректирующие коды (исправляюшие n-кратную ошибку) - вот тут хорошо бы знать модель ошибок.
Цитата(Vic1 @ Oct 30 2005, 12:07)
To Pat - применимы все методы контроля, используемые при передаче по каналу связи (бит паритета, CRC и т.п.).
Есть и корректирующие коды (исправляюшие n-кратную ошибку) - вот тут хорошо бы знать модель ошибок.
Есть и корректирующие коды (исправляюшие n-кратную ошибку) - вот тут хорошо бы знать модель ошибок.
Я, конечно, извиняюсь, ибо в этой области я серый, как штаны пожарника.
Наверное, я сильно переживаю за данные в EEPROM, так как там модель ошибки очень случайная. Просто в народе бытует мнение о том, что данные в EEPROM могут иногда повреждаться. Многие причины этого повреждения известны и они учтены в самой конструкции и софте, но все равно хочется сделать некоторую избыточность так на всякий случай. А случаи как говорится разные бывают
.
Это все понятно (относительно EEPROM и ошибки, а не штанов пожарника ) .
Исходя из этого и был мой совет. Если не хотите лезть в книжки по системам связи, то возьмите самый известный CRC16 (используемый, например, в протоколе ModBus), посчитайте циклический код над байтами калибровочного коэфф-та и используйте его в Вашей операции сравнения. Этот подход оправдывается в тех случаях, когда калибровочные коэфф-ты занимают достаточно большую область памяти. Если же коэфф-т занимает 1-2 байта, то более целесообразен Ваш первоначальный алгоритм.
Тут на местном ftp - книжка старинная есть. Уильямс "Отладка микропроцессорных систем" 1988 г. Там, в частности, должен и этот вопрос рассматриваться.
Сама уже заглянула в книгу - там только предлагается расчет контрольной суммы области памяти, запись байта контрольной суммы и сравнение его с рассчитанным в программе. Контрольная сумма в книге - это сумма всех байт области без учета переполнения.
Использование CRC16 - все точно также, но алгоритм вычисления контрольной суммы (CRC16) чуть-чуть посложнее. Если что, свистните , выложу исходник на Си.
) . Исходя из этого и был мой совет. Если не хотите лезть в книжки по системам связи, то возьмите самый известный CRC16 (используемый, например, в протоколе ModBus), посчитайте циклический код над байтами калибровочного коэфф-та и используйте его в Вашей операции сравнения. Этот подход оправдывается в тех случаях, когда калибровочные коэфф-ты занимают достаточно большую область памяти. Если же коэфф-т занимает 1-2 байта, то более целесообразен Ваш первоначальный алгоритм.
Тут на местном ftp - книжка старинная есть. Уильямс "Отладка микропроцессорных систем" 1988 г. Там, в частности, должен и этот вопрос рассматриваться.
Сама уже заглянула в книгу - там только предлагается расчет контрольной суммы области памяти, запись байта контрольной суммы и сравнение его с рассчитанным в программе. Контрольная сумма в книге - это сумма всех байт области без учета переполнения.
Использование CRC16 - все точно также, но алгоритм вычисления контрольной суммы (CRC16) чуть-чуть посложнее. Если что, свистните
, выложу исходник на Си.
Цитата(Vic1 @ Oct 30 2005, 13:34)
Если же коэфф-т занимает 1-2 байта, то более целесообразен Ваш первоначальный алгоритм.
Спасибо вы правы пойду по первому пути.
Еще присоветую. Так как ошибка в коде может потереть кусок памяти одинаковым значением, или же микросхема может быть повреждена, троирование здесь может не помочь.
Запишите коэффициент через некоторые интервалы, которые будут заполнены сторожевым значением 0xDADA...DA<val>DA...DA<val>DA..DA<val>DA..DA и после этого наложите и запишите после этого CRC.
Запишите коэффициент через некоторые интервалы, которые будут заполнены сторожевым значением 0xDADA...DA<val>DA...DA<val>DA..DA<val>DA..DA и после этого наложите и запишите после этого CRC.
Еще вариант: записать само значение и его инверсию. Минимум накладных расходов.
Также, если в EEPROM достаточно свободного места, можно организовать что-то типа отказоустойчивой системы с транзакциями
: кольцевой буфер, в "голову" которого пишется пакетик данных, затирая "хвост". Преимущество: если последняя "транзакция" не удалась (например, питание ушло), можно вернуться к предыдущему значению (если это калибровочный коэффициент, то он обычно между калибровками уплывает ненамного, и со старым его значением прибор будет хоть как-то работать).
Также, если в EEPROM достаточно свободного места, можно организовать что-то типа отказоустойчивой системы с транзакциями
: кольцевой буфер, в "голову" которого пишется пакетик данных, затирая "хвост". Преимущество: если последняя "транзакция" не удалась (например, питание ушло), можно вернуться к предыдущему значению (если это калибровочный коэффициент, то он обычно между калибровками уплывает ненамного, и со старым его значением прибор будет хоть как-то работать).
данные в EEPROM типа 93Cxx действительно могут быть испорчены, если в момент записи пропадет питание, или на ноге CS будет активность (при сбросе процессора), при чтении - все ok
я делаю так:
в EEPROM записываю дополнительно два счетчика.
каждая запись состоит из следующих этапов:
1. считать, инкрементировать и записать счетчик 1.
2. записать данные
3. считать, инкрементировать и записать счетчик 2.
если значение счетчиков FF, то оно меняется на 01 (т.е. 00 и FF - запрещенные значения)
при считывании сравниваю счетчики
преимущества: не надо считывать всю информащию и рассчитывать контрольную сумму или СRC
недостатки: работает, если данные портятся только в момент записи.
я делаю так:
в EEPROM записываю дополнительно два счетчика.
каждая запись состоит из следующих этапов:
1. считать, инкрементировать и записать счетчик 1.
2. записать данные
3. считать, инкрементировать и записать счетчик 2.
если значение счетчиков FF, то оно меняется на 01 (т.е. 00 и FF - запрещенные значения)
при считывании сравниваю счетчики
преимущества: не надо считывать всю информащию и рассчитывать контрольную сумму или СRC
недостатки: работает, если данные портятся только в момент записи.
Самый тривиальный алгоритм подсчета контрольной суммы CRC16:
Последний элемент массива - значение CRC16 массива при проверке (возвращается 0 при правильной CRC16), 0 - при подсчете. Оптимизируйте при необходимости - я написал в свое время за 15 минут, совершенно не думая о производительности.
Код
WORD calc_crc16(WORD *ar,int num)
{
WORD i,j,val,val1;
val=ar[0];
for(i=1;i<num;i++)
{
val1=ar[i];
for(j=0;j<16;j++)
{
if(val&0x8000)
{
val=val^0x8005;
}
val=(val<<1);
if(val1&0x8000)
{
val++;
}
val1=(val1<<1);
}
}
ar[i-1]=val;
return(val);
}
{
WORD i,j,val,val1;
val=ar[0];
for(i=1;i<num;i++)
{
val1=ar[i];
for(j=0;j<16;j++)
{
if(val&0x8000)
{
val=val^0x8005;
}
val=(val<<1);
if(val1&0x8000)
{
val++;
}
val1=(val1<<1);
}
}
ar[i-1]=val;
return(val);
}
Последний элемент массива - значение CRC16 массива при проверке (возвращается 0 при правильной CRC16), 0 - при подсчете. Оптимизируйте при необходимости - я написал в свое время за 15 минут, совершенно не думая о производительности.
записывай на бумажку)))
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.