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

[jcxz]

В вашем случае сброс можно формировать из без WDT - просто ждать ответа очередной задачи по таймауту средствами RTOS.
Не успела ответить - пишем событие в журнал, сбрасываем проц любым способом. Хотя это можно делать и через WDT.

Лучше это делать через WDT.
Во-первых: Зачем плодить лишние сущности (высокоприоритетная задача для контроля + низкоприоритетная) если можно всё сделать в одном месте?
Во-вторых: А если нужна длительная работа некоей задачи по длительной циклической обработке неких данных "как можно быстрее всё обработать, но реал-тайм не нужен - как всё закончили так закончили"? Тогда помещаем её на самый нижний приоритет и она там колбасит со 100%-ной загрузкой CPU. При этом отвечая на периодические запросы о живости от WDT-задачи.
Вот у меня был проект, где нужно было быстро излучить некий зондирующий импульс (УЗ), захватить эхо-отклик на него, затем сделать его тяжёлую обработку, а потом - отобразить данные (или отправить их в интерфейс). Я сделал излучение/захват на высоком приоритете, потом - понижение приоритета задачи до минимального, чуть выше Idle (чтоб не мешала остальным работающим в это время реал-тайм задачам), длительная обработка на минимальном приоритете, после завершения - опять повышение приоритета задачи. При этом некоторое время процессор МК был загружен на 100%, и если-б контролировал WDT в самой низкоприоритетной задаче, то не успел бы завершить тяжёлую обработку из-за его срабатывания.

Поэтому, "давая" остальным возможность втупую сбрасывать WDT в прерываниях, вы тем самым открываете им "ящик пандоры".

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

зы. самый лучший WDT - внешний, в идеале со своим источником питания.

Это не самый лучший - он просто обязателен. У меня во всех серьёзных проектах обязательно есть внешний WDT.
И тот алгоритм контроля, что я описал, он в реале работает с парой: внутренний WDT + внешний WDT. Стараюсь везде так и строить работу: внутренний WDT + внешний WDT. Естественно - время таймаута внутреннего при этом чуть меньше таймаута внешнего WDT.

[Forger]

Лучше это делать через WDT.

У всех свое понятие "лучше".

Во-первых: Зачем плодить лишние сущности (высокоприоритетная задача для контроля + низкоприоритетная) если можно всё сделать в одном месте?

У меня это было сделано в одном модуле LifeGuard (сущность "по-вашему"), в котором крутятся две задачи. Его реализация зависят от проекта. Простейшие содержат лишь задачу с WWDT.

Во-вторых: А если нужна длительная работа некоей задачи по длительной циклической обработке неких данных "как можно быстрее всё обработать, но реал-тайм не нужен - как всё закончили так закончили"?

Достаточно сделать ей приоритет равным или ниже задачи с WWDT, но тогда там нужно ручками обеспечивать гарантию ее независаемости.
Однако, я всегда стараюсь строить "числовые" задачи так, чтобы они не грузили ядро на 100%.

Это мне кажется самоочевидным.

Увы, не всем .... обратите внимание на название этого раздела: "В помощь начинающему";)
Наверняка среди читателей этой темы найдутся те, кто до сих пор грешит суперлупом и там же постоянно сбрасывает WDT