Кто как расчитывает надёжность проектируемой программы для микроконтроллера?

Оглянитесь вокруг и найдите такого человека, у которого все ломается в руках. Дайте ему поиграться с вашим устройством, оцените результат. В будущем берегите этого человека!!

Как нас учили в курсе надёжности РЭА, конкретные условия эксплуатации, и в особенности помеховая обстановка - это чуть ли не самое случайное, что может быть. Ну и как же такую случайность смоделировать? По-моему, только в реале... Иначе натурные испытания стали бы не нужны, и изделия с конструкторского стола сразу передавались бы в серию.

Дон Амброзио, КТО КАК ....
Это опять простой развод на болтовню....или как хочешь, так и проверяй, или как скажет ЗАКАЗЧИК, так и сделаешь...в разных солидных организациях свои школы и принципы...

Это весьма хитрый и профессиональный вопрос Все зависит от стиля программирования идеально подходит только ASM
а в библиотеках С много ненадежных дырок .Я писал такие программы, которые не завизали и не выходили из под контроля
но это уже стоит денюжек, а школьные програмки -это вон любой С-компилятор делает. Скажу только одно, - таймеры в
таких программах закручены на всю катушку и система прерываний вложенная, остальное секрет , потому что я знаю кто ноет
на эту тему и кому это нужно, пусть вначале научаться платиь за работу как во всем мире.

Смешались в кучу кони, люди....
Вопрос делится на ДВА ВОПРОСА.
1. Надежность аппаратной части. Т.е. по сути возможность кристалла выполнять возложенные на него проектировщиком и производителем функции.
Все тесты давно произведены, если это не рекламируемый новодел, а вы в роли лоха бесплатно отлавливающего баги проектировщика. Отсюда правило - берите надежные кристаллы работа которых проверена временем их жизни.. Разводку платы поручите профессионалу. Если что не ясно- ОБРАТИТЕСЬ К ПРОИЗВОДИТЕЛЮ КОНТРОЛЛЕРА.
2. Корректность (в рамках определенной производителем програмной модели) закладываемой потребителем программы. ОБРАТИТЕСЬ К ВАШИМ ПРОГРАММИСТАМ

Использовать Вач-Дог, если есть в контроллере. Изредка проверять целосность программы - считать CRC. Кто-то считает, что использование state machine позволяет избавится от многих труднодиагностируемых ошибок.

А вообще зависит от "масштаба" программы. ATtiny и ARM9 две большие разницы.

Дон Амброзио И почему если state machine позволяет избавится от многих труднодиагностируемых ошибок их не юзают все поголовно?

Потому-что это дело вкуса и стиля, и для простых вещей они, зачастую, неоправданно трудоемки. Насколько я копал даташиты - в микроконтроллерах все аппаратные модули сделаны именно на машинах состояний, и примеры их программной реализации - тот-же метод (например программная реализация I2C в Хайтековских примерах для PICC-18).

Дон Амброзио: А что это за машины-то такие и "с чем их едят"?
Только в двух словах. Т.к. сам не большой приверженец. Описываете все состояния Вашей системы (устройства). Описываете все входные сигналы. Далее для каждого состояния описываете реакцию на входные сигналы в виде перехода (не обязательно) в другое состояние. Сразу же уходят огромное количество "навороченных" и многократно вложенных if-else. Если обработчик состояния все равно большой - разбиваете его на несколько проще или вводите внутри него подсостояния, со своими переходами. В итоге у Вас должен получится массив с указателями на функции-обработчики состояний и сама переменная, которая хранит текущее состояние. Сами обработчики линейные и описывают малую часть функционала, поэтому легко пишутся и читаются.

З.Ы. я на этом принципе реализовывал драйвер GSM модема. Вроде работает. Во всяком случае код читабельный.

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

Dron_Gus: Кто-то считает, что использование state machine позволяет избавится от многих труднодиагностируемых ошибок. Пойдем на поводу у "Естественного человеческого отвращения к мыслительному процессу".... Для простых алгоритмов (там где опытный программист ошибается мало)хорошо подходит. Для сложных весьма громоздко в формальную логику безошибочно вписать. Новые ошибки появятся...
Кроме того, реализованные таблицы , как правило, состоят из команд длинных переходов (например 3-х байтных), и "пустые" состояния описываются тем-же размером. Быстродействие прекрасное, но обьем очень быстро растет при увеличении сложности алгоритма.. Полагаю, этот прием эффективен только в некоторых частях программы..