О сохранности данных в памяти МК

[niXto]

Надежность хранения данных в ОЗУ контроллера почти идеальная, ещё ни разу не сталкивался с тем, чтобы данные повреждались САМОпроизвольно (например, из-за пролета ионизирующей частицы или отдаленного ядерного взрыва)... Все искажения данных, что встречались - чисто программные косяки, и вычислялись при отладке. Так что хранить данные в ОЗУ можно хоть годами, не боясь что где-то единица внезапно станет нулем, или наоборот...

[nahimovv]

Угу, пионерский бред.

[_Слон_]

Надежность хранения данных в ОЗУ контроллера почти идеальная, ещё ни разу не сталкивался с тем, чтобы данные повреждались САМОпроизвольно (например, из-за пролета ионизирующей частицы или отдаленного ядерного взрыва)... Все искажения данных, что встречались - чисто программные косяки, и вычислялись при отладке. Так что хранить данные в ОЗУ можно хоть годами, не боясь что где-то единица внезапно станет нулем, или наоборот...

Спасибо. Я тоже так считаю. Просто у нас тут с коллегами спор возник...
А память FRAM, конечно, стоящая вещь...Впервые я о ней узнал около года назад. Тогда мне казалось, что это технология недалекого будущего. А сейчас посмотрел по ценам-вполне доступно.

[testerplus]

Не знаю, насколько на самом деле важен конкретный счетчик посещений туалета, но для информации:

Вообще-то ОЗУ может сбоить. Скажем, спустя 5 лет работы из-за деградации характеристик МОП-транзистора вследствие инжекции горячих носителей в окисел, какая-то ячейка начнет нестабильно читаться/писаться. Космическое излучение – редко, но бывает. Просто зарегистрировать такие ошибки, чтобы утверждать, что именно они привели к сбою, в обычном девайсе нереально:
- во-первых, в памяти не так много битов, изменение которых привело бы к фатальной ошибке (PC, указатель стека, конфигуратор прерываний; это, понятно, не считая проблемно-ориентированных данных, вроде Вашего счетчика), поэтому часто такие сбои памяти просто остаются незамеченными, либо замеченными гораздо позже, чем произошло изменение бита.
- во-вторых, чтобы хоть попытаться зафиксировать такой сбой, нужны как минимум программные средства контроля за всеми битами, что несколько нереально.

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

----

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

Т.е. сохранение в EEPROM в таких случаях так же должно делаться тройным резервированием с контрольными суммами. С временнЫми лагами между записью и восстановлением (т.к. запись может начаться но не успеть закончиться, а МК уже перезагрузится и полезет читать EEPROM, при этом получит отказ). А вообще, процедура замены батарейки в таких случаях должна предусматривать порядок действий, при котором резервное копирование в еепром производится до ее извлечения.

[niXto]

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

Вполне реально. У современных контроллеров опционально есть аппаратный модуль контроля CRC каждой ячейки ОЗУ, и автоматическая генерация прерывания при несовпадении. Хотя бы стм32ф0хх по цене чуть больше доллара. Но для обычного применения (в не-критически важных местах) ОЗУ вполне можно доверять

[testerplus]

Вполне реально. У современных контроллеров опционально есть аппаратный модуль контроля CRC каждой ячейки ОЗУ, и автоматическая генерация прерывания при несовпадении. Хотя бы стм32ф0хх по цене чуть больше доллара.

Это хорошо (и, кстати, показательно), что в широтребовских МК начали появляться такие модули. Остается надеяться, чтобы разработчики ими хотя бы пользовались
(А вроде ТС хотел что-то простое: пикаврстм8 )

[nahimovv]

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

5+ ! .

[KBH-I]

Дублирование, избыточное кодирование (Хэмминг и пр.) - много вариантов передачи-хранения-восстановления данных. Гугль в помощь.

Пардон, но это единственный топик со словом "Хэмминг".
Просто на днях узнал, что RAID-2 - это и есть диск с поддержкой кодов Хэмминга.
А у меня как раз завалялся старенький HDD на 1Тб. Вот и думаю, а как бы его сделать с защитой кодами Хэмминга?
Наверно, придётся его делить на 2 логических диска (а каких именно и с каким объёмом каждый?), затем как-то объединять в массив RAID-2?

В Тырнете - какая-то помойка и всё не то: http://yandex.ru/yandsearch?text=%D1...id=9582&lr=213

Поэтому вопрос: никто не пытался делать внешний диск RAID-массивом, причём именно RAID-2?

[Boba_spb]

Вполне реально. У современных контроллеров опционально есть аппаратный модуль контроля CRC каждой ячейки ОЗУ, и автоматическая генерация прерывания при несовпадении. Хотя бы стм32ф0хх по цене чуть больше доллара. Но для обычного применения (в не-критически важных местах) ОЗУ вполне можно доверять

Вектор прерывания в студию !!!
Иль ссылку на эту сказку.

[niXto]

Вектор прерывания в студию !!!
Иль ссылку на эту сказку.

Очередной раз рекомендую изучать английский. Работать с современными микроконтроллерами, руководствуясь только переводами на русский, уже практически нереально. Ссылка на эту сказку - http://www.st.com/st-web-ui/static/a...DM00091010.pdf