реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> Как правильно использовать сторожевой таймер с РТОС?, wathdog timer, RTOS
Abcde
сообщение Feb 18 2018, 11:43
Сообщение #1





Группа: Новичок
Сообщений: 1
Регистрация: 9-03-16
Пользователь №: 90 775



Сейчас период таймаута выбран 0,5 сек, обнуление счетчика сторожевого таймера происходит в одной задаче РТОС, которая начинает выполняться только через 1 секунду после подачи питания (такая особенность). Получается сторожевой таймер срабатывает раньше…
Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?
Или задачи во время своего выполнения сами должны анализировать себя и сигнализировать выше, но если РТОС вытесняющая, то задача может прерваться и анализ оказаться неполным или не быть готовым к моменту принятия решения о сбросе по сторожевому таймеру. Как тут быть?
Обязательно ли проводить самодиагностику сторожевого таймера при подаче питания (когда ждем сброса по срабатыванию сторожевого таймера, а после него фиксируем успешность его работы и загружаемся как обычно). Но это ограничивает период таймаута сторожевого таймера, чтобы долго не загружать устройство.
Спасибо!
Go to the top of the page
 
+Quote Post
Den64
сообщение Feb 18 2018, 12:02
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 584
Регистрация: 22-11-07
Из: Курская область
Пользователь №: 32 571



Бывает что процессы зависают из-за ошибки алгоритма, но остальные работают. Всё управляется, обмены по интерфейсам идут, а результат не обновляется.
Сторожевой таймер ИМХО адекватно защищает только от железных зависаний. Т.е от грязи в питании, или остановки тактового генератора.
Разумное решение, на мой взгляд, это сбрасывать таймер в планировщике задач. Можно думаю и в отдельном процессе с самым низким приоритетом(если приоритеты конечно есть). Например все важные процессы устанавливают каждый свой флажок, а один из процессов изредка влючается и проверяет флаги. Если не все установлены то не сбрасывает таймер, а если все то сбрасывает все флаги и таймер.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Feb 18 2018, 13:29
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Abcde @ Feb 18 2018, 13:43) *
Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?

Завести отдельную задачу, которая будет периодически пинговать все остальные и не сбрасывать WDT до тех пор, пока очередная контролируемая задача не ответила на пинг.
Go to the top of the page
 
+Quote Post
Baser
сообщение Feb 18 2018, 13:31
Сообщение #4


Просто Che
*****

Группа: Свой
Сообщений: 1 567
Регистрация: 22-05-07
Из: ExUSSR
Пользователь №: 27 881



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

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

Цитата(Abcde @ Feb 18 2018, 13:43) *
Обязательно ли проводить самодиагностику сторожевого таймера при подаче питания (когда ждем сброса по срабатыванию сторожевого таймера, а после него фиксируем успешность его работы и загружаемся как обычно).

Про такое даже никогда не слышал, хотя возможно это и имеет смысл в параноидально-ответственных приложениях sm.gif
Go to the top of the page
 
+Quote Post
HardEgor
сообщение Feb 18 2018, 13:41
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 2 223
Регистрация: 3-03-06
Из: Tomsk
Пользователь №: 14 925



Цитата(Abcde @ Feb 18 2018, 18:43) *
Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)?

watchdog контролирует не задачу, а процессор - если вдруг он повис, то собачка его аппаратно перезагрузит.
А все остальные задачи пусть контролируют время своей работы по какому-нибудь таймеру, и если надо, перезапускают или сбрасывают зависшую часть.
Go to the top of the page
 
+Quote Post
haker_fox
сообщение Feb 19 2018, 00:44
Сообщение #6


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



QUOTE (Abcde @ Feb 18 2018, 19:43) *
Где должен обнуляться счетчик сторожевого таймера?

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

QUOTE (jcxz @ Feb 18 2018, 21:29) *
Завести отдельную задачу, которая будет периодически пинговать все остальные и не сбрасывать WDT до тех пор, пока очередная контролируемая задача не ответила на пинг.

Во! Интересная идея! +1!


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Feb 19 2018, 05:57
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Baser @ Feb 18 2018, 15:31) *
Нерегулярные задачи, которые могут не возникнуть за период сторожевика, не контроллирую.

Я контролирую все задачи. Нерегулярные в том числе (те, которые ждут какого-то события, потом его обрабатывают?) - посылаю им пинг (пустое событие), на который они должны ответить.
Все задачи построены в виде циклов ожидания/обработки события, схематически:
Код
while (1) {
  WaitForEvent(...);  //ожидание eventa ОС
  ILive(TASK_ID_...);
  if (!needForService) continue;
  ...
}

В ILive() контролируемая задача посылает контролирующей сообщение, что она жива (ставит флажок например).
Регулярные построены точно так же - без разницы.
Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().
Таким образом проверяется, что задача выполняет главный цикл своего функционирования (не заблокировалась например на каком-то ожидании или dead-lock-е) в хвосте главного своего цикла.
Go to the top of the page
 
+Quote Post
Arlleex
сообщение Mar 1 2018, 19:03
Сообщение #8


Местный
***

Группа: Участник
Сообщений: 492
Регистрация: 12-11-11
Пользователь №: 68 264



Цитата(jcxz @ Feb 19 2018, 08:57) *
Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive().
Таким образом проверяется, что задача выполняет главный цикл своего функционирования (не заблокировалась например на каком-то ожидании или dead-lock-е) в хвосте главного своего цикла.

На самом деле интересная идея, но не совсем понятно, как именно отслеживается зависание. Ну не ответила задача - вполне может быть, что у неё время выполнения большое. Не совсем понял Вашего механизма, если честно. Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю?
Go to the top of the page
 
+Quote Post
jcxz
сообщение Mar 1 2018, 20:37
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Arlleex @ Mar 1 2018, 21:03) *
Ну не ответила задача - вполне может быть, что у неё время выполнения большое.

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

Цитата(Arlleex @ Mar 1 2018, 21:03) *
Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю?

Никак. Он должен быть меньше времени таймаута WDT.
Go to the top of the page
 
+Quote Post
Forger
сообщение Mar 3 2018, 17:53
Сообщение #10


Профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(Abcde @ Feb 18 2018, 14:43) *
Как правильно использовать сторожевой таймер с РТОС?

В любом нормальном CPU сторожевой таймер имеет т. н. "оконный" принцип работы, т. е. сбрасывать его нужно не позже и не раньше заранее настроенного времени.
Это - очень удобный и полезный механизм.
Я использую его очень просто - создаю отдельную задачу, которая сбрасывает WDT через строго заданные интервалы времени (разумеется, допускается определенная погрешность).
Задача эта имеет самый низкий приоритет, фактически на уровне приоритета задачи Idle.
Как тут уже было сказано выше - WDT нужен для борьбы с зависаниями CPU, точнее, "заклиниваем" любой из задач.
Фактически, WDT я использую для неожиданных выходов уровня загрузки CPU до 100%.
Если код спроектирован достаточно грамотно, то этого никогда не произойдет, но в ответственных приложениях WDT - обязательная вещь.

Однако, использовать его нужно правильно, иначе проку от него никакого не будет:
самая частая ошибка начинающих "программистов" - сбрасывать WDT где попало, например, в планировщике или в Idle задаче.
В этих случаях вся полезность WDT напрочь "убивается"! smile3046.gif

зы. Я уже не говорю про случаи сброса WDT в прерываниях - за подобное кощунство подобного горе-"программиста" следует навсегда изгонять из профессии maniac.gif


--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
Go to the top of the page
 
+Quote Post
ViKo
сообщение Mar 3 2018, 18:33
Сообщение #11


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



1. Впервые слышу про сторожевой таймер в МК, который должен быть сброшен не ранее определенного времени.

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

3. Сбрасывать сторожевой таймер в планировшике - хорошая идея, если это возможно.

4. Сбрасывать сторожевой таймер в прерываниях - в корне неверно, поскольку основная программа может уже безнадежно висеть.

5. Если РТОС зависает из-за неправильно заданной передачи управления между задачами, то таймер нужно встроить программисту в нутро.
Go to the top of the page
 
+Quote Post
Forger
сообщение Mar 3 2018, 18:44
Сообщение #12


Профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(ViKo @ Mar 3 2018, 21:33) *
1. Впервые слышу про сторожевой таймер в МК, который должен быть сброшен не ранее определенного времени.
(С) "Век живи - век учись!" wink.gif
Например, в STM-ках есть WWDT - Window WDT...
Вообще, в идеале, WDT должен тактироваться от собственного независимого генератора (в нормальных МК есть даже несколько разных WDT, в т.ч. "аналоговых").
При схеме, которую я описал выше, любой сбой системной частоты, от которой тактируется системный таймер ОС, вызовет несвоевременный сброс WDT, что вызовет всегда сброс проца.
Т. е. оконный WDT позволяет еще и бороться со сбоями тактовой частоты (банально коснулись пальцем выводов кварца), т. е. WDT "контролирует" связь приложения с реальным временем.

Цитата
3. Сбрасывать сторожевой таймер в планировшике - хорошая идея, если это возможно.

Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда безусловно "благодаря" прерываниям от системного таймера и сервисами ОС, вызываемыми из других прерываний (семафоры/сообщения из прерываний).
Приложение давно висит, но данные снаружи сыпятся, вызывают прерывания, те уже семафорят (будят) задачи и тем самым безусловно вызывают планировщик, а тут сбрасывается WDT ... короче, в такой схеме WDT вообще бесполезен!

Фактически это то же самое, что и сбрасывать WDT в прерываниях:
Цитата
4. Сбрасывать сторожевой таймер в прерываниях ....




Цитата
5. Если РТОС зависает из-за неправильно заданной передачи управления между задачами, то таймер нужно встроить программисту в нутро.

WDT в принципе не должен ничего знать о принципах и стратегиях построения приложения. WDT - полностью независимый "орган", и работать он должен не предвзято.
Проект может меняться как угодно, а WDT - как работал так и должен работает. Ему все это должно быть "до лампочки". В противном случае проку от такого WDT не будет.
Кстати, в серьезных проектах работа WDT всегда проверяется - пишутся соотв. тесты, в т. ч. аппаратные: сбои тактирования, питания, повреждения содержимого ОЗУ (например, радиацией для соотв. применений).


--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
Go to the top of the page
 
+Quote Post
Den64
сообщение Mar 3 2018, 19:53
Сообщение #13


Знающий
****

Группа: Свой
Сообщений: 584
Регистрация: 22-11-07
Из: Курская область
Пользователь №: 32 571



У меня в домашней автоматике, периодически, зависает одна задача. Примерно раз в день. Просто передёргиваю питание, могу себе такое позволить. Лень ошибку устранить.
Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду? Ну и будет отдельный процесс сбрасывать, а другой висеть или завершился (бес его знает что там).
100% защиты от софтовой ошибки WDT не даст, да и от аппаратной. Это понятно. Но вот смысл сбрасывать в отдельной низкоприоритетной задаче вижу только в защите от сильной загрузки процессора, и то только в момент сброса. Процессор может быть загружен пол секунды, а в момент работы процесса сброса процессор свободен. Непонятно.

Цитата(Forger @ Mar 3 2018, 21:44) *
Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда

Планировщик это вообще то не одна строчка кода. И варианты не только перед и после этой строчки.
Go to the top of the page
 
+Quote Post
Forger
сообщение Mar 3 2018, 21:26
Сообщение #14


Профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 22-02-05
Пользователь №: 2 831



Цитата(Den64 @ Mar 3 2018, 22:53) *
У меня в домашней автоматике, периодически, зависает одна задача. Примерно раз в день. Просто передёргиваю питание, могу себе такое позволить. Лень ошибку устранить.
Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду?

Тут WDT вообще не поможет. Тут - проблема другого характера:
Цитата
"лень ошибку устранить"




Цитата
100% защиты от софтовой ошибки WDT не даст, да и от аппаратной. Это понятно.
WDT существует не для борьбы с ошибками, а совсем для другого - как минимум для защиты от некоторых непредвиденных ситуаций.
WDT создан лишь как дополнение к существующим методам защиты, но не их замена.
Грамотное применение WDT позволить реализовать все его возможности, а не создавать иллюзию от его якобы пользы.

Цитата
Но вот смысл сбрасывать в отдельной низкоприоритетной задаче вижу только в защите от сильной загрузки процессора, и то только в момент сброса.
В момент сброса процессор сброшен и ничего у него не работает. Вы о чем?

Цитата
Процессор может быть загружен пол секунды
Если это время измеряется в секундах, то период WDT также должен быть настроен на аналогичный интервал.
А вообще real-time приложение НИКОГДА не должно быть загружено на 100% более, чем допустимое (детерминированное) время реакции на любое событие системы!
В данном случае - полсекунды - это огромное время, за которое в реальном устройстве может успеть произойти очень много неприятностей.

Цитата
Непонятно.
Читаем матчасть!



Цитата
Планировщик это вообще то не одна строчка кода. И варианты не только перед и после этой строчки.
Да хоть 500 тыщ строк кода, сути это не меняет.
Угробить функционал WDT очень просто - достаточно лишь сбрасывать его где надо и не надо wink.gif


--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
Go to the top of the page
 
+Quote Post
Den64
сообщение Mar 3 2018, 22:31
Сообщение #15


Знающий
****

Группа: Свой
Сообщений: 584
Регистрация: 22-11-07
Из: Курская область
Пользователь №: 32 571



Цитата(Forger @ Mar 4 2018, 00:26) *
В момент сброса процессор сброшен и ничего у него не работает. Вы о чем?
...
В данном случае - полсекунды - это огромное время, за которое в реальном устройстве может успеть произойти очень много неприятностей.
...
Читаем матчасть!

я тоже могу начать переводить тему, коверкать смысл, демагогией заниматься, тролить...
Цитата(Forger @ Mar 4 2018, 00:26) *
WDT существует не для борьбы с ошибками, а совсем для другого - как минимум для защиты от некоторых непредвиденных ситуаций.

А если по теме. Произошла непредвиденная ситуация (любая, не ошибка софта. Это я для примера писал), не работает один процесс. Как поможет тот пример, что Вы привели, восстановить работу?
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 28th July 2025 - 00:45
Рейтинг@Mail.ru


Страница сгенерированна за 0.0153 секунд с 7
ELECTRONIX ©2004-2016