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

[PlainUser]

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

Тупо использовать или тупо игнорировать это практически одно и тоже.
Должна быть цель , обоснованная цель.

[niXto]

Проверять работоспособность контроллера - полный бред. Где гарантия, что в результате воздействия "ионизированной частицы" не произойдет ошибка Именно в подпрограмме проверки работоспособности? и из-за этого вся программа пойдет в разнос... Если нет доверия контроллеру - возьмите другое семейство, если есть сомнения что контроллеры вообще будут работать - ставьте хоть К155 что до сих пор делают вояки. Сейчас свое неумение программировать и ловить глюки последовательно в каждом модуле программы модно компенсировать вачдогами и внешними ресетами... Просто нужно знать все воздействия которые могут быть, и предусмотреть программные/аппаратные способы минимизации последствий. Если вы строите дом так, что он может упасть - то не нужно предусматривать лампочку на пульте, сигнализирующую об успешном обрушении дома

[st_1]

Проверять работоспособность контроллера - полный бред. Где гарантия, что в результате воздействия "ионизированной частицы" не произойдет ошибка Именно в подпрограмме проверки работоспособности? и из-за этого вся программа пойдет в разнос...

Давайте уже хоть само понятие "бред" не доводить до состояния бреда...
Давайте не будем считать идиотами ведущих производителей МК, которые напичкивают всякими фичами, типа переключение тактирования, запрет на изменение настроек модулей и портов, трапы и прочее, свои изделия.
Значит это всё кому-то нужно???
А иначе... зачем проверять авто, самолёты и атомные станции... один хрен бьются и взрываются... вопрос только в том... насколько часто???

[you_go]

В ответственных приложениях для защиты данных я всегда использую либо код Соломона Рида. либо как минимум CRC блоков данных. Сбои могут случиться везде, в том числе и в подпрограммах контроля. Но все же, если контроль в программе присутствует как таковой, то всегда можно принять решение либо о восстановлении данных, либо о рестарте, либо о фатальной ошибке. Это всяко лучше, чем работать "вслепую".

[niXto]

В ответственных приложениях для защиты данных я всегда использую либо код Соломона Рида. либо как минимум CRC блоков данных.

Для передачи данных - не спорю, это обязательно. Но Внутри контроллера контроль данных - немножко бессмысленно. Кроме флеш-памяти которая действительно теоритически лет через 20 может испортиться.

Давайте не будем считать идиотами ведущих производителей МК, которые напичкивают всякими фичами, типа переключение тактирования, запрет на изменение настроек модулей и портов, трапы и прочее, свои изделия.

Так может давайте доверять производителям а не думать "ой, они наверное дураки и не предусмотрели ‹тут› защиту - давай-ка я добавлю программную защиту". Есть конечно форсмажоры типа переключения тактирования на источник, на выходе которого нет генерации - но это лишь значит что нужно быть более осторожным при переключениях. А не что нужно вешать снаружи костыли на 555 который будет контролировать и ресетить всю систему. "Если бы программисты строили города - то первый залетевший дятел приводил бы к краху цивилизации"

[testerplus]

Проверять работоспособность контроллера - полный бред.

Это Вы зря. Есть такие вещи как электромиграция, инжекция горячих носителей в диэлектрик, температурные деформации, брак производства, утечка заряда, недозаряд/недостироание flash-ячейки и пр. Ничто, кроме самого МК это детектировать не сможет.

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

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

Сейчас свое неумение программировать и ловить глюки последовательно в каждом модуле программы модно компенсировать вачдогами и внешними ресетами...

Тут ключевое слово "сейчас". Оттого, что эмбеддерство стало модным и доступным, и туда поналезно неумеек, влияние помех и проблем лектромеханического характера не стало меньше. Даже наоборот: со временем технологический процесс становится все тоньше -› меньше токи -› больше влияние помех. (Та же электромиграция быстрее разрушит тонкий проводник).

Еще одно слово "компенсировать" не совсем уместно. Грамотно применить вочдог - это не многим профессионалам под силу. А натыкать его бездумно - это вовсе не скомпенсировать, а создать себе иллюзию отказоустойчивости своей поделки.

Для передачи данных - не спорю, это обязательно. Но Внутри контроллера контроль данных - немножко бессмысленно. Кроме флеш-памяти которая действительно теоритически лет через 20 может испортиться

EEPROM тоже в зоне риска (слабые места - стирание и запись). А в некоторых случаях есть смысл и участки RAM защищать CRC.


С радостью бы подискутировал (у меня это больная тема ), но шибко занят: кстати строительством дома

Если вы строите дом так, что он может упасть...

Кстати, OFF: всегда было интересно, почему дома в американских штатах, где часто бывают ураганы, построены так, что у них всегда срывает крыши и ломаются стены?

[PlainUser]

Давайте уже хоть само понятие "бред" не доводить до состояния бреда...
Давайте не будем считать идиотами ведущих производителей МК, которые напичкивают всякими фичами, типа переключение тактирования, запрет на изменение настроек модулей и портов, трапы и прочее, свои изделия.
Значит это всё кому-то нужно???
А иначе... зачем проверять авто, самолёты и атомные станции... один хрен бьются и взрываются... вопрос только в том... насколько часто???

Ведущие производители чего угодно следят за модой.
Это позволяет увеличить продажи.
Типичный пример широкая реклама ООП для МК лет 10 назад.Тогда это было модно.
Сейчас уже давно забыли.

[st_1]

С радостью бы подискутировал (у меня это больная тема ), но шибко занят: кстати строительством дома

Респект... Виктор!!!

[niXto]

Это Вы зря. Есть такие вещи как электромиграция, инжекция горячих носителей в диэлектрик, температурные деформации, брак производства, утечка заряда, недозаряд/недостироание flash-ячейки и пр. Ничто, кроме самого МК это детектировать не сможет.

Я же говорил

Если нет доверия контроллеру - возьмите другое семейство, если есть сомнения что контроллеры вообще будут работать - ставьте хоть К155

Если в рабочем режиме жизненного цикла устройства у контроллера возможны "электромиграция, инжекция горячих носителей в диэлектрик, температурные деформации, брак производства, утечка заряда" - его применять категорически НЕЛЬЗЯ!!! Нужно применять те, у которых такое невозможно, если таковых не существует - делать на жесткой логике. Но не надеяться "Авось внешняя защита ресетнет и спасет жизнь(и)"

у меня в критических устройствах программа проверки флеши (программ и данных, обе изготовлены по флеш-технологии поэтому обоих называю флеш)запускается только при включении питания устройства (в секции бутлодера), больше никогда. В обычных применениях проверки - лишние понты. Тем более как вы правильно замечаете, бездумное использование проверок только вредит иллюзией

[st_1]

Я же говорил

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

Если в рабочем режиме жизненного цикла устройства у контроллера возможны "электромиграция, инжекция горячих носителей в диэлектрик, температурные деформации, брак производства, утечка заряда" - его применять категорически НЕЛЬЗЯ!!! Нужно применять те, у которых такое невозможно, если таковых не существует - делать на жесткой логике. Но не надеяться "Авось внешняя защита ресетнет и спасет жизнь(и)"

О да!!! Серия К511 нам поможет!!!
Вы видимо никогда не сталкивались, как сбоит логика в условиях промышленных помех!!! Большое количество корпусов и большие размеры плат приводят только к снижению надёжности в целом...

у меня в критических устройствах программа проверки флеши (программ и данных, обе изготовлены по флеш-технологии поэтому обоих называю флеш)запускается только при включении питания устройства (в секции бутлодера), больше никогда. В обычных применениях проверки - лишние понты. Тем более как вы правильно замечаете, бездумное использование проверок только вредит иллюзией

Если вы что-то недопонимаете или делаете неправильно, то это не повод для гордости...