Как правильно использовать сторожевой таймер с РТОС?, wathdog timer, RTOS Опции

[Abcde]

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

[Den64]

Ваши слова?

Как мои слова связаны с

В вашем примере - задача, которая может тупить (загружает проц. на 100%) слишком долго (намного дольше допустимого времени реакции системы на сбой),..

?


Вытесняющая многозадачность. Задача зависла или завершилась и не работает и не кому не мешает, и не грузит на 100% наверняка. Хотя точно не знаю, не принципиально и не интересно. Но ваши способности удалённо читать "мысли" микроконтроллера поражают.

[Forger]

Вытесняющая многозадачность.

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

Код

void someTask(...)
{
  while (true) {}
}

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

Задача зависла или завершилась и не работает и не кому не мешает, и не грузит на 100% наверняка.

Зависшася задача, которая не потребляет ресурсов - это задача, которая ждет некого внешнего события: семафор, сообщение.
Если этого события нет, то это задача тут ни при чем, искать нужно того, что не прислал нужного сообщения. Такие ошибки не решит никакой WDT.
Другой же случай: задача зависла (например, бесконечно полит некий флажок или крутится в бесконечном цикле), то такая задача загружает проц на 100%.
Такая ситуация сама по себе не возникает, но мое решение с WDT с ней борется на все 100%.
Ибо в реальном устройстве, которое, например, управляет внешней силой, подобные зависания могут привести к печальным последствиям.
И потому способ борьбы должен быть максимально аппаратным, вплоть до установки внешнего WDT, который сбрасывается точно также, но уже дерганием ножки проца в такой же самой низкоприоритетной задаче.

Но ваши способности удалённо читать "мысли" микроконтроллера поражают.

Вы зря одушевляете голую железку, приписывая ей некие "мысли"
Когда знаешь как она устроена, и как устроен софт на ней (OCь), то умение "читать мысли" не требуется - оно и так все понятно

[Den64]

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

Код

void someTask(...)
{
  while (true) {}
}

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

Согласен. Вылетело из головы. Но у меня это не сработает, кроме приоритетов у задач задаю квант времени работы. (хотя скорей всего сработает, не проверял)

Вы зря одушевляете голую железку, приписывая ей некие "мысли"
Когда знаешь как она устроена, и как устроен софт на ней (OCь), то умение "читать мысли" не требуется - оно и так все понятно

Мысли в кавычках.

[Forger]

Согласен. Вылетело из головы. Но у меня это не сработает, кроме приоритетов у задач задаю квант времени работы. (хотя скорей всего сработает, не проверял)

Квант времени работает ТОЛЬКО для задач с равным приоритетом, он всегда измеряется в периодах системного таймера, в котором вызывается шедулер.
Это квант (slice) дает возможность работать другим задачам с РАВНЫМ приоритетом.
В остальном - все то же самое: все низкоприоритные задачи ждут, пока им не достанется чуток процессорного времени.
По крайней мере так сделано во всех ОСях, которые поддерживают time slice.
Подобная штука категорически необходима для проектов, где ВСЕ задачи имеют равный приоритет.

[Den64]

Квант времени работает ТОЛЬКО для задач с равным приоритетом, он всегда измеряется в периодах системного таймера, в котором вызывается шедулер.
Это квант (slice) дает возможность работать другим задачам с РАВНЫМ приоритетом.
В остальном - все то же самое: все низкоприоритные задачи ждут, пока им не достанется чуток процессорного времени.
По крайней мере так сделано во всех ОСях, которые поддерживают time slice.
Подобная штука категорически необходима для проектов, где ВСЕ задачи имеют равный приоритет.

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