Нужны рекомендации по использованию whatchdog

Допустим, при обновлении системы на новый образ что-то зависло. Watchdog перезагрузит систему в резервный/предыдущий слот. barebox имеет поддержку redundancy, к примеру.

Проекты хоббийные, на stm32

Про stm32 вообще ничего не знаю. Там линукс поднимается вообще?

простой критерий нужен ли вам watchdog: если вы не знаете, как пишется watchdog — он вам не нужен

Там нет линукса, это совсем мелкие эмбеды. Cortex M0…M4, 128K Flash, 8-16K RAM.

Кейз с прошивкой понял, тут пожалуй не критичннo. Другие варианты возможны? Говноразводку питания и hard fault от деления на ноль не рассматриваем (лечить такое вочдогами - это за гранью добра и зла).

Конкретный пример приводить не буду, а в общем мы на старой работе обмазывали ими:

• железяки, которые иногда самостоятельно висли намертво. Например RPi2 с некоторым софтом.
• собственно, софт, который было особо не переписать, но заставить кикать таймер (плагинами, расширениями).

Проекты хоббийные

Допустим, при старте железка инициализируется в безопасное состояние: закрыть кран. А в процессе работы кран открывается на какое-то время, производятся какие-то действия, потом кран нужно закрыть. Но что-то идёт не так и…

С простым watchdog железка хотя бы просто перезапустится и проинициализируется так, что кран закроется.

и hard fault от деления на ноль не рассматриваем (лечить такое вочдогами - это за гранью добра и зла).

Когда железка работает только под присмотром - без проблем: ведь сам по сути и выступаешь в роли сторожевого пса. А если железку надо оставить без присмотра…

Wathcdog не для лечения, а для предохранения от тяжёлых последствий.

А я как раз спрашиваю конкретные примеры. Потому что железки и софт рисую сам. И обмазываться вочдогами прозапас нафик не вперлось.

Это все конечно здорово, но хотелось бы услышать конкретные условия, из-за которых MCU может сойти с ума. Или вероятность что он сойдет с ума просто так.

Представь себе контроллер микроволновки. Там настолько простой софт, что все его состояния детерминированы. Это не линукс с сотней модулей от индийских контракторов.

Я обозначил следующий критерий нужности: отсутствие возможности исправить причины отказов.

Ну там с рядом поправок: софт работает плохо, но всё равно нужен, периодические сбои — это поведение, которое приходится считать нормальным и т.д.

Короче говоря, свои поделки я этим делом не обмазывал, потому что в необходимости не возникало.

UPD: а, я изначальный контекст не так понял. Не подскажу ничего дельного тогда :)

Сегодня что, парад тупняка пятизвёздочников?

В двух словах: отсутствие в проекте сторожевого таймера - признак полной некомпетентности разработчика. No exceptions.

В трёх словах: любой контроллер может зависнуть или серьёзно отклониться от выполнения программы в результате аппаратного сбоя. Помехи на шинах данных или питания, проблемы с тактированием, перегрев, электромагнитная чепуха, уникальные дефекты чипа - абсолютно что угодно. Управляемая им периферия при этом остаётся в непредсказуемом состоянии и может выйти из строя и/или нанести ущерб твоей сычевальне. Простой пример - мозг микроволновки зависнет и не отключит разогрев курочки.

все его состояния детерминированы

Кек.

Вообще, как ни печально, WDT - не панацея. Далеко не всякий сбой приводит к зависанию контроллера и сбросу по таймауту, часто можно словить запрет/разрешение прерываний, самопроизвольный запуск таймеров, неадекватные переходы в условиях, вот это вот всё. По своему опыту могу сказать, что большие проекты в силу своей хрупкости менее подвержены влиянию этой дряни, а «десятистрочники» после сбоя могут не сброситься, а продолжить работу хрен пойми как.

по моему опыту, пока человек самостоятельно не придёт к мысли «вот бы тут поставить такую штуку, которая независимо от всего будет проверять статус» — объяснять ему бесполезно, он так и будет хлопать глазками «у меня всё под контролем, тут ломаться нечему»

нехай набивает шишки, это полезно.

отсутствие в проекте сторожевого таймера - признак полной некомпетентности разработчика.

ДАТЫШО?!! Серьезно? Прям вот так вот? Нц-нц-нц…как жить, как жить теперь…

Простой пример - мозг микроволновки зависнет и не отключит разогрев курочки.

Ага, и именно поэтому мы отдадим это на откуп сторожевому песику, который реализован на, как ты выразился, чипе, в котором могут быть «уникальные дефекты чипа»

Откуда ты такой категоричный взялся?

Вообще, как ни печально, WDT - не панацея.

КАААК?! Ты ж толькочто строчкой выше утверждал, что:

отсутствие в проекте сторожевого таймера - признак полной некомпетентности разработчика

Быстро ж ты переобуваешься в воздухе!

В любом софте бывают баги (а во встраиваемых системах помимо софтовых бывают ещё и аппаратные вроде неудачной разводки платы). От хоббийных проектов на ардуине до Боингов. Не ошибается лишь тот, кто ничего не делает. Watchdog очень простой и дешёвый способ ограничить ущерб и получить дополнительную уверенность в том, что систему безопасно оставлять без присмотра. В более ответственных случаях делают ещё и резервирование систем, но это уже удорожание конструкции и изменение архитектуры по, а таймер можно добавить очень быстро и бесплатно по железу.

От обнаружения бага до исправления может пройти время, а намертво зависший контроллер за это время может причинить ущерб. Выше уже привели пример с краном. Да, ты обновишь прошивку, но залитым соседям платить всё равно придётся. Если что watchdog никак не мешает логгировать факты зависания, у большинства контроллеров есть всякие флаги причины рестарта. Так что ошибку не пропустишь, если захочешь.

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

Говноразводку питания и hard fault от деления на ноль не рассматриваем (лечить такое вочдогами - это за гранью добра и зла).

Но такое неизбежно иногда происходит. Просто у новичка часто, а у профессионала очень редко. Но гораздо приятнее если система будет работать хоть как-то, а ущерб от её сбоя будет ограничен, пока ты будешь искать ошибку и исправлять её.

Логика уровня «не буду включать поворотники, вдруг они не работают».

Ремень безопасности не панацея, но это не аргумент его не пристегивать. Просто ты должен понимать, что даже если пристегнулся, ездить под 100 км/ч и игнорировать светофоры всё равно не стоит. Пример с поворотниками выше тоже очень хорош. Их использование не гарантирует на 100%, что в тебя никто не влетит при повороте, однако что-то мало кто будет доказывать с пеной у рта, что они не нужны.

Логика уровня «не буду включать поворотники, вдруг они не работают».

Нет. Это логика типа «включать поворотник только тогда, когда нужно включать поворотник. А не при любом удобном случае.»

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

ТЫЦ!

Watchdog очень простой и дешёвый способ ограничить ущерб и получить дополнительную уверенность в том, что систему безопасно оставлять без присмотра.

Кроме тех случаев, когда нужна уверенность, что ничего не случится с самим устройством/чипом. Как в случае с резервированием. Там всем плевать на сторожевого пса, его там никто не реализует. Контроль резервирования осуществляет независимый модуль. Но это да, совершенно другой класс устройств и ответственности.

а во встраиваемых системах помимо софтовых бывают ещё и аппаратные вроде неудачной разводки платы

как будто их не во встраиваемых не бывает

почему на дескопы-ноутбуки-смартфоны сторожевых собак массово не вешают? )

И какая разница, встроенный таймер используется или внешний монитор, если цель, результат, а зачастую и реализация одинаковы?

Вешают, просто не на перезапуск ОС. Примерно во всех программируемых мультиконтроллерах есть вачдог, во многих - интеграция со внешними схемами слежения, например.

почему на дескопы-ноутбуки-смартфоны сторожевых собак массово не вешают?

В смысле не вешают? В прошивках есть. Не везде, но вешают.

И какая разница, встроенный таймер используется или внешний монитор, если цель, результат, а зачастую и реализация одинаковы?

А такая разница, что в случае с косячным чипом у тебя нет и не может быть доверия к встроенному в этот чип механизму watchdog. Логично ж, ну?

Ну так помимо косячного чипа может быть (и куда вероятнее) косячный код. И от него watchdog вполне поможет.

внешний watchdog тоже может оказаться косячным, будет непрерывно ресетить исправно работающий чип )

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

Система может упасть просто так. От залетевшего нейтрино. Но вот я спрашиваю у всех статистику падений (кроме кривого софта), а мне вместо статистики «надо вочдог потомушта дидызавещали».

И второй вопрос был по приворачиванию. Потому что если повесить сброс вочдога на прерывание от таймера, толку будет не особо. Ответы тоже из серии «вы главное повесьте, а оно уж чего-нибудь навочдожит».

Хотелось бы в нюансах разобраться, а не на одной духовности код клепать.

Но вот я спрашиваю у всех статистику падений (кроме кривого софта), а мне вместо статистики «надо вочдог потомушта дидызавещали».

Статистика будет зависеть от 100500 условий, поэтому будет логичнее, если ты сам посчитаешь её на первой партии твоих устройств и по результатам решишь, нужен ли вочдог в следующей ревизии или нет

Чаще всего МК виснут при помехах на тактировании. у STM есть переход в аварийный режим с тактированием от внутреннего источника при сбое внешнего, но он, как правило, спасает только при сбое тактирования, но не при лишних пиках. AVRки лишены даже этого и начинают творить трэш при недостаточном размахе тактового сигнала.

Ещё AVR часто виснут при отрицательных пиках на IO, видимо, защитные диоды фигово справляются со своей функцией. На STM с таким характером помех не сталкивался, хз.

По поводу «навочдожит» - я раскидываю установку флагов во все значимые места, в которых код выполняется периодически - таймеры, автоматические прерывания АЦП, важные блоки основного цикла, и периодически проверяю, все ли флаги взвелись. Если да, то обнуляю их и сбрасываю wdt. Это позволяет снизить количество отказов из-за произвольного отключения периферии.

Ну так помимо косячного чипа может быть (и куда вероятнее) косячный код.

Ну дык и watchdog можно косячно оформить, коли на то пошло :)

А вообще разговор пошел с того, что мол его надо пихать повально везде и вообще если ты не используешь его для своего очередного контроллера для гирлянды, то ты быдло. Так вот я начал агриться именно на эту мысль, а не на факт использования watchdog. Используй, ради Дарвина! Сколько тебе влезет. Просто понимать надо что в 90% случаев, где нужен сторожевой пес, реализовывать его в том же чипе настолько же глупо, насколько искать кофетерий в лепрозории.

Было у меня такое в пору нубости :)

Там как правило на жесткой логике монитор в не самых ответственных случаях, и целая независимая служба, отслеживающая несколько условий для сработки. Так что там уже настолько параноидально все получается, что «нуянезнаючодолжнослучицца».

ты же упёрся рогом в недостатки одной из реализаций и несёшь пургу.

Я уперся только в ту пургу, которую начал нести ты, не сливай тут стрелки.

А про нужность watchdog и говорить не надо. ТСу еще в первых сообщениях все ответили.

Но вот я спрашиваю у всех статистику падений

Конкретно в случае с радиоуправляемыми моделями пихать нужно обязательно, ибо юзвери любят пускать свои коптеры возле ЛЭП или в грозу. Там статистика близка к 100%

И второй вопрос был по приворачиванию. Потому что если повесить сброс вочдога на прерывание от таймера

Watchdog ващет сам есть таймер, счетчик которого надо успевать обнулять, иначе ресетнет чип. И это и есть главный нюанс. Разбираться не в чем.

Статистика будет зависеть от 100500 условий, поэтому будет логичнее, если ты сам посчитаешь её на первой партии твоих устройств и по результатам решишь, нужен ли вочдог в следующей ревизии или нет

Нифига подобного! Есть вещи, где прям Докинз завещал пихать его. Когда устройство может оказаться под жестким внешним воздействием либо получить адскую хрень на вводе от человекопользователя вместо требуемой величины. Тут никакую статистику считать не надо.

Конкретно в случае с радиоуправляемыми моделями пихать нужно обязательно, ибо юзвери любят пускать свои коптеры возле ЛЭП или в грозу. Там статистика близка к 100%

Сенькс, это очень годный пример.

Watchdog ващет сам есть таймер, счетчик которого надо успевать обнулять, иначе ресетнет чип. И это и есть главный нюанс. Разбираться не в чем.

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

А доступ к event loop есть далеко не везде. В той же rtos непонятно куда втыкать, чтобы результат был не для галочки.

О, годный принцип для RTOS. Спасибо.

А вот если я не загоняю контроллер в sleep и не встаю под ЛЭП, есть повод переживать? Тактирование у меня либо внутреннее, либо от генератора, чтобы с кварцами не уродоваться. Внешних незащищенных интерфейсов, с которых может кака прилететь, особо нет.

Чаще всего МК виснут при помехах на тактировании.

Это можно считать как выполнение произвольной инструкции вместо нужной или там какой-то более узкий набор дефектов? Если я правильно понимаю, то на stm32 незапланированный такт - это с большой вероятностью продолбанный тайминг при чтении флеша.

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

Ну, вот ты и ответил сам себе на все важные вопросы :) Пиши так, чтоб watchdog сбрасывался не в теле обработчика прерываний. Да и обработку прерываний нужно как можно короче делать. А в остальном уже по ситуации.

А доступ к event loop есть далеко не везде. В той же rtos непонятно куда втыкать, чтобы результат был не для галочки.

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

А вот если я не загоняю контроллер в sleep и не встаю под ЛЭП, есть повод переживать?

Здесь надо сначала перечислить весь список того, что ты НЕ делаешь и только после этого отвечать. Если исключены все виды ЭМП помех, не летают ионы, не светят лазеры и нет прочих «возбудителей», то в общем-то смысла нет. Скорее даже помешает, ибо придется помимо основной проблемы сначала разбираться какого ляда пес сработал.

Внешних незащищенных интерфейсов, с которых может кака прилететь, особо нет.

Статика прикосновения, пьезоэффект в тактовом генераторе от вибрации? Если нет или уверен в принятых мерах защиты, то забей.

Это можно считать как выполнение произвольной инструкции вместо нужной или там какой-то более узкий набор дефектов?

Нет, там все проще. На тактовом входе контроллера как правило реализован триггер Шмидта. Просто такт не сработает. Если тактовый генератор одновременно является генератором импульсов для каких-то внешних счетчиков, то это проблема. Если ничего, кроме как сам контроллер генератор не тактирует, то забей. Здесь намного выгоднее не watchdog лепить, а ставить какой-то внешний логгер проблем по питанию. Хотя в хоббийных проектах вряд-ли такое встречается.

sleep

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

набор дефектов

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

повод переживать

Зачем переживать, если можно не переживать? В простейшем случае вся работа с wdt - это 3 строки:

#include <avr/wdt.h> // без комментариев
wdt_enable(WDTO_2S); //при инициализации
wdt_reset(); //в основном цикле

и всё, в 95 случаях из 100 девайс при сбое сам перезапустится.

Пиши так, чтоб watchdog сбрасывался не в теле обработчика прерываний.

Гы, дык в этом и заключался один из вопросов - какие есть паттерны программирования для приворачивания вочдогов. Вот [user]izzholtik[/user] предложил по сути групповой семафор, где все таски должны отметиться. Может еще как-то можно.

Ваще не понял, как это касается слипа

На SO видел упоминание забавного бага, кажется в stm32f0. При выходе из слипа иногда PLL коряво подхватывался и частоту в 6 раз меньше выдавал.

Зачем переживать, если можно не переживать? В простейшем случае вся работа с wdt - это 3 строки:

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

Хочу разобраться в сути, чтобы понимать где и как втыкать. На суперлупе три строчки прокатят, а в RTOS это уже конкретный зашквар и лучше объединять флаги из всех задач, как ты выше посоветовал.

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

Судя по описанию, оно просто на куски разваливается :). А не могут быть просто чипы изначально говно? Вроде в современных ARM и мониторы питания, и задержки для стабилизации кварца.

Очень давно, когда сваливал с PIC на AVR, заметил их меньшую устойчивость, когда рисовал 10-20-амперные регули для моторчиков в радиомодели. Но это было очень давно. Сейчас stm32 использую.

Та не, вполне нормальные глюки, когда кто-то пальцем в выводы кварца тыкает. Хотя и контрафакт искючать нельзя, возможно, ъ-оригинал стабильнее.

Спасиб. Ты и Oberstserj мне очень помогли в практическую сторону вопроса нормально въехать.

Пойду дальше нести свет современной электроники в мир хоббистов https://hackaday.io/projects/hacker/440909 :)