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

Допутим у меня в приборчике используется какая-то уставка, я ее храню в eeprom, в пяти копиях.
Кроме того во флеш записаны верхний и нижний допустимые пределы этой уставки.
При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает.
________________
Вопросы.
А какая вероятность порчи данных в ячейке RAM и FLASH?
Имеет ли смысл проверять правильность данных и в этих областях?
Если да, то как это лучше сделать?

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

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

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

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

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

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

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

_________

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

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

_________

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

_________

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

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


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


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


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


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


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

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

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

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

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


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

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

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


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

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

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

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

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


Правильно - регулярное обновление. Как вариант - выбрать некоторое событие (нажатие на кнопку или к примеру выключение зажигания) по которому устройство проводить через RESET - с полным обновлением памяти (кроме статусного регистра флагов) и битов портов.
ЗЫ. Ну и естественно если читать EEPROM однократно, то при любом RESET (в т.ч. и по WDT), а не только при подаче подаче питания.
ЗЗЫ. А вообще - если переменная в EEPROM не вижу смысла ее хранить в другом месте.

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

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

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

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

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

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