Кроме как для сброса плохо написанной "зависшей" программы для чего ещё можно использовать?

Для пробуждения из глубокого сна, для программного сброса.

Возможно, но почему "программного"? может всётаки аппаратного?

Потому что инициирован программно.

В том смысле, что программа вызывает сброс.
Так как не у всех АВР есть способ вызвать сброс МК через запрос, то можно для этого WDT использовать.

Была ситуация, когда были заняты все таймеры. Я использовал WDT как дополнительный таймер с прерыванием от него.

Часы можешь сделать - 1 сек там есть

Для сброса хорошо написанной зависшей программы. Зависшей естественно обычно от внешних воздействий типа очень коротких помех или радиации.

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

Т.е программисту который полностью представляет все реально происходящие процессы WDT не нужен.


Не согласен.
Абсолютно любое поведение дачиков не должно приводить к зависанию программы.


Например?
Мне кажется что у добросовестно написанной программы как раз и не может быть непредусмотренных стечений обстоятельств.


Это Вы про радиацию?

У добросовестно написанной программы, занимающейся, условно говоря, управлением светодиодом от кнопки - возможно; в объемной и разветвленной системе, активно взаимодействующей с внешним миром, предусмотреть все и вся, и обеспечить 100% тестовое покрытие невозможно. И пусть вероятность возникновения "аварийного" стечения обстаятельств будет крайне низкой, следует предусмотреть надежный и безопасный выход из такой ситуации.

На мой взляд как раз в таких системах это просто необходимо и возможно.
А вот так вот недобросовестные программисты и обьясняют зависания своих недобросовестных программ.

Что поделать, слаб человек: и на МКС бортовые ЭВМ, бывает, зависают. Да что там далеко ходить, даже в уютном восьмибитном мирке не все справляются.
А если Вы полагаете, что "полностью представляете все реально происходящие процессы", значит, надо или переходить к более сложным процессам, или отказываться от иллюзий

Наоборот, сильно вдохновляет, что даже PC с виндами довольно редко виснут, с их гигабайтами и гигагерцами. Как-то даже не по себе. Какая реальная вероятность безотказной работы?

Если такой программист и существует, то только новичок или весьма самонадеянный человек.
Непредусмотренное стечение обстоятельств потому так и называется, что его невозможно предусмотреть. Именно из-за таких программистов потерян был "Фобос-грунт". После сеанса связи станция осталась ориентированной на Землю, бесконечно ждала сигнала "конец связи", который оператор просто забыл выдать. А гениальная программа не следила в это время за состоянием бортовых батарей. Они сели и станция замерзла.

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

Когда-то специально дал процессору несуществующую команду, хотел посмотреть что получится.
Собака не помогла, только общий сброс.

Мне кажется что непредусмотренное стечение обстоятельств это как раз такое стечение обстоятельств которое забыл или не смог предусмотреть программист.
А для обстоятельств которые предусмотреть невозможно должно быть другое определение.


Если это действительно так, то именно из за непредусмотренной ситуации это и произошло.



Сторожевой таймер существует не для предотвращения зависания а для выхода из оного.


Давайте не будем трогать MKC,windows и т.д. а только восьмибитный мирок (согласно ветке форума)


Вот в этом и пытаюсь разобраться.


Дайте критерий программы активно взаимодействующей с внешним миром.
Программа анализирующая кнопку и управляющая светодиодом тоже считает себя активно взаимодействующей с внешним миром.

так если нет Undefined exception, с чего бы собаке виснуть?
проц как распознал, так и выполнил, а прерывание таймера как работало, так и работает. Собака обновляется - значит и сброса нет

Вы, похоже, плохо знаете восьмибитный мирок. "Пионер" уже ушел за пределы Солнечной системы, облетел несколько планет, открыл несколько спутников, передал массу хороших цветных фотографий, выполнил сложнейшие баллистические расчеты по маневрированию и ориентации.
Так там 8-битный бортовой процессор и ..аж 8 кбайт памяти на все. И не завис за 30 лет.
Сейчас не каждый программист успеет на этом два светодиода зажечь.

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

В период обучения азам встречал у Микрочипа очень красивый пример с использованием WDT для вполне реальной задачи. Просто для переключения светодиодов. Можно было бы решить "её в лоб", но это слишком банально. А было продемонстрировано, как изящно может её решить настоящий программист.
Сейчас лень искать.

Неужели в пять команд вместе с включением WDT ?

так это значит не была предусмотрена защита от полного разряда... а так вообще-то станция должна постоянно передавать свою телеметрию

Она и передавала, но ушла за горизонт, а там принимать было некому.

Интересно, а есть ли в той системе WDT и если есть то сколько раз срабатывал за 30 лет?

Вообще-то срабатывание WDT для работы устройство должно быть мало заметно.
А в космической технике это переход в "безопасный режим" в который эта техника падает почти по каждому чиху. Без этого режима Пионер проходя через радиационные пояса Юпитера просто бы не выжил. А так отделался только потерей данных.

Опять радиация.
Согласен, влияние оной действительно предвидеть невозможно.

Получается что всё упирается только в радиацию? поскольку её влияние мы исключить полностью не можем нужно обязательно использовать WDT?

А что если эта самая радиация "убьёт" и WDT? Зависнем навсегда?

мы выпускаем радиометры для исследования урановых скважин, интенсивности попадаются до 20000мкР, применяю 8-битные AVR, WDT не использую

Нет, Всё упирается в наличие человека. WDT обязателен если устройство должно работать продолжительное время без отключения и нажатия на кнопку Reset. Ну и конечно чем сложнее программа тем опаснее сбой - в простых программах сбои незаметнее.

На чём пишете программы для этих радиометров?


очень растяжимые понятия

ассемблер... а какая разница?

Само собой расняжимые. Много от чего зависят. Чем чище и стабильнее питание и меньше воздействия радиации на камень, тем больше времени он может не сбоить. И т.к. процесс статистический, чем больше устройств выпущено, тем раньше можно заметить отсутствие WDT.
Потому и растяжимые.

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

Я так и предполагал.

Как только начинаешь использовать подпрограммы,библиотеки написанные не самим тут уже без WDT никак это точно


А если бы такую ситуацию предусмотрели то таймер был бы ненужен.


МКС вон единицы выпушено а отсутствие WDT уже заметно.

За двадцать лет мной разработано несколько десятков различных изделий на АТ90S,MEGA,XMEGA которые разошлись тиражами от сотни до десятков тысяч и ни в одном из них я никогда не использовал WDT.
Жалоб на какие либо зависания рабочих изделий небыло.

Странно. Особенно на AT90S. Разве что устройства не были автономными.


А причем тут МКС?

Да, конечно. Но тут я вспоминаю кадры старого фильма:
ПетрI: Продули битву почем зря...
Меншиков: Да, мингерц, продули-с... А вот если бы у нас была конница...
ПетрI: Так то ж если бы она была! Побеждать нужно уметь всегда!

Для сброса зависшего микроконтроллера с хорошо написанной программой? очевидно же.
Микроконтроллеры часто зависают при воздействии помех по питанию и т.п.
WDT должен использоваться обязательно, без вариантов.

Разрешая работу любого узла мк я обязательно должен убедиться в его работоспособности.

Как предлагаете проверить WDT? (советы убрать wdr не принимаются).

Просто проверить(wdr не убираем):

Если программа сбрасывается на >100500 МК значит WDT работает(при соответстующих условиях).



Это как бы обязательно. Но первый кандидат, почему программа не работает - это ваша программа. Но узлы МК тоже могут работать не так как задумывалось их разработчиками (xmega тому хороший пример).

Вы меня не поняли.
Разрешение/запрещение wdr путём опроса ноги или перекомпиляции проекта это не то.
Для полноценного теста работоспособности WDT и правильности расположения в программе команд wdr процессор должен именно подвиснуть и после этого сброситься именно от WDT.
Пишут : "часто зависают при воздействии помех по питанию и т.п."
Вот я и хочу как то воздействовать на питание или на т.п. с целью подвесить проц.
Как мне это сделать???




Разумеется.


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