В конкретния случай използвам TI-RTOS, но въпроса е общ за всички OS-ове.

Въпроса е как "най-интелигентно" да се реализира защита на устройството от забиване на някой от тасковете му?

В предишен проект бях имплементирал софтуерни WDT за всеки един от тасковете, които се процесваха в отделен таск, в който се опресняваше и хардуерния WDT на контролера. Ако някой от софтуерните WDT изтечеше - предизвиквах ресет на контролера.
Всеки от софтуерните WDT се пуска, спира и опреснява в съответния таск в зависимост от функционалността на конкретния таск.

Има ли друг "универсален" начин за решаването на проблема в многозадачни системи?

(преди време май бяхме нищили тази тема, но не можах да я намеря във форума)

Няма такова нещо като "универсален" и "най-Ентелегентен"...

Първо имаш много различни кърнели и шедул алгоритми. С това трябва винаги се съобразяваш, когато правиш софтуер изобщо. Не знам TI какво ползват, макар че масово обикновено се ползва RMA (Rate Monotonic Algorithm) със или без кооперативност. RMA простичко казано е работа с приоритети, които би следвало да се присвояват на база честотата на всяка задача. Демек ако имаш задаче дето обслужва прекъсвания с честота 5mS и такава на 50mS първата е с по-висок приоритет и при поискване трябва винаги да получава управлението преди другата. Кооперативност е когато имаш редуване на задачи с еднакъв (или поне близък) приоритет.
Особеност на RMA e, че за да работи безотказно трябва производителността на проца да е такава, че да не се надхвърля 69% CPU usage. За всяко ниво на приоритет, блокажът трябва да е ограничен до определено време съответстващо на приоритета (честотата). Демек ако в ниво Х имаш някаква нишка, то на ниво Х-1 може да пуснеш тестова нишка, която ако през определен период от време не получи управление значи нещо е сбъркано. Ако реакцията към забивки не трябва да е супер бърза може с най-нисък приоритет в системата да се търкаля една нишка, която да храни кучето. Ако някъде нагоре нещо зацикли кучето ще се разлае от глад
Това обаче е при RMA, щото има и други алгоритми и съответно може кучешката нишка да получи управление дори и отгоре й нещо да е зациклило.

Е те това ме притесненява, че може да се случи.

Повечето таскове в повечето от времето (например дни и седмици) няма да имат никаква активност.
Системата е изцяло батерийно захранена и различните спящи режими са на "особена почит" ...

Силно "пожелателно" е детектването на забит таск и ресета на проца да става в рамките на 500mS примерно...

хардуерното куче решава хардуерни проблеми, а софтуерното се храни от онази особена порода хора, наречени програмисти. не бъркай двата щата.

софтуерно нещата могат да се объркат по 1000 начина, докато хардуерните се броят на пръсти и тогава наистина трябва ресет.

за съжаление, софтуерните мерки за забил процес или нишка са много специфични и дори монография от 1000 страници надали да е изчерпателна. няма обща рецепта, просто още в началото на софтуеристите трябва да им се набие в главата, че не са бесзмътри и още по-малко безгрешни и техните програми винаги ще забиват. затова мерки трябва да се заложат още в дизайна на системата, а не да се подкара и после да се кърпи в посока надеждност.

Значи силно пожелателно е да не ти забиват тасковете никога

А иначе първата ти работа е да разбереш какъв точно ти е шедулинга... По спомен някъде бях чел че е с приоритети, потърси да няма някъде думичката "кооперативност" или "инверсия на приоритети". Обикновено щом е RTOS няма такива работи, ама знаеш ли... или ако ги има те са опционални, т.е. има настройки да се включват/изключват (при freeRTOS май беше така).
Ако е чисто RMA слагаш нишка с нисък приоритет да храни кучето и да спи по да кажем 200-400mS. Tова гарантирано трябва да хваща зациклени нишки. Но няма да ти хване повишена активност, което също ще ти тормози батерията. В такива случаи най-добре ако може да си мериш cpu usage-a. И ако видиш че се задържа висок подозрително дълго време да рестартираш и да се молиш, че няма да се повтори веднага

RTOS-a е приоритетно базиран, пеемптив, но не "върти" таскове с еднакви приоритети, ако изрично не го форсна за това. (Не поддържа ранд-робин превключване )

Има възможност за инверсия на приоритети, но това се получава и по "естествен" начин, ако високо приоритетен и ниско приоритетен таск използват общ ресурс. Т.е.високоприоритетния таск чака, докато ниско приоритетния не освободи общия ресурс ...

На времето доста се чудих как да направя софтуерните WDT и ги направих както го описах в първият ми пост.

Със сигурност трябва да се мисли за това още в началото на проекта, а не после да се "кърпи".

Отделно диагностиката и дебъг инфото също са важни и трябва да се заложат още в началото, но това може би в отделна тема ...

Меренето на активността на процесора е добра идея, стига този анализ да не изразходва много енергия. (е, и сам по себе си не е достатъчен критерий за "забиване")

Някакви идеи как да се направи това?

Сложна работа е. Най-чисто е всеки таск да си има собствено куче. Периодично вика някаква функция, която регистрира, че таскът е жив (т.е. храни си кучето). Отделно има таск само за обслужване на глутницата, която трябва да се съобразява с това, кой таск е бил буден, дали си е нахранил кучето, евентуално да се съобразява с някаква конфигурация и т.н. И ако нещо се размирише, да ритне столчето.

От М3 нагоре има опционален брояч на инструкциите (DWT_CYCCNT), би трябвало каубойците да са го имплементирали, ако не ще трябва да си пуснеш друго таймерче...

Как точно ще си го ползваш зависи от теб. Може примерно при смяна на контекста да си засичаш колко е бачкал текущия таск и така за всеки таск да си имаш cpu usage. Moже и глобално за всички, тук вече зависи как точно спинкаш дали с WFI или по друг начин, но преди спинкане засичаш време, като се събудиш пак и така...

Специално за спинкането има един трик - вдигаш SEVONPEND в SCR-а. След това преди спинкане може да забраниш прекъсвания и да заспиш с WFE. Като дойде прекъсване, то ще събуди проца, но няма да влезе да се изпълнява. Съответно може да видиш точното време когато си събудил, след това да пуснеш прекъсванията да си свършат работата...

... което ще рече, че при необходимост от по-дълга работа на устройството, файдата от RTOS е никаква и тя въобще не работи като такава. Но това си е твое решение...

Аз друго искам да питам - що е то "забиване" и вие с кучето ли го борите? Щото тогава при често забиване RTOS въобще не е RT, та пак да питам трябва ли ти?

И как работят RTOS ако не е тайна?

За кой процесор питаш, ако не е тайна?
Не че мога да отговоря умно, още повече на тебе. beer

Проца е CC1350.
Лео, не се сещам за друг начин за излизане от забила програма.
Какво означава "забила" е сложен въпрос...
Един от критериите например може да е ако даден таск не е завършил активността си за определено време.

Шегата ми беше към Миро, ама и към тебе става, Емиле

Да мериш "активността на процесора" - не става ли с два таймер, до които достъп има само
кернела - единият постоянно инкрементиращ, другият- когато се пуска някоя потрбителска задача? Или ще харчи много ток.