Мисля че в зората на тоя форум, чесахме подобна тема, ама сигурно ще е интересно за доста нови хора.... та:

Как съвместявате работата на кучето с една RTOS имплементирана във ваша система.

Общо взето аз RTOS системите ги деля на два вида:

1. Примитивни - от собственоръчно написан превключвател, до да кажем нещо от сорта на FreeRTOS, Salvo или ucos.

2. Сложни - CE, uCLinux, баш Linux и пр. дето не са точно RTOS, но пък са OS, така че и там проблема е налице.

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

Това горе долу е изпълнимо при първата група системи. Всъщност сега ми се налага да го правя и мисля да го правя нещо от този сорт.

Но как ще се направи такова нещо при по сложна система от втория тип - хич не ми се мисли. Никога не ми се е налагало, признавам.

Дайте да обсъдим подобни техники. За мен "специалистите" се делят на два типа - едни за които сигурността е задължение, кучето е задължителен елемент. Повечето от тези специалисти обаче никога не използват RTOS. Другите пък са на високо ниво, за тях работа без таскове и кернел е немислима. Но опита ми показва че те в повечето случаи игнорират хардуерните кучета и летят над тия работи. Тъй де важното е да подържаме WIFI пък за куче..... В 90% от случаите и заданието на проекта не ще кучета, та тяхната е лесна. Налагало да имплементираме цял контролер който да играе куче за няколко от тежкарите по платката, щото те имат по възвишени задачи

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

Ми ако е истинска RTOS, т.е. с ясно време за превключване на нишките, не виждам какъв ти е проблема. Проблем по-скоро би имал, ако системата не е рийл-тайм и никой не ти гарантира, че процеса ти ще си получи времевата порция. В Windows-а това се решава с написване на лоу-левъл кърнъл мод дивайс драйвери. На тях им е гарантирано, че могат да пипат шедълинга. В линукса, предполагам, е нещо подобно.

Виж сега за теб кърнела е нещо всевишно. По презумпция според теб той не забива.

Но това не е така. Кернела е код, който се изпълнява от ядрото. И той може да забие. Поради програмистка грешка, поради смущения в захранването, пропадане на осцилатора и пр. Така че не можеш да разчиташ на кърнела да те извади от такива ситуации. Там само кучешки ресет помага. Въпроса е кой да гали кучето , т.е. да не му дава да лае.

Представи си че имаш животоподържаща система. Забива ти лоулевъл кернела, например влиза в прекъсване, и не може да излезе. Кво правим после?

При една "сериозна" система в този случай ще се активира кучето. Ще блокира системата (защото неправилната и работа може да навреди повече от бездействието и), ще активира някаква хардуерна аларма и ще повика някой да сеърши останалото. Ако системата е автономна, може да я рестартира, като остави някъде знак че кучето е било там. После кернела да вика помощ и пр.

Но тук по - скоро говорим за "елементарни" ОС, не за Vista.

За много отговорни приложения съм си мислил за едно дребно процесорче в което да си реализирам няколко wachdog-a. С него да следя работата на основния процесор с RTOS-а. Но така и не съм го правил на практика.
За случаите когато съм ползвал RTOS съм слагал разни трикове с флагове както и ти.
За freeRtos слагам едно прекъсване в което последователно проверявам края на стека на всеки таск. Ако случайно се препълни да се ресетне процесора. Обикновенно почти всички проблеми водят до омазване на някой от стековете. Не е проблем и в друга OS да се направи но аз познавам достатъчно добре като да ровя в кернела само freeRtos и затова съм го правил само на нея.
Отделно при ARM си имаш обработка на грешките / abort / така че ако ядрото на OS-a или нещо друго се омаже почти невероятно е да не се получи някакъв abort.

Краткият отговор според мен е че RTOS/OS и кучетата нямат и не бива да имат нищо общо!


По-дългият вариант е, че идеята на кучето е да повиши надеждността на системата. Въпросът е кога е възможно това да бъде направено и какво общо име това с един RTOS?
За да се отговори на тия въпроси първо трябва да се започне с предположението че RTOS-а е сложен не за красота, а защото има real time system. Определението за такава система е че правилна работа означава не само логически добре свършена работа, ами трябва и на време да бъде свършена работата. С други думи перфектно работещ софтуер не е достатъчно, трябва си и бързина.

Първи извод: В RTS, независимо дали има RTOS/OS надежността зависи от времето за изпълнение на нещо си (дефинирано от приложението). Ако ще се връзва куче в такива системи, то не трябва да слухти дали е забил процесора и дали работи софта, ами дали системата си върши работата навреме.

Втори извод: В една RTS кучето обикновено не помага, даже може и да попречи.
Звучи малко нелогично, но има много примери. Преди години затова падна една френска ракета - Ариана ли се казваше, не помня, ама беше нещо от сорта че от 4-та към 5-тата им версия бяха сменили двигателя и той правеше по-големи ускорения, софта им за управление на крилата пък имаше някакво цифрово препълване заради по-големите стойности и се побъркваше със сметките. Интересното е че нали са авионика, сметките се дублират в няколко компютъра, съответно всичките се дънят... в крайна сметка се задейства кучето и ракетата пада
Естествено, става въпрос за поредица от грешки - че не са си фикснали софта за стабилизация и най-вече че след рестарт на кучето по време на изтрелване не е трябвало да изхвърлят секцията. Иначе секцията имала само още няколко секунди до изгаряне и след това ускоренията щели да влязат в нормата... Но заради кучето вместо на грешна орбита са паднали на земята

В крайна сметка е непбходим анализ - значи системата има задача и определено време да я свърши. Нагласяш кучето малко преди изтичане на времето. Като не стане работата обикновено има проблем и единичен отказ на системата е почти факт. Дали трябва да се рестартира системата? Ако за системата не е фатален единичен отказ - да, може да се рестартира и да се надяваме че това ще е единичен провал. Но трябва да се внимава с рестарта - за да не стане като с французите... Понякога е по-добре многократен провал на една задача пред еднократен провал на много задачи. За такива случаи май трябва да се слага глутница от кучета и да се рестартират само отделни задачи...

Конкретно за RTOS-те трябва да се има предвид че благодарение на хардуерните екстри, кърнелите им са що годе защитени. Ако има някакво тотално омазване, то с достатъчно голяма вероятност ще избие през някакъв ексепшън. Разбира се колкото и малка да е вероятността, има такава и да се омаже кърнела въпреки хилядите екстри на процесора. Тогава кучето би помогноло, обаче
кучето обикновено е едно, а вероятността да се омаже лузерски код без да се омаже кърнела е мнооого по-голяма.
Затова повечето кърнели избягват да използват кучето и то да остане свободно за лузера, който е в много по-голяма опасност.

Така че проблемът с кучето обикновено е проблем на лузера - той трябва да си направи сметката кога да го гали и кога да се бъзика с него

Всъщност работата е елементарна.
Това, което правя - било в малък кернел (правил съм го напр.
за HC11), било в пълнофункционална OS (като DPS за PPC или CPU32),
е да сложа ритането на watchdog-а в task-switch-а. Ако някой таск се успи
и забие дотам, че да не поиска сам да излезе за rescheduling и стои
маскиран за насилствено вадене - е, watchdog-ът бие reset.
Не ми е ясно за какво разделяне на кернел и некернел става дума
тук, ако има някакъв таск, койот се води "кернел" и той не се връща
наникъде по цели вечности, на човек му трябва не watchdog, а
работеща ОС...

Цецо, ето какво правя понякога:

Да предположим че дадено MCU има вградено куче на базата на някакви броячи. Тъй като надеждността му е ниска се слага външно куче - обикновено в комплект с ресет генератор ти идва наготово (TI имат сносни решения). Докато вътрешното куче са някакви броячи и т.н., външното е проста импулсна схема и директно управлява ресет-а.

Подходът е прост - да речем че външното куче има таймаут от порядъка на 0.5-2 секунди с всичките толеранси на захранване и температура. Обикновено иска първо подритване за да се запусне. Това е "нервното" куче което трябва да бъде хранено във всеки случай. Мястото за това е най-високо приоритетната задача или регулярно таймерско прекъсване.

Другото, "мързеливо", куче с броячите се конфигурира за някакъв сравнително голям период съобразен с приложението. Неговата цел е да пази най-мудната част на софтуера и се подритва от възможно най-ниско приоритетната задача, или както иначе я наричам - "foreground" процеса.

Каква е идеята сумарно? Нервното външно куче с малкия си период следи дали MCU-то работи като чип. Когато кучето е един чип с ресет генератора това ти гарантира бърза реакция при непредвидени смущения. Първото му запускане се прави на място в началната инициализация от където нататък регулярното му хранене е гарантирано. За примера даден бих използвал подритване не по-рядко от 0.25 секунди. Вътрешното мързеливо (и ненадеждно) куче пък от своя страна следи че най-бозявата част (писана от незнайно кого и как) не е изпаднала в дрямка. Там може да се стигне дори до порядък минута - силно зависи от приложението. Например е съвсем възможно системата да работи и най-високо приоритетните задачи/прекъсвания да си щракат щастливо, но "foreground" процеса да е изпаднал в размисъл или въобще да не може да получи време поради interlock на по-важни процеси.

Ако искаш му хвърли един малък размисъл. Основната идея е да имаш две контролирани граници, не една. Надявам се поне малко да е било разбираемо ... обясняването не ми е даденост.

Чакайте сега. За мен кучето е спасител в извънредни сутации. Обикновенно лузърска грешка при писане на софт наистина не е проблем на кучето. Но грешка при писане на кернел е проблем на кучето.

Наиситна повечето от сериозните съвременни ядра има ексепшъни за щяло и нещяло. Но това предполага ядрото да е работоспособно. А ако не е.

1. Какво става когато умре главния осцилатор? Раздрънка се почне да бръмчи на господ знаекой хармоник. Ама това не ставало при хубаво направен дизаин. А като стане - блъскаме ракетата в къщата и обясняваме че дизайнера е лузър?

2. RTОС са си върви, кернела пее. Ръгаме в най-високопреоритетно прекъсване, щото така си работи системата. И оп, там си оставаме. Ама как така ще питате? Ами ей така, случаен пик в захранването, програмния брояч прещраква някой старши бит и о небеса по случайност попадаме на някой затворен луп. Естетсвено вероятността за това е едно на милион. Дали?

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

Или пък:

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

Факт е че всички съвременни контролери имат куче . И факт е че имат доста развита глудница от кучета, което вече следи и осицилатора, и захранването и пр.

Аз продължавам да разчитам на кучето.

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

Woody, това което предлагаш е друг филм - по скоро как да подобрим работата на кучето. Тук въпроса е как да съчетаем една многозадачна система с кучето. Макар че има смисъл в това което казваш.

tqi, твойта теза пък съвсем не я схванах.

"че да не поиска сам да излезе за rescheduling"... това как да го разбирам? За non-preemtive системи ли говорим?

Ами точно де, какво те мъчи? Забива кърнела, твоя процес забива и той поради тая причина, уачдога таймаутва и ресетира процесора.

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

Има различни поведения при различни източници на проблема.
Ако сдуха кърнълът, само хардуерно куче може гарантирано да го изведе ( ресет на системата ).
Ако е сдухал някой тред, кучето не трябва да се намесва. Работа на кърнъла е да открие проблема и да извърши необходимите действия ( според случая, но почти винаги килва нишката )
Аз така ги виждам нещата.

В DPS тасковете могат - когато например чакат нещо - да излязат
за "rescheduling", т.е. scheduler-ът превключва към нов таск според текущите
приоритети.
Когато някой таск получи контрол, той го получава заедно с някакъв ограничителен
таймер (например в power архитектурата това е DEC регистърът). Ако таскът не
излезе сам, таймерът го вади насилствено (обикновено това го държа около
10 mS, но съм го забравял и на 2 с години без да забележа ... ).
Та докато тасковете излизат сами или могат да бъдат извадени, все ще има
нещо вървящо, което да реагира по някакъв начин - например потребител,
който да убие някой таск с команда и т.н.
А ако не излизат, е, никой не стига до scheduler-а за над 10-20mS - ами
тогава работата е достатъчно умряла за reset.
Много повече от това няма какво да направи човек по въпроса.
Дали watchdog-ът е зависим от системния clock или не - та да го хваща
и него, ако спре - е хардуерен избор който също е прост и еднозначен,
и човек го прави преди да почне да програмира така или иначе.

то кучето си е куче(хардуерно) - джафне ли - РЕСЕТ..... където и как го галиш все е тая,
"ракетата" пада - до колкото разбрах май се мъчиш да контролираш "падането"...
възтановяване на системата до колкото е възможно

Така е... и най-вече последното, че трябва да се подхожда конкретно според заданието и приложението.

Няма проблем да "галиш кучето" и в кърнела, но това е по-скоро отбиване на номера. Може да върши работа в по-прости системки, но АРМ/PPC и нагоре файдата клони към нула.
Всъщност ще има щото ако трябва да бъда честен мен ме мързи да обработвам хилядите други индикации, примерно проца ми си има вътрешен RC клок и ако нещо стане с PLL/oscilator си минава на бавния клок автоматично и прави прекъсвания... Същата работа и с ексепшъните. Добрия вариант е да се обработват, ама... за по-мързеливите може и с куче.

Иначе за АРМ и другите наистина кърнела може да е доста здрав, особено ако има MMU със защита. Поне при мен много по-често се случва забивка на лузерско ниво - я някой високоприоритен таск се отнесе и зацикли, я някой забие да чака forever за нещо което няма да дойде. Затова и аз лично никога не бих сложил кучето в кърнела - в >90% от случаите просто няма да има файда.
А и по принцип - ти лузер ли си или правиш ОС? Ако си лузер, кой ти разреши да бъркаш из кърнела? На ниво лузер аз бих пуснал таск който само да глези кучето - така хем няма да пипам където не ми е работа, хем променяйки приоритета на тоя таск може да постигнеш различни защити (говоря за приемптив ОС).

Аз съм прост лузер, галя си кучето в отделен тред...обикновено някой от нископриоритетните...ама и адвансд лузер да бях, не виждам много смисъл да го галя през кернела. Няма ли да е по-лесно (и също толкова надеждно) ако се следи някоя променлива от OS-а (context switches/runtime и пр.), която се цъка от кернела...кернела като зацикли (едно на милион), в който и да е таск (по още едно на милион), дори и в този в който бия кучето (по броя таскове), при колкото и некадърно написан софтуер (по десет на сто ) , кучето ще оправи работата.