Ами то общото между OS-а и стековете е като между кравата и магарето - само това, че и двете са от един обор . Дали ще ги ползваш заедно зависи от това дали си склонен да платиш за всичко.
А FreeRTOS не бих го препоръчал на никого. Доста му е тромав шедълера, а и като му погледне човек сорсовете му настръхва косата .

Чак тромав,силно казано. Доста честичко се забраняват глобално прекъсванията. За това съм съгласен. Можело е малко да се пооправи концепцията. Но не е болка за умирачка в повечето случаи.
Сега FreeRtos-a е версия 7. Може би имаш повече наблюдения върху 5-цата. Но доста подобрения има вече в сорса на ядрото. Има глупости по портовете за някои процесори. Стартъп кода на SAM7S например просто е преписан от някакви атмелски примерни кодове.

Пък uCOS-а II да не е цвете случайно?
Гледам че за III се говорят добри неща,но аз лично не съм копал. С няколко добавки към ядрото които съм си писал съм си решил вече проблема за малка OS.

Относно стековете. Ами като си е писан за съответния OS и е съобразен с конкретната му концепция си е друго. Най малкото организацията на кода е същата и лесно се събира проекта.
Аз например доста ядове брах с подкарването на uGUI под FreeRtos. Загубих 2-3 дни докато разбера кое къде и всичко се изкомлилира както си трябва. Накрая не ми хареса,не ми пасваше на приложението

От какъв порядък им е латентността за прекъсвания на тия кернели от по $30к
(и при какъв клок де)? Питам само от любопитство.

То това по-силно зависи от архитектурата на джелезото. За прекъсванията де. Иначе латентността на самия суитчер вече е друг въпрос. Макар, че пак е зависима от джилезото.

Ако се притесняваш за латентността на нещо, го пускаш над кърнела да работи и готово

Зависи най-вече от ОС-а, колко за най-дълго маскира прекъсванията.

Не съм мерил времето за забрана на прекъсванията на uCOS-а - по начало събития, които пристигат през по-малко от 10-на микросекунди предпочитам да ги прехвърля на някакво желязо за обработка.
Иначе, времето за превключване на контекста при STM32F1 на 72MHz е около 12 микросекунди.

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

Читав ОС няма причина да забранява прекъсвания. При старата 4-та архитектура даже забраната е живо приключение и потребителския код може изобщо да няма права да забранява. При куртексите забраната е лесна, но безмислена защото приоритетите ги има задължително (не са опция), освен това има един таймер ( sys tick) и едно софтуерно прекъсване (pending service) дето са нарочени за ОС. Та обикновено операционните системи слагат възможно най-нисък приоритет на пендинга и там се сменят контекстите (демек точно преди излизане от всякакви прекъсвания и ексепшъни). Систика пък се слага на най-високия приоритет за ОС-а. Над това ниво може както каза Цецо да се слагат прекъсвания, но те не бива да ползват кърнела, защото са с по-висок приоритет и може да го омажат.
Ядрото следи приоритетите и всеки опит за инверсия гърми с хард фаулт. Може само да се ескалира нагоре, т.е. всички дето искат да ползват кърнела обикновено минават през трап, който вдига приоритета и спира конкуренцията. Тия отгоре не са конкуренция, щото ако се опитат да скочат в трапа ще гръмнат...

БатеВаньо, не разбрах какви предимства има това чудо, освен че е скъпо?

Абе, без забрана на прекъсвания няма как да стане (или поне аз не виждам как) - докато се обработва пендинга може да възникне ново прекъсване, да смени състоянието на OS-а и наистина да омаже всичко.

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

Да разбирам демек, че ARM са се сдобили с няколко нива на прекъсване ала 68k?

Брей, бая прогрес е това. В power няма - там има момент когато се налага маскиране
за няколко инструкции (не повече от 3-4 май идваше по спомен, но и сериализация и т.н.).
Е, има едно второ прекъсване (ала 6809) в тия дето ползвам и по-новите де, та може да има
прекъсвания и под ОС-а както можеше на 68к (и го може на coldfire).

ДедоБоре, видях, че в друга тема питаш за сорсовете на 3-ката.
Предполагам си видял, че могат да се изтеглят от сайта на Микриум - иска се регистрация, но можеш да ги пробваш без пари. Плаща се, ако ги използваш в търговски продукт и то след 45-дневен гратисен период.
Ако имаш притеснения с това, мога да ти ги хвърля някъде заедно с порта за STM32F2xx.

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

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

Тва винаги го е имало, просто преди приоритетите зависеха от интеръпт контролера, а той не беше част от ядрото. И имаше производители дето лицензираха само ядрото и си слагаха собствен и не задължително "nested" interrupt controller.
При куртексите проиводителя може да избира само колко нива да има, но останалото е де-факто стандарт. За съжаление новата имплементация е доста по-калпава. Сложиха хем автоматично спасяване на регистри, хем тейл чайнинг. Демек сега като скачаш през трап задължително всички параметри се претакат през стека. Изобщо покрай прекъсванията направиха една крачка напред и две назад....

Тия извън ядрото ги има и в power, ама нали там маската винаги се вдига да може обработката
на прекъсването да прибере някъде регистрите с мястото на прекъсване и контролите (в power
общо 2 регистъра) преди да може да се отмаскира. Това дублираното за което разправям (ала 6809)
е с отделен бит за маскиране и отделни два регистъра за спасяване та могат да не си пречат с другото.

А другия вариант - ала 68к - минава през стекване, няма как инак да стане прекъсване в прекъсване
по всяко време. Та е все тая в крайна сметка като тегли чертата човек, дали ще чака микрокода
да стеква или ще остане маскиран за малко и стеква софтуерно.

За макросите е въпрос на вкус. Аз също за малки процесори пиша с много макроси.

Проверките на аргументите раздуват кода,вероятно и затова са пропускани. Тук аз съм съгласен че евентулано е можело да се направи нещо да се включват с някакъв ключ ако програмиста прецени че са необходимо. Аз лично съм си направил един софтуерен слой през който ползвам api-to на FreeRtos-a. Не специално за чекването а за независимост на кода от използвания OS доколкото е възможно. Там съм си реализирал и чекването на някои аргументи които съм преценил че е важно.

За списъците не се сещам какво точно те дразни.

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