Laksus 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Насколько я понимаю, вероятность порчи данных в eeprom AVR большая, и желательно застраховаться от их порчи. Допутим у меня в приборчике используется какая-то уставка, я ее храню в eeprom, в пяти копиях. Кроме того во флеш записаны верхний и нижний допустимые пределы этой уставки. При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает. ________________ Вопросы. А какая вероятность порчи данных в ячейке RAM и FLASH? Имеет ли смысл проверять правильность данных и в этих областях? Если да, то как это лучше сделать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
artemkad 89 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Насколько я понимаю, вероятность порчи данных в eeprom AVR большая Не правильно понимаете. Вероятность самопроизвольной порчи - крайне низкая. Порча происходит при попытках записи в условиях недостаточного питания или при банальнейших глюках ПО (к примеру при попытке чтения EEPROM в прерывании, без защиты содержимого служебных регистров, в момент ее записи в основном цикле) При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает. Думаете в RAM долговременно хранится лучше чем в EEPROM? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zhevak 0 9 сентября, 2011 Опубликовано 9 сентября, 2011 · Жалоба Что-то мне не нравится это определение -- "порча". Возникают какие-то нездоровые ассоциации со сглазом, с гаданием на кофе, с П.Глобой, со звездами, со святой водой и т.д. Какой-то ненаучный термин -- "порча". Наверно лучше говорить о потере информации или искажении данных. Но это так, потрындеть... Вам, в общем-то, правильно сказали, что если питание МК выполнено правильно и программа работает без побочных эффектов (то есть вы умеете писать робастые программы -- стеки не переполняются, код одной функции не искажает данные другой), то ни нет никакой разницы, где вам хранить -- в RAM, EEPROM или во внешнем EEPROM. Если у вас питание выполнено по принципу "тяп-ляп", если вы начинающий программер и пишите корявый код, то нет никакой гарантии, что ваши данные не будут случайно изменены. По проблеме случайных изменений данных в EEPROM погуглите ради интереса, найдете много чего полезного. Несколько лет назад эта тема была очень обсуждаема в интернете. В спорах действительно было сломано много копий. Что же конкретно делать? В основном советы сводятся к тому, что в схему нужно добавлять супервизор, если у вас затянутые фронты питающего напряжения (Vcc при включении/выключении медленно нарастает/спадает), и после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Laksus 0 10 сентября, 2011 Опубликовано 10 сентября, 2011 · Жалоба Вероятность самопроизвольной порчи - крайне низкая. Ладно, пусть я не умею правильно обращаться с еепром (писать программы, разводить платы), но дело в том, что и в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Учитывая, что я имел дело с очень небольшим количеством устройств, то проблема наверное все таки есть. _________ Думаете в RAM долговременно хранится лучше чем в EEPROM? Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю. Сделать голосование для eeprom очень просто, так как чтение у меня только при пуске, а свободных ячеек много. А как проверять целостность данных в RAM я не знаю. Предположения есть, но при этом простенькая програмка станет монстром. И еще насчет FLASH, где-то встречал мнение, что желательно при пуске пуске проверять контрольные суммы программы, но сейчас что-то не найду про это, хотелось бы чтобы кто-то подсказал где можно найти. _________ В основном советы сводятся к тому, что в схему нужно добавлять супервизор, Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные. _________ после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется. А как лучше сделать, если програмка пишется в WinAVR, то если ввести неиспользуемую еепром-переменную и после любых обращений к еепром еще добавлять строчку с чтением этой переменной, будет это работать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zhevak 0 10 сентября, 2011 Опубликовано 10 сентября, 2011 · Жалоба Ладно, пусть я не умею правильно обращаться с А это совсем не важно -- умеете Вы или нет. Важно -- хотите ли Вы научиться. Ваша жизнь не просто точка по пространстве. Ваша жизнь -- это движущаяся точка. Не важно, где Вы сейчас находитесь. Важно -- в каком направлении Вы двигаетесь. в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Все мы люди. И все разные. Кто-то делает на совесть, а кто-то абы-как. Кто-то пишет картины, а кто-то красит заборы. Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю. Сделать голосование для eeprom очень просто, так как чтение у меня только при пуске, а свободных ячеек много. А как проверять целостность данных в RAM я не знаю. Предположения есть, но при этом простенькая програмка станет монстром. Э-э... стоп-стоп-стоп! Я немного не понял. Мы говорим о проблемах несанкционированного изменения данных в EEPROM. Это, как мы знаем, происходят в моменты включения/выключения питания. Мы так же предполагаем, что программа написана правильно и не выполняет неожиданных действий. Иначе говоря, мы абсолютно понимаем как работает наша программа. Но, если нас беспокоят проблемы включения/выключения питания, то тогда причем здесь RAM? При выключении питания информация в RAM полностью теряется. И еще насчет FLASH, где-то встречал мнение, что желательно при пуске пуске проверять контрольные суммы программы, но сейчас что-то не найду про это, хотелось бы чтобы кто-то подсказал где можно найти. Да ну! Что за фигня? Если Вы не изменяете флешь, то это граничит с паранойей. Так никто не делает. Что за аппарат такой Вы изобретаете, где требуется такая сверх-надежность? Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные. Я лично с проблемами EEPROM не сталкивался. Может везло :( ... хз. А как лучше сделать, если програмка пишется в WinAVR, то если ввести неиспользуемую еепром-переменную и после любых обращений к еепром еще добавлять строчку с чтением этой переменной, будет это работать? 1. Создайте переменную в EEPROM, которую читаете. Ее значение не принимает участия в программе. Проследите, чтобы компилятор не "соптимизировал" код. 2. Тупо записывайте в регистр EEAR адрес неиспользуемой ячейки. Для этого дела как нельзя к стати подходит байт с адресом ноль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kan35 7 11 сентября, 2011 Опубликовано 11 сентября, 2011 · Жалоба Включайте brown out контроль и спите спокойно, никуда информация не денется. Когда не было brown out при выключении происходило несанкционированное выполнение случайного кода, что не редко приводило к сбоям всякого рода, в том числе порче памяти. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
artemkad 89 12 сентября, 2011 Опубликовано 12 сентября, 2011 · Жалоба Ладно, пусть я не умею правильно обращаться с еепром (писать программы, разводить платы), но дело в том, что и в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Учитывая, что я имел дело с очень небольшим количеством устройств, то проблема наверное все таки есть. Причин может быть воз и маленькая тележка. Причем 99% - вина разработчика. Думаете в RAM долговременно хранится лучше чем в EEPROM? Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю. Неправильно предполагаете. Я лет пять назад столкнулся с ситуацией в которой устройство (брелок охранной автосигнализации) через несколько недель непрерывной работы (батарейка постоянно включена) терял некоторые данный в RAM(сериальный код блока). Разработчики этого устройства, которое выпускалось десятками тысяч штук сделали бредовую ошибку - читали содержимое EEPROM однократно, только при подаче питания. Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные. У первых - супервизоров не было вообще. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
V_G 11 12 сентября, 2011 Опубликовано 12 сентября, 2011 · Жалоба Вопчем, вероятность порчи данных экспоненциально стремится к нулю с ростом квалификации разработчика. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Laksus 0 13 сентября, 2011 Опубликовано 13 сентября, 2011 · Жалоба Разработчики этого устройства, которое выпускалось десятками тысяч штук сделали бредовую ошибку - читали содержимое EEPROM однократно, только при подаче питания. А можно подробнее про это. Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания. А как правильно? У первых - супервизоров не было вообще. Ну я имел ввиду, когда они уже появились, то первые были ненадежные, и было общепризнанным правилом их не использовать, а ставить внешние. __________ А вообще то я для себя решил, что так как по любому нельзя самим устройством обнаружить все свои глюки, то сделаю еще один приборчик, который будет следить за работой основного устройства, и в случае недопустимого отклонения в режиме работы основного, будет давать сигнал аварии и блокировать опасные действия первого устройства. Думаю, что вероятность отказа обеих устройств сразу, будет очень малой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
maksimp 0 13 сентября, 2011 Опубликовано 13 сентября, 2011 · Жалоба Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания. А как правильно? Наверное правильно читать EEPROM регулярно всё время. Подобная проблема есть у FPGA - они читают конфигурационную флеш 1 раз при включении, и потом работают на копии в ОЗУ. Но может пролететь космическая частица и произойти сбой. Вот и придумывают для борьбы с этим всякие костыли к FPGA - подсчёт контрольной суммы содержимого конфигурационного ОЗУ, реализация 3 одинаковых схем внутри и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
artemkad 89 14 сентября, 2011 Опубликовано 14 сентября, 2011 · Жалоба А можно подробнее про это. Подробнее - двусторонний брелок системы Pantera XS-3300.... Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания. А как правильно? Правильно - регулярное обновление. Как вариант - выбрать некоторое событие (нажатие на кнопку или к примеру выключение зажигания) по которому устройство проводить через RESET - с полным обновлением памяти (кроме статусного регистра флагов) и битов портов. ЗЫ. Ну и естественно если читать EEPROM однократно, то при любом RESET (в т.ч. и по WDT), а не только при подаче подаче питания. ЗЗЫ. А вообще - если переменная в EEPROM не вижу смысла ее хранить в другом месте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zombi 0 15 сентября, 2011 Опубликовано 15 сентября, 2011 · Жалоба устройство (брелок охранной автосигнализации) через несколько недель непрерывной работы (батарейка постоянно включена) терял некоторые данный в RAM(сериальный код блока). А эту ситуацию устранили? и каким образом? тупо многократным чтением EEPROM? И потерю SN списали на зловредные космические частицы? ЗЫ.Предполагаю что SN это всего несколько байт и их можно восстанавливать из епрома а как быть если необходимо иметь 4/8/16/32 и т.д. кб данных в RAM? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
artemkad 89 15 сентября, 2011 Опубликовано 15 сентября, 2011 · Жалоба А эту ситуацию устранили? и каким образом? тупо многократным чтением EEPROM? Мы небыли связаны с производителем этих систем. Поэтому устранили самым простым способом - перестали закупать эти модели... :twak: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Laksus 0 16 сентября, 2011 Опубликовано 16 сентября, 2011 · Жалоба Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash? И вытекающий из первого - нужно ли принимать меры по проверки целостности данных и какие? У меня сложилось мнение, что конкретные цифры никому не известны, и соответственно нет общепринятых мнений. Просто кому какие случае на практике попались, тот и считает их главной проблемой. У меня это eeprom, у ArtemKAD - ram. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
V_G 11 16 сентября, 2011 Опубликовано 16 сентября, 2011 · Жалоба Чрезвычайно низкая при соблюдении требований по питанию, помехоподавлению и пр. За более чем 10 лет работы с AVR проблем с несанкционированной порчей данных не встречал. Да, были глюки в программе, было дерьмовое питание от автомобиля, но в конце концов все наладилось, все выявленные ошибки - следствие огрехов в аппаратной части и программировании. Причем содержимое флэша и еепром с помощью контрольных сумм не проверяю, и по 10 раз одно и то же не считываю Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться