Перейти к содержанию
    

Какая вероятность порчи данных в разных областях памяти AVR?

Насколько я понимаю, вероятность порчи данных в eeprom AVR большая, и желательно застраховаться от их порчи.

 

Допутим у меня в приборчике используется какая-то уставка, я ее храню в eeprom, в пяти копиях.

Кроме того во флеш записаны верхний и нижний допустимые пределы этой уставки.

При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает.

________________

Вопросы.

А какая вероятность порчи данных в ячейке RAM и FLASH?

Имеет ли смысл проверять правильность данных и в этих областях?

Если да, то как это лучше сделать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Насколько я понимаю, вероятность порчи данных в eeprom AVR большая

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

При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает.

Думаете в RAM долговременно хранится лучше чем в EEPROM?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что-то мне не нравится это определение -- "порча". Возникают какие-то нездоровые ассоциации со сглазом, с гаданием на кофе, с П.Глобой, со звездами, со святой водой и т.д. Какой-то ненаучный термин -- "порча". Наверно лучше говорить о потере информации или искажении данных. Но это так, потрындеть...

 

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

 

По проблеме случайных изменений данных в EEPROM погуглите ради интереса, найдете много чего полезного. Несколько лет назад эта тема была очень обсуждаема в интернете. В спорах действительно было сломано много копий.

 

Что же конкретно делать? В основном советы сводятся к тому, что в схему нужно добавлять супервизор, если у вас затянутые фронты питающего напряжения (Vcc при включении/выключении медленно нарастает/спадает), и после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вероятность самопроизвольной порчи - крайне низкая.

Ладно, пусть я не умею правильно обращаться с еепром (писать программы, разводить платы), но дело в том, что и в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Учитывая, что я имел дело с очень небольшим количеством устройств, то проблема наверное все таки есть.

 

_________

Думаете в RAM долговременно хранится лучше чем в EEPROM?

Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю.

Сделать голосование для eeprom очень просто, так как чтение у меня только при пуске, а свободных ячеек много.

А как проверять целостность данных в RAM я не знаю. Предположения есть, но при этом простенькая програмка станет монстром.

 

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

 

_________

В основном советы сводятся к тому, что в схему нужно добавлять супервизор,

Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные.

 

_________

после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется.

А как лучше сделать, если програмка пишется в WinAVR, то если ввести неиспользуемую еепром-переменную и после любых обращений к еепром еще добавлять строчку с чтением этой переменной, будет это работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ладно, пусть я не умею правильно обращаться с

А это совсем не важно -- умеете Вы или нет. Важно -- хотите ли Вы научиться. Ваша жизнь не просто точка по пространстве. Ваша жизнь -- это движущаяся точка. Не важно, где Вы сейчас находитесь. Важно -- в каком направлении Вы двигаетесь.

 

в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились.

Все мы люди. И все разные. Кто-то делает на совесть, а кто-то абы-как. Кто-то пишет картины, а кто-то красит заборы.

 

Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю.

Сделать голосование для eeprom очень просто, так как чтение у меня только при пуске, а свободных ячеек много.

А как проверять целостность данных в RAM я не знаю. Предположения есть, но при этом простенькая програмка станет монстром.

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

 

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

Да ну! Что за фигня? Если Вы не изменяете флешь, то это граничит с паранойей. Так никто не делает. Что за аппарат такой Вы изобретаете, где требуется такая сверх-надежность?

 

Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные.

Я лично с проблемами EEPROM не сталкивался. Может везло :( ... хз.

 

А как лучше сделать, если програмка пишется в WinAVR, то если ввести неиспользуемую еепром-переменную и после любых обращений к еепром еще добавлять строчку с чтением этой переменной, будет это работать?

1. Создайте переменную в EEPROM, которую читаете. Ее значение не принимает участия в программе. Проследите, чтобы компилятор не "соптимизировал" код.

2. Тупо записывайте в регистр EEAR адрес неиспользуемой ячейки. Для этого дела как нельзя к стати подходит байт с адресом ноль.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Включайте brown out контроль и спите спокойно, никуда информация не денется.

 

Когда не было brown out при выключении происходило несанкционированное выполнение случайного кода, что не редко приводило к сбоям всякого рода, в том числе порче памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ладно, пусть я не умею правильно обращаться с еепром (писать программы, разводить платы), но дело в том, что и в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Учитывая, что я имел дело с очень небольшим количеством устройств, то проблема наверное все таки есть.

Причин может быть воз и маленькая тележка. Причем 99% - вина разработчика.

Думаете в RAM долговременно хранится лучше чем в EEPROM?

Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю.

Неправильно предполагаете.

Я лет пять назад столкнулся с ситуацией в которой устройство (брелок охранной автосигнализации) через несколько недель непрерывной работы (батарейка постоянно включена) терял некоторые данный в RAM(сериальный код блока). Разработчики этого устройства, которое выпускалось десятками тысяч штук сделали бредовую ошибку - читали содержимое EEPROM однократно, только при подаче питания.

 

Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные.

У первых - супервизоров не было вообще.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопчем, вероятность порчи данных экспоненциально стремится к нулю с ростом квалификации разработчика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А можно подробнее про это.

Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания.

А как правильно?

 

У первых - супервизоров не было вообще.

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

 

__________

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания.

А как правильно?

Наверное правильно читать EEPROM регулярно всё время.

 

Подобная проблема есть у FPGA - они читают конфигурационную флеш 1 раз при включении, и потом работают на копии в ОЗУ. Но может пролететь космическая частица и произойти сбой. Вот и придумывают для борьбы с этим всякие костыли к FPGA - подсчёт контрольной суммы содержимого конфигурационного ОЗУ, реализация 3 одинаковых схем внутри и т.д.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А можно подробнее про это.

Подробнее - двусторонний брелок системы Pantera XS-3300....

 

Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания.

А как правильно?

Правильно - регулярное обновление. Как вариант - выбрать некоторое событие (нажатие на кнопку или к примеру выключение зажигания) по которому устройство проводить через RESET - с полным обновлением памяти (кроме статусного регистра флагов) и битов портов.

ЗЫ. Ну и естественно если читать EEPROM однократно, то при любом RESET (в т.ч. и по WDT), а не только при подаче подаче питания.

ЗЗЫ. А вообще - если переменная в EEPROM не вижу смысла ее хранить в другом месте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

устройство (брелок охранной автосигнализации) через несколько недель непрерывной работы (батарейка постоянно включена) терял некоторые данный в RAM(сериальный код блока).

А эту ситуацию устранили? и каким образом? тупо многократным чтением EEPROM?

И потерю SN списали на зловредные космические частицы?

 

ЗЫ.Предполагаю что SN это всего несколько байт и их можно восстанавливать из епрома а как быть если необходимо иметь 4/8/16/32 и т.д. кб данных в RAM?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А эту ситуацию устранили? и каким образом? тупо многократным чтением EEPROM?

Мы небыли связаны с производителем этих систем. Поэтому устранили самым простым способом - перестали закупать эти модели... :twak:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash?

И вытекающий из первого - нужно ли принимать меры по проверки целостности данных и какие?

 

У меня сложилось мнение, что конкретные цифры никому не известны, и соответственно нет общепринятых мнений.

Просто кому какие случае на практике попались, тот и считает их главной проблемой. У меня это eeprom, у ArtemKAD - ram.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чрезвычайно низкая при соблюдении требований по питанию, помехоподавлению и пр. За более чем 10 лет работы с AVR проблем с несанкционированной порчей данных не встречал. Да, были глюки в программе, было дерьмовое питание от автомобиля, но в конце концов все наладилось, все выявленные ошибки - следствие огрехов в аппаратной части и программировании.

Причем содержимое флэша и еепром с помощью контрольных сумм не проверяю, и по 10 раз одно и то же не считываю

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...