Тестирование работоспособности контроллера

[st_1]

Здесь все таки обсуждается обычна промышленная железяка, а не супер пупер хрень выдерживающая ядрёный взрыв с его окуенным ЭМИ и прочими прелестями.

Бросьте... вы не сталкивались с "обычными" промышленными помехами??? Та ещё "радость"...

[_guardianangel]

Сталкивался - 4 года был наладчиком промышленного и испытательного оборудования.

[PlainUser]

Я, кстати, при разработке чего-то сложнее гирлянды, часто закладываю счетчик резетов. В начале инициализации проц прибавляет единичку к значению в еепром. Через некоторое время считываю еепром и смотрю - не было ли резетов?

Одобряю , может дать пищу к размышлениям.И затрат практически ноль.

[PlainUser]

Вы о чём это??? Если ёлочная гирлянда, то нет смысла, а если это удалённо обслуживаемый и обновляемый девайс???

И что ?
Как проверить исправность проца при помощи его самого.
И главное как понять где неисправность в рабочей процедуре или в процедуре проверки?
Все писатели подобных тестов исходят из некоторых родившихся исключительно в их мозгу допущений никакими даташитами , регламентами и фундаментальной теорией не подкрепленными.

Типа ..."вот пролетит рядом бозон хикса а проц-то и сбойнет , а мы че-нибудь посчитаем и ошибку то исправим".

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


ЗЫ Ну собственно че-то делать всяко надо.
Но при этом полезно никому не верит на слово и почаще задавать вопрос ПОЧЕМУ?
Хотя-бы самому себе.
Это страшный вопрос , ответ на него знают не многие.
Я вот точно не знаю.


Из местного сообщества наиболее авторитетным в этих вопросах считаю testerplus.
Кое в каких мелочах несогласен но это совсем мелочи.

[PlainUser]

Простейший пес делается на каком-нибудь чахлом PIC10. Важно, я думаю, только питание ему свое сделать. Чтоб помеха по питанию только один камень свешивала. А в идеале опторазвязку обеспечить.

В чем-то согласен , даже применял для этого 12ф629.
Но сейчас считаю что идеологически правильнее нечто более дубовое, одновибратор на 555 или РЦ цепочку...

Встроенным в процы вачдогам не верю, даже когда пишут что они независимые.
Это не правда.

[st_1]

Из местного сообщества наиболее авторитетным в этих вопросах считаю testerplus.
Кое в каких мелочах несогласен но это совсем мелочи.

Как проверить исправность проца при помощи его самого.
И главное как понять где неисправность в рабочей процедуре или в процедуре проверки?
Все писатели подобных тестов исходят из некоторых родившихся исключительно в их мозгу допущений никакими даташитами , регламентами и фундаментальной теорией не подкрепленными.

Да как-то первая фраза не вяжется со второй... к чему бы это???

[PlainUser]

Да как-то первая фраза не вяжется со второй... к чему бы это???

Человек существо противоречивое и склонное к саморазрушению.

[st_1]

Типа ..."вот пролетит рядом бозон хикса а проц-то и сбойнет , а мы че-нибудь посчитаем и ошибку то исправим".

Простой пример... кодовый замок... Многие ли при совпадении кода или ошибке пересбрасывают МК... хотя бы программно??? А ведь казалось... чего проще... ничего не теряем... просто провели заново инициализацию...

[st_1]

Как и ставит ловушки на неиспользуемые прерывания.

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

[alex_r61]

А поставить внешний микромонитор типа
DS1232 это сильно сложно?