Цецо, само не ме разбирай погрешно...

Аз препоръчвам nuttx защото съм го разгледал и твърдя, че аз бих се справил с него. И ако навремето го имаше, нямаше да правя собствен. Но аз вече имам собствен и от една страна ми е вече късно, от друга разликата с моя не е толкова голяма и не си струват революциите да минавам на Nuttx. Така че ако някой реши да го ползва, после не мога да обещая че ще мога да помагам с каквото и да е било. И да не ме псувате

Не че е много интересно, да простичко е и работи. Идеята по принцип е да се ползва само един от тасковете. Това е основната (real time) функционалност на дадената система. Всичко останало е в допълнителните задачи, които си имат прост механизъм за разрешаване/забраняване на изпълнението им и един стек ако се наложи да прескочиш някой таск и после да се върнеш. Най-хубавото е, че като използваш такава система се научаваш да пишеш драйверите абсолютно нон-блокинг, или иначе казано - като хората. На хората обаче им се вижда доста сложно...

Ти, кортексите що ги ползваш? От куртуазия някаква или щот има мода такава? Това, което демонстрираш е смехория! Вземи си ползвай пиковете и не се занимавай с ARM-мите поне докато наистина не се наложи!

@fan, да не те сърби някъде, където не можеш се почеса - примерно дивака, та си позволяваш да се обръщаш така ?! Айде, моля те, като не можеш да помогнеш - не си демонстрирай колко ти е самочувствието и "превъзходството" с такива съвети. Еволюирай в отношенията към колегите, ок?

W/e върти ми се в главата решение на проблема, вероятно сведено до не особенно тежък таск мениджър и малко раздробяване на функциите, както и разделяне на периферията във времето с флагове кой я ползва и за колко ще я ползва. Предполагам ще се справя с това, а и то на практика не ми трябва нещо кой знае колко повече, освен приоритет на критичните таскове, което не е трудно да се направи при условие, че под "критичен" имам предвид около 1мс от събитието да започна обработка - пък и те са само 2 проблемни таска, другото може да трае.

Това съвсем не е от самочувствие, а за помощ аз ти помогнах достатъъчно повече от писанията на колегата - а него просто го попитах що така! Сори за скандала и офтопика!

Човекът си каза че иска само кърнел, тъй че не виждам защо липсата на драйвери при freertos-a ще му е проблем.
Ако говорите за пълен ОС (само дето имаше уточнението че не му трябва разни "стекове" и подобни, а само кърнел), ще се съглася че в тоя nuttx има повече неща.
Колкото до качеството на freertos-a - хм, не мога да разбера какво му е толкова калпавото? Имаш ли нещо предвид конкретно? Все пак на тая база са openrtos и safertos. На първия не се срамят да му искат пари, на втория ТЮФ са му дали сертификат за safety, което за мен е признак за нещо - целият му развоен процес на тоя ос е минал под лупа и предполагам е документиран педантично.

Апропо, някой пипал ли е Луминари с вграден в ROM-а SafeRtos (9B96)?

FreeRtos-а са се ограничили до кърнела - оттам интерфейси към драйвери, хардуерна абстракция и подобни липсват. Хубаво беше да ги има, стига да пасват на проекта (или девелопера).

Другото, дето още не сме го споменали, е uc-os2 на micrium. Не е фрии, но за крадене става.

Performance-а на rtos не смятам че е боза. Можеш да провериш защо чибито е бързо - според тях това се дължи на факта, че тасковете и другите примитиви се създават статично. Доста rtos-и могат да го правят динамично, което само по себе си е плюс. Само че в голяма част от случаите този плюс води до по-сложно превключване, и оттам по-бавно. А моят (неголям) опит показва, че обикновено тасковете се създават на старт-ъп и живеят така до изключването - т.е. тоя feature често е излишен.

Като гледам, ако човекът иска малък и лек кърнел, чибито изпъква с peformance. Остава да разбере дали нещо от feature-ите на другите ще му влезе в употреба и да прецени за себе си.

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

Естествено че има случаи в които това е без голямо значение, при прости приложения - ама там един superloop с няколко прекъсвания е чуден. В тези случаи rtos е само допълнително натоварване без реална полза.

И с какво точно помогна, че нещо пропуснах...

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

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

Всеки един ОС изисква време да го разучиш и да му свикнеш, няма значение какъв е. И лошото е, че времето инвестирано във фреертос няма с нищо да ви е полезно. Това ще е време, през което НЯМА да се научите как се структурират проекти, НЯМА да се научите как се правят стекове, драйвери и т.н.

Ако беше някаква междинна стъпка нямаше да има проблем. Но НЕ Е!. Напротив, веднъж като понатрупате сорсове няма да ви си мърда.



Това са свободни съчинения... Не познавам чибито, но за фреертос няма разлика какъв ти е таска.
Изобщо в едно реално приложения кърнел кода отнема не повече от 0.001% от CPU usage-а. Тъй че ако от подобно "забавяне" ви зависят нещата яко сте я закъсали...

Тоя nuttx като идеология не е ли правен да се компилира по Лайнукс???

Гледам препоръчват под бозата да се ползва Цигвин - а аз това не го понасям....

Може ли да се изкомпилира чисто под бозата?

Поразгледах го това nutx.
Няма порт за читав компилатор за съжаление. Като гледам организацията вероятно няма и да има.
Тъй че Миро хич не го хвали толкоз Играчка за мазохисти :):)

А FreeRtos-a се компилира под каквото искаш
Има една единствена сериозна причина за критика. Доста често самия кърнел забранява прекъсванията. Това е цената на универсалноста за съжаление. Разбира се проблем е само при някои приложения.
И при по сериозно навлизане в нещата може да се направи собствен порт в който това не е така. Имам едно продуктче с SAM7S64 в който малко съм пипнал готовия порт и за сметка на това че внимавам какво правя в прекъсванията,кърнела не ми забранява прекъсванията глобално никъде.

А прехвалената от теб организация на драйверите си мисля че за малките процесори си е по скоро минус отколкото плюс. Само товари кода.
Перифериите са различни. Няма никаква причина освен облекчаване работата на програмиста да се стандартизира интерфейса им.
Ми то като ще се облекчава работата на програмиста за сметка на тромав код дай да пишем на Basic

На freeRTOS, специално за Куртекс, кернела забранява прекъсванията които са под него и до някакво предварително зададено ниво (има макрос за това). От там нагоре (по преоритет) не бара.

Поне така са писали в документацията. Не съм ровил сорса.

Иначе сега разгледах бегло и coocоx - като я гледам не виждам нещо по различно от freertos. Може би далаверата е в това, че е писана специално за Куртекс и вероятно е оптимизирана добре за него. Което пък я прави неприложима за нищо друго, т.е. на Миро няма да му хареса.

@миро - документацията на nuttx е трагична. В смисъл самия кернел и синхронизациите са описани, но всичко друго е мъгла от тип - те ти кода, оправяй се. То това е нормално де, човека без пари ти го дава, ама....

бърз преглед показва, че разчитат на цигвин плюс, допълнително имат доста шел скриптове...

Би трябвало да стане и без цигвин, но със сигурност ще трябва пълнен комплект binutils, няма да стане с орязания на ягарто...


И аз го имам тоя проблем и мога да ги разбера Изглежда сложно и объркващо, но без система за конфигуриране и компилиране просто не става. ..
Засега аз се опитвам да не ползвам нищо повече от yagrto но и това си има цена. Получава се дублиране - веднъж в моите МК-файлове имам дефиниции по които се решава какво да се компилира, втори път същите дефиниции ги имам в хедър файл, за да знае и сорса как го компилират...
Ако трябва да го направя като хората, дефинициите трябва да са общи за да няма възможност за разминаване. Но пък форматът е различен, т.е. ако е общ формат трябва парсване и обработки дето не стават с туловете на ягарто или на бозата.
Освен това те правят и компилиране на части, докато аз още я карам всичко в един кюп. И това почва да ми създава вече проблеми, щото станаха 700-800 сорс файла и ми се случва на няколко пъти конфликти в имена, дефиниции...

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

Ами мен друг компилатор освен GCC не ме интересува. Няма смисъл да спорим дали GCC или IAR е по-по-най...

Всеки има някакви лични предпочитания. Ако те убеждавам за нещо, то е да отделиш малко повече време. Защото тая някаква надежда, че ако ти научиш GCC поне толкова, колкото аз познавам IAR може и да си промениш личното мнение






Ех, не мога да кажа че няма "овърхед"... Има и той е различен при различните ОС.
Въпросът е, че това е "овърхед" само при условие, че ти НЕ правиш това което прави ОС-а. Ако го правиш, то и ти ще имаш овърхед и малко вероятно е той да е по-малък.

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

Ми незнам. При малките контролери наистина това с драйверите е малко изнасилено. Например SPI - аз по принцип рядко връзвам повече от един чип на една шина. За чии ми е, като Куртексите от малки имат по 2-3 SPI интерфейса. Малките пикове пък нямат, ама те нямат и ресурс за RTOS, камо ли за драйвер.

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

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

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

За дребни процесори според мен това е оптималния начин за работа с драйвери. Така едни и същи драйвери за AVR ползвам под моята си OS и под FREERTOS.
Разбира се е повече играчка да се напише драйвера.