|
Как правильно использовать сторожевой таймер с РТОС?, wathdog timer, RTOS |
|
|
|
Feb 18 2018, 11:43
|
Группа: Новичок
Сообщений: 1
Регистрация: 9-03-16
Пользователь №: 90 775

|
Сейчас период таймаута выбран 0,5 сек, обнуление счетчика сторожевого таймера происходит в одной задаче РТОС, которая начинает выполняться только через 1 секунду после подачи питания (такая особенность). Получается сторожевой таймер срабатывает раньше… Где должен обнуляться счетчик сторожевого таймера? Сейчас он обнуляется в одной из задач РТОС, почти безусловно, т.е. контролируется только правильность работы этой задачи. Как контролировать остальные, особенно если они взаимосвязанные (ждут результатов работы других задач)? Или задачи во время своего выполнения сами должны анализировать себя и сигнализировать выше, но если РТОС вытесняющая, то задача может прерваться и анализ оказаться неполным или не быть готовым к моменту принятия решения о сбросе по сторожевому таймеру. Как тут быть? Обязательно ли проводить самодиагностику сторожевого таймера при подаче питания (когда ждем сброса по срабатыванию сторожевого таймера, а после него фиксируем успешность его работы и загружаемся как обычно). Но это ограничивает период таймаута сторожевого таймера, чтобы долго не загружать устройство. Спасибо!
|
|
|
|
|
Feb 18 2018, 13:31
|

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

|
Обычно период сторожевика выбирают от внешних условий работы. Чем ответственней применение и чем печальней могут быть последствия подвисания МК, тем меньше период. И уже исходя из периода так планируют программу, чтобы при нормальной работе софта гарантированно уложиться до автосброса. Я обычно обслуживаю сторожевик в средне-низкоприоритетной задаче, которая вызывается регулярно со временем в несколько раз чаще периода сторожевика. Остальные важные регулярные задачи выставляют флаги, а та задача исходя из них сбрасывает сторожевик. Нерегулярные задачи, которые могут не возникнуть за период сторожевика, не контроллирую. Цитата(Abcde @ Feb 18 2018, 13:43)  Обязательно ли проводить самодиагностику сторожевого таймера при подаче питания (когда ждем сброса по срабатыванию сторожевого таймера, а после него фиксируем успешность его работы и загружаемся как обычно). Про такое даже никогда не слышал, хотя возможно это и имеет смысл в параноидально-ответственных приложениях
|
|
|
|
|
Feb 19 2018, 00:44
|

Познающий...
     
Группа: Свой
Сообщений: 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!
--------------------
Выбор.
|
|
|
|
|
Feb 19 2018, 05:57
|
Гуру
     
Группа: Свой
Сообщений: 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-е) в хвосте главного своего цикла.
|
|
|
|
|
Mar 1 2018, 19:03
|

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

|
Цитата(jcxz @ Feb 19 2018, 08:57)  Контролирующая, после установки состояния "проверка состояния задачи TASK_ID...", перестаёт генерить WDI до того момента, пока контролируемая задача не вызовет ILive(). Таким образом проверяется, что задача выполняет главный цикл своего функционирования (не заблокировалась например на каком-то ожидании или dead-lock-е) в хвосте главного своего цикла. На самом деле интересная идея, но не совсем понятно, как именно отслеживается зависание. Ну не ответила задача - вполне может быть, что у неё время выполнения большое. Не совсем понял Вашего механизма, если честно. Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю?
|
|
|
|
|
Mar 1 2018, 20:37
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(Arlleex @ Mar 1 2018, 21:03)  Ну не ответила задача - вполне может быть, что у неё время выполнения большое. Не должно быть такого. У любой задачи должно быть строго известное время максимальной задержки ответа. Не ответила - перезагрузка. Цитата(Arlleex @ Mar 1 2018, 21:03)  Да и период пингуюшей задачи, не понятно, должен ли как-то зависеть от периодов задач, которые подвергаются контролю? Никак. Он должен быть меньше времени таймаута WDT.
|
|
|
|
|
Mar 3 2018, 17:53
|

Профессионал
    
Группа: Свой
Сообщений: 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 напрочь "убивается"!  зы. Я уже не говорю про случаи сброса WDT в прерываниях - за подобное кощунство подобного горе-"программиста" следует навсегда изгонять из профессии
--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
|
|
|
|
|
Mar 3 2018, 18:44
|

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

|
Цитата(ViKo @ Mar 3 2018, 21:33)  1. Впервые слышу про сторожевой таймер в МК, который должен быть сброшен не ранее определенного времени. (С) "Век живи - век учись!"  Например, в STM-ках есть WWDT - Window WDT... Вообще, в идеале, WDT должен тактироваться от собственного независимого генератора (в нормальных МК есть даже несколько разных WDT, в т.ч. "аналоговых"). При схеме, которую я описал выше, любой сбой системной частоты, от которой тактируется системный таймер ОС, вызовет несвоевременный сброс WDT, что вызовет всегда сброс проца. Т. е. оконный WDT позволяет еще и бороться со сбоями тактовой частоты (банально коснулись пальцем выводов кварца), т. е. WDT "контролирует" связь приложения с реальным временем. Цитата 3. Сбрасывать сторожевой таймер в планировшике - хорошая идея, если это возможно. Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда безусловно "благодаря" прерываниям от системного таймера и сервисами ОС, вызываемыми из других прерываний (семафоры/сообщения из прерываний). Приложение давно висит, но данные снаружи сыпятся, вызывают прерывания, те уже семафорят (будят) задачи и тем самым безусловно вызывают планировщик, а тут сбрасывается WDT ... короче, в такой схеме WDT вообще бесполезен! Фактически это то же самое, что и сбрасывать WDT в прерываниях: Цитата 4. Сбрасывать сторожевой таймер в прерываниях .... Цитата 5. Если РТОС зависает из-за неправильно заданной передачи управления между задачами, то таймер нужно встроить программисту в нутро. WDT в принципе не должен ничего знать о принципах и стратегиях построения приложения. WDT - полностью независимый "орган", и работать он должен не предвзято. Проект может меняться как угодно, а WDT - как работал так и должен работает. Ему все это должно быть "до лампочки". В противном случае проку от такого WDT не будет. Кстати, в серьезных проектах работа WDT всегда проверяется - пишутся соотв. тесты, в т. ч. аппаратные: сбои тактирования, питания, повреждения содержимого ОЗУ (например, радиацией для соотв. применений).
--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
|
|
|
|
|
Mar 3 2018, 19:53
|

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

|
У меня в домашней автоматике, периодически, зависает одна задача. Примерно раз в день. Просто передёргиваю питание, могу себе такое позволить. Лень ошибку устранить. Ну вот как защитит WDT если, я просто запущу ещё один процесс который будет сбрасывать таймер допустим раз в секунду? Ну и будет отдельный процесс сбрасывать, а другой висеть или завершился (бес его знает что там). 100% защиты от софтовой ошибки WDT не даст, да и от аппаратной. Это понятно. Но вот смысл сбрасывать в отдельной низкоприоритетной задаче вижу только в защите от сильной загрузки процессора, и то только в момент сброса. Процессор может быть загружен пол секунды, а в момент работы процесса сброса процессор свободен. Непонятно. Цитата(Forger @ Mar 3 2018, 21:44)  Если планировщик вытесняющий, то это - абсолютно плохая плохая идея!!! , поскольку тогда WDT будет сбрасывает всегда Планировщик это вообще то не одна строчка кода. И варианты не только перед и после этой строчки.
|
|
|
|
|
Mar 3 2018, 21:26
|

Профессионал
    
Группа: Свой
Сообщений: 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 очень просто - достаточно лишь сбрасывать его где надо и не надо
--------------------
Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".
|
|
|
|
|
Mar 3 2018, 22:31
|

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

|
Цитата(Forger @ Mar 4 2018, 00:26)  В момент сброса процессор сброшен и ничего у него не работает. Вы о чем? ... В данном случае - полсекунды - это огромное время, за которое в реальном устройстве может успеть произойти очень много неприятностей. ... Читаем матчасть!я тоже могу начать переводить тему, коверкать смысл, демагогией заниматься, тролить... Цитата(Forger @ Mar 4 2018, 00:26)  WDT существует не для борьбы с ошибками, а совсем для другого - как минимум для защиты от некоторых непредвиденных ситуаций. А если по теме. Произошла непредвиденная ситуация (любая, не ошибка софта. Это я для примера писал), не работает один процесс. Как поможет тот пример, что Вы привели, восстановить работу?
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|