Я совершенно не спорю с вами я просто не знаю ответа.

Вот скажите мне при каком условии вероятность сбоя будет выше?
1) 1 раз записать ячейку - 100 млн. раз её прочитать.
2) 100 тыс. раз записать ячейку - 100 млн. раз её прочитать.

Давайте ещё один пример виртуальный с EEPROM.
Представим себе ситуацию что надо хранить 50 байт данных и периодически обновлять их.
Как надёжнее?
1) Просто записать и КС
2) Хранить 3 экземпляра и кс.
и ещё вопрос
В каком из этих вариантов EEPROM разрушится быстрее или вероятность появления ошибки выше?

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

Есть пример - контроллер мостовой пилы для резки гранита.
Все просто - тележка ездит вперед/назад, пила вверх/вниз и враво/влево, датчики положения (холла).
Решения - периодическая проверка живучести системного таймера, таймауты на прием сигналов датчиков. Красота... но если пила в камне, то вправо/влево включать нельзя. А как сие определить?
Проверить положение? А если что-то врет? Тогда получается некрасивая пропорция - проц за 1 доллар убивает пилу за 2000 оных. Вышли из положения - перемещения влево/вправо можно только выключить автоматом. Включить - только вручную.
Извините за оффтоп.

Конечно - это всё не праздные вопросы. И в каждом конкретном случае надо самостоятельное решение принимать. А груз ответственности велик.

Скажем в таких приложениях никто не заставляет AVR применять, хотя с другой стороны если проц за 1$ это ещё не значит что он не надёжный. К тому же резервирование на процессорах за 1$ будет стоить дешевле естественно с точки зрения аппаратной части. А вот разработка программного обеспечения - будет трудоёмким. (Я естественно не призываю - так - вариант)

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

Будем решать. Будем внимательнее.

Брат объявился!
Про пилу - это дела минувших дней.
А про Вашу тему - сейчас то же самое делаю по синхронному движению.
В личку можно?

На то она и личка

Полностью согласен, достаточность мер диагностики определяет только разработчик и под свою ответственность. И на 99% вероятность аварии в его руках.
Но если вернуться к теме

То честно говоря не вижу в этом особого смысла, да и возможности. При включении можно проверить всё, что угодно. А как во время работы проверить ОЗУ? Остановить устройство, и записывать-считывать память, регистры и т.п.?

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

Мне, вот, просто интересно стало. А что же делать если микроконтроллер расположен внутри ПЛИС, ведь это почти тоже самое что и взять стандартный чип? И как такие устройства работают?

Как как.. Да как два пальца абосфальт.. Записал чё-нить в ОЗУ и тут же прочитал (проверил тем самым записалось ли). Не знал про такой способ?

А тут же, это когда, через такт, секунду, месяц?
А ещё бывают volatile переменные, что, запрещать к ним доступ, что бы прочитать что записалось?

Можно выделить сразу буфер, для проверуи памяти. Сначала проверяете его, а потом блоками перетаскиваете в него содержимое из ОЗУ, проверив определённый участок памяти, возвращаете туда то что перекидывали. Естенственно на время теста нужно вырубать прерывания. А период тестирования определяется параметрами надёжности и безопасности вашего устройства.

Известно из работ 80-х годов по тестированию ОЗУ (конкретнее - если найду книжку - скажу) о том, что такой способ является самым грубым и не обеспечивает выявление даже половины возможных неисправностей.

Единственный способ проверок такого рода, резервирование двойное, а то и тройное.

Тестирование памяти вообще достаточно серьёзная задача. Ну а какие ещё способы тестирования ОЗУ в фоновом режиме Вы можете предложить).

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

Интересно...., а контроль переполнения стека тоже относится к одному из видов фобий или есть какая нибудь целесеобразность?