Кто как расчитывает надёжность проектируемой программы для микроконтроллера?
Дон Амброзио: виде спец. организации программ, чтобы не один сбой не проходил "не замеченным" программой
Как Вы себе это представляете? Это уже сродни мании преследования. У Вас блок слежения "все ли хорошо" будет в разы больше самой программы. А ведь за ним тоже следить надо, вдруг в нем сбой произойдет?...
Мне это напоминает цитату с баша:
serg> Читаю код доставшийся от коллеги
serg> ...
if ($flag == false) {
# на вский случай
if (false == true)
exit;
include "execute.php";
}
serg> чувак убил мой моск...
serg> какой нах ВСЯКИЙ СЛУЧАЙ???
Дон Амброзио: Тоже не выход, поскольку вся надёжность не зависит от количества дублей системы,а определеятся надёжностью "схемы сравнения", от того насколько надёжно она "сравнивает"
Схема сравнения обычно делается на жесткой логике, надежность которой в разы больше любоого кода. Забыл слово. Есть специальные клапаны. Даже в 155 серии такие есть.
А вообще время, потраченое на попытки построить тотально контролируемую программу, лучше потратить на ее тестирование, проверку и упрощение. 
Дон Амброзио: Ну допустим я "упрощу" программу исключив из неё код обнаружения случайных джампов?
Я смутно представляю, как у Вас организована проверка случайных джампов. Было бы любопытно ознакомится с принципами.
Я же говорю про то, что если у Вас устройство так чувствительно к помехам и может вылетать неизвестно куда, то тут мало что поможет. Хотя, чем проще программа, тем меньше времени она выполняется и тем меньше вероятность сбоя именно в момент выполнения. С той же стороны, чем меньше программа, чем меньше адресов она занимает, тем меньше вероятность при сбое улететь на середину программы. Больше вероятность улететь за ее край. Всю свободную память можно забить джампами на обработчик вылета. Но все это вряд ли прокатит на архитектурах более 8 бит. Там своя специфика.
Dron_Gus: Где-то тут приводили пример разборов падения Французкой (?) ракеты носителя...
- Если это про аварию Ариан-5, там чисто программный глюк был. Ещё бы, софт ведь писали любители-самоучки -- использовался язык программирования Ada (более высокоуровневый, чем C), а не ассемблер.
caddr: там чисто программный глюк был
Ну суть в том что там тоже резервирование было. И резервный блок завис от того же глюка.
Вот не пойму, в честь чего столько внимания "случайным" переходам. Даже если и отловите их на 100%, это всего лишь защита от аварийного изменения _одного_ регистра процессора (IP).
Предупреждение.
Вы общаетесь с сетевым троллем. Доктором.
Интересно, а как можно отслеживать правильность выполнения кода(программы), теже "случайные джампы" и т.п.. Или типа к PIC^AVR прикрутить ARM чтобы следить за его работой?, а кто будет следить за ARM?.....
Помоему вся тема пиз.. флейм чистой воды
ЗЫ. На работе делали проект( и наладку) литейной машины, постороенной на CPU S7-300 за 4-е года ни одного "программного" сбоя!!! Программу писал я, причем без "специфических" знаний.
Вспомнил! Я во всех своих конечных автоматах (построенных на switch - конструкциях) вставляю типа
defaut:
state = 0;
break;
Это считается повышением сопротивляемости программы аппаратным глюкам?