Пускам темата като отговор на Zdrav...



Като начало искам да кажа че гледам на въпроса от теоретичната му страна. И в тоя смисъл няма никаква дилема "или-или"... Ако с един контролер/процесор на човек му се наложи да върши няколко задачки едновременно, то той по един или друг начин ще си направи "някаква многогозадачност".
Разбира се, няма нужда да се открива топлата вода... много по-умни хора от нас са се сблъсквали с проблемите свързани с многозадачностите и има разработени различни алгоритми как да става това.
Според мен теорията е добре да се познава, независимо дали ще ползваш чужд код (ОС) или не. Първото важно нещо е дали става дума за "твърда" многозадачност (real-time) или не. Определението за "система за реално време" звучи по памет така: "система, при която правилните отговори трябва да са не само логически верни, но и да са дадени навреме". С други думи не е достатъчно просто да свършиш задачката, ами трябва да я свършиш навреме.Закъснелите отговори в такива системи се считат за провал, независимо дали са логически верни. Примерно ако управляваш самолет решенията трябва да се вземат навреме, иначе става кофти...
Обикновено повечето хора си мислят "аз не правя совалки, демек не ми трябва real time shit". Това е така, но теорията е добре да се знае, защото по ирония на съдбата в по-малките контролери обикновено се ползва RTOS и съответното техните алгоритми са за real time задачки. Това е така, защото се търси малко ядро и съответно прост scheduler. И всъщност реал тайма опростява нещата, защото се предполага че е избран достатъчно мощен хардуер за съответния набор от задачи. Така че до провали няма да се стигне и шедулъра трябва само да определи порадъка на изпълнение на задачите.

И в повечето случаи се ползва RMA (rate-monotonic algorithm), който гласи че задачките които възникват по-често трябва да се изпълняват с по-голям приоритет. Дейсвително, тоя алгоритъм гарантира че няма да има провали, стига CPU-usage да не преминава определена критична стойност. Това е доказано математически и т.н.
Всичко е прекрасно, само че като седне един програмист винаги ще предпочете приоритета да го сложи споре "важността" на задачата, а не според честотата на нейното появяване. И освен това обикновено няма гаранции че CPU-usage няма да стигне 100% и изобщо резултатите на практика доста се разминават спрямо теорията... Но не защото теорията е грешна, а просто защото не се знае...





С други думи имаш нещо като cooperative multitasking... Това общо взето е най-примитивния способ за многозадачност. Всички останали имат някаква стратегия, дали ще гонят deadline на задачите, дали ще е rate или нещо друга, но си подреждат задачките за изпълнение и не зависят много-много от самите задачи. Т.е. при другите се гони cpu usage и само над определен usage на процесора възниква риск за провал. Докато с кооперативната история провал може да имаш дори и на idle процесор. Нещо като оня виц, "чекай да свърша с флопито и ще ти покажа многозадачност"



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




И тук е точно обратното... В момента в който сложиш ОС трябва да забравиш за полиране! Всяка задачка бачка, ако има какво да бачка, ако не - трябва да "заспи в очакване на event". Така междувременно другите задачи ще могат да ползват процесора. Събитията ти идват или от прекъсвания, или от време.
Единственото ограничение е, че от към време ще трябва да се съобразяваш с резолюцията на OS-a. Казват му quantum и в повечето системки може да го избираш, но за ARM7 аз предпочитам qunatum от порядъка на 1mS, т.е. във *всеки* таск може да имаш time-driven неща само дето чувствителността ти към време е с точност от порядъка на quantuma-a.


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

Но на теория пак казвам, няма недостатъци! По-конкретно нещата които се гонят с един ОС са:
1) По-добро използване на процесора за множество задачи. Вместо да циклиш в една задача докато чакаш нещо, даваш шанс на други задачи да получат процесорно време, без това да ти алгоритъма. Всяка задача си я описваш по алгоритъм като че ли е само тя на тоя свят.
2) Абстракция и независимост на задачите. От горното ако ти трябва примерно да пуснеш задачка да се изпълнява на някакъв интервал от време или при някакво събитие - пускаш си я и не се интересуваш от други неща. Така ако си я направил в един проект, просто копираш файловете с copy&paste и ги добавяш в друг и не променяш нищо.
3) Абстракция на ниво хардуер. Това не всички RTOS-чета го правят, но идеята е да ползваш драйвери, а не директно да пипаш хардуера. Вмного случаи дори не се интересуваш какъв хардуер ползваш изобщо. Примерно при мен всички серийни драйвери имат еднакъв интерфейс и се бачкат с хендъли. Естествено като отварям хендъла знам към кой дали отварям USB, SPI, UART, USB, I2C или нещо друго. Но след това хендъла си е хендъл и мога да го подам на функции, дето им е все тая какъв е той. Това се налага много често при комуникации. Примерно правя си някакъв протокол за ъпдейт на фърмуера. За целта правя една функция, която чете, потвърждава и т.н. После за всеки възможен конектор и интерфейс който имам на устройството, пускам таск, отварям хендъл и викам въпросната функция. Така дефакто слухтя на всички интерфейси, пък вече където ръгнат кабел там става заварка...
4) Възможност за по-добра синхронизация и координация между различни задачи. До тук казах че целта е да се абстрахираш от това че имаш други задачи, но понякога пък искаш да имаш координация между група задачи. И в това отношение ОС-вете дават повече възможности, докато при теб предполагам имаш само едно събитие в даден момент и вероятно ще се опетлаеш ако трябва да правиш логика с много събития и много задачи.
Зависи много от приложенията, но при мен често става дума за терминали и човешка намеса - екранче, клавиатурка и разни други събития и когато пиша нещо трябва да се съобразявам от къде какво може да ми дойде.... Примерно често срещано явление да пусна някаква операция - независимо каква и чакам тя да свърши. Но в същия таск следя и за таймоут на операцията... И в същото време потребителя може да натисне клавиш за да поиска да прекъсне там каквото съм почнал...
Без ОС (или подобна концепция) тия неща стават трудно, но с ОС може във всеки таск да си избираш какви събития те интересуват и да чакаш и обработваш само тях...

моя отговор е прост

bare metal ако може. Ако не може - OC. Въпрос на дефиниция е каво значи "може/не може".

Всичко е въпрос на камбанарията от която гледаш бе miro. Не случайно има места където е забранено да се ползват компилатори, камо ли ОС. Ти ако трябва да правиш просто управление на 4 клапана на ABS - с ОС ли ще го направиш?

Ако говорим чисто теоретично - няма нещо което може да се направи с OС и да не може да се направи и без ОС. Обратното обаче не винаги е валидно. Т.е. има неща които могат да станaт без OС, но с ОС не могат.

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

Хората едно време като са имали само DOS да не би да са умирали от глад? И атомни централи са строили и ракети са пускали.

Естествено не искам да кажа че ОС-а е една безмсислица. Напротив - нищо лошо няма, стига да не се залита прекомерно. И стига човек да знае какво ползва и как го ползва. За всеки влак си има пътници.

Ти сам казваш - твойте приложения имат човешка намеса. Е то си плаче за ОС, щото човека е бавно говедо. Т.е. имаш съчетание на бързи и бавни процеси. Ама я си представи една система в която факторите които и влият са 10тина и резолюцията на задачите е от порядъка на 10ки микросекунди. Един пример от мойто ежедневие - управление на високоволтов модул. Кво прави процесора - управлява едни гейтове, мери едни напрежения и едни логичекси нива и всичко това с времена за реакция строго под 50us. И едновременно с това търкаля един сериен протокол на 9600. Няма екрани, бутони и пр. Какво да я правя вътре тая ОС? Че на мен първата ми версия даже беше на асемблер. В случая освен да ми пречи ОС-а, друго не може да стане. А над тоя процесор седи един ColdFire който търкаля линукс има TFT екран, файлова система, мрежа, тъчове, бутони, GUI - е тва пък как да го направиш без ОС. То ще е чудеса от мазохизъм.

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

Първо искам да благодаря на miro_atc за готовността да пише дълги обяснения в този форум. Предполагам че не стои без работа и за това оценявам времето и ресурса който отделя за дискусиите тук.
Като второ: "или" за мен винаги е включвало и "и". Тоест не бих искал дискусията да се отплесва в противоречията между ОС и голото желязо. При мен например нещата започват да идват някакси естествено. От прости и фиксирани задачи започвам да минавам на все по-сложни и заплетени. Започвам да се сблъсквам с проблемите които и всички други преди мен са срещнали. От една страна търся моя начин за решаването им но от друга страна наистина не искам вечно да откривам топлата вода и съм съвсем наясно че щом се използва и развива концепцията за ОС то определено хората знаят за какво го правят.
Има още няколко неща които не ми харесват в разделянето на ОС от bare metal. Едното е че започвайки да използваш ОС започваш да се придържаш към определен стереотип на мислене и подход към писането на софтуера. Другото е че се налагат ограничения по директния достъп до хардуера. Тука може и да греша не съм запознат с различните ОС. Но от скромния опит който имам абстракцията на ниво хардуер е понякога нерешима задача или така грозно ти вързва ръцете че съжаляваш за изгубеното време да пишеш абстрактен слой вместо да ползваш директно регистрите на съответния периферен модул. Пак казвам може би греша.
Наистина не съм чел много по темата, но бях останал с впечатлението че събитията по прекъсвания не могат да извикват/събуждат съответен таск. Интересно е и каква точно е имплементацията на такъв подход. Стигайки до точката когато един таск трябва да чака дадено събитие дали му се налага да прави един куп инициализации. Щото аз например предпочитам векторите на прекъсване, приоритетите и процедурите за обработка на прекъсванията да са твърдо установени при проектирането на системата. Иначе самия софтуер също започва да поражда събития или да ги пропуска тихомълком.
И понеже съм захапал абстрактния хардуерен слой да добавя още нещо което не ми харесва. Понеже хардуера става абстрактен решаването на задачите започва да се свежда до чисто програмистки методи, а понеже за решаването на един проблем има обикновенно няколко хиляди начини, софтуера започва да формализира и съответно игнорира някои от най-елегантните решения.

Това е което в момента ми липсва. Искам една задача да я опиша на С и като отворя нейната процедура да виждам всичко което тя прави и от което е зависима.

Това пък е което в момента ме спира да отделя повече време на изучаването на чужда ОС(многозадачна система). Имам вече написани и изтествани основни неща които ползвам на много места. Доколко са обособени като модули го тествам при всеки нов копи&пейст
Съгласен съм че използвайки една и съща ОС все едно че говорим на един и същи език. Т.е. работата в екип се улеснява. Улеснява се поддръжката на кода след време или ако трябва да се поддържа чужд код.
Съгласен съм и с това че спецификата на задачите определя и това дали ще ти трябва ОС. Както казваш когато имаш юзер интерфейс и не знаеш какво кога и откъде ще дойде е съвсем различно. При мен имах такъв случай. Работим с колегата който пише софтуера за ПЦ а аз за една ембедед система. Двата свята се срещат когато се свържат със серийна връзка. На колегата ми му беше много чудно какво толкова се пуйча около трансфера на данни. Обаче протокола ни беше такъв че той е от страната на мастъра, а аз от страната на слейва. Т.е когато на него му потрябва нещо той си пуска алгоритъма в който праща заявка след това чака отговор или излиза по таймаут. , докато аз не знам кога ще получа заявката, дали няма да ме хване по средата на някоя задача, нито дали няма да реши юзера да дръпне кабела, да натисне някой бутон в този момент...
И накрая един конкретен въпрос струва ли си човек да разработва собствена макар и примитивна ОС. Дори и това да е само със образователна цел и след време да му дойде друг акъл и да започне да използва някоя не толкова симпатична, но популярна ОС.

Цецо, аз в самото начало направих уточнение че говорим за ситуации при които един микроконтролер трябва да прави няколко задачи....

В тия случаи дилемата е или ползваш инструменти за многозадачност, или блъскаш като хамалин и сам си ги създаваш тези интрументи. Zdrav конкретно ползва някаква стратегия без да я нарича "ОС", но същата стратегия ползва и примерно Taskit, което се води за ОС, даже пича има и TCP/IP стек.
Става въпрос за концепцията, а не за имплементацията. Когато имаш няколко задачи трябва да имаш многозадачност... и е малко вероятно да измислиш нова концепцията, която вече да не е имплементирана от някой ОС.

Въпросът не е да заобикаляш известните концепции и инструменти - това не води до нищо хубаво. Както казва Zdrav колкото по-навътре влизаш, толкова повече затъваш в подобно блато...


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



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




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


Относно образователните цели.... както казах един ОС е преди всичко някаква концепция за многозадачност. Има много такива и задълбавайки конктретно само в една не е много образователно. Ако ще е за учене само, сякаш е по-добре да разучиш теориите за различни концепции.
А дали си струва... ами всяко нещо от което падат пари си струва. Ако можеш да искараш пари ще си струва естествено.
При всички случаи няма еднозначен отговор на тоя въпрос. В моя случай аз вече някъде 2 години се занимавам с писане на ОС. За щастие по-голямата част от времето ми е финансирана, т.е. не съм набутан. Грешката се оказа че вкарахме прекалено много неща в проектите. И дефакто трябваше да пренаписвам неща, които вече ги има. С две думи открих топлата вода
Аз всъщност много добре си знаех че тия неща ги има, но просто ги има само големи операционни системи. А пък тях няма как да ги подкарам на АРМ7. Щяхме да спестим много време, ако от самото начало бяхме сложили един АРМ9, ама това не зависише от мен... Хората казаха пари за хардуер няма, действай!
Ако мога да върна времето назад щях повече да настоявам за смяна на хардуера.... Иначе пак щях да тръгна със собствена ОС, просто защото няма друга която да ми върши работа на тоя хардуер.
Но подчертавам че моят случай е частен в много отношения. Включително и това че АРМ7 е особен случай. Значи повечето универсални операционни системи не се съобразяват с архитектурата на АРМ. Те си правят нещата по един универсален начин. Съответно аз ги оптимизирах и натъманих като за АРМ и на тая платформа постигам по-добри резултати. Това е хубаво от една страна, но от друга е лошо, тъй като обвързах много концепцията си с конкретната архитектура. Ако някой ден ми се наложи да портна нещата и за друга архитектура ще имам проблеми. Вероятно ако го направя, ще стигна до същото което вече други са направили. Аз затова и сигурно никога няма да тръгна да го правя. Но да не казвам големи думи, щото знам ли какви простотии ще ми се наложи да правя

Миро този Taskit нещо не го намирам.
Кажи някоя по-примитивна ОС която ти е направила добро впечатление. Може и да не е за ARM.
Че нещо се губя в море от всевъзможни RTOS.

странно.. може и аз да съм объркал името, но сякаш бяха две системки на тоя принцип. Едната е www.utasker.com и тя е event-driven но малко по-развита. Пичът който я поддържа Mark (Butcher?) e готин и пише по много форуми. Но имаше още една по-проста, дето по принцип беше правена за разни 8-бит процесори, но коя беше... Ще се сетя може би

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

За примитивна OS може би трябва да разгледаш freertos-a... На мен честно казано не ми харесва, обаче е фрее... и вече популярен, демек ще намериш и други които го ползват. Никола Киров мисля че го ползва и можете да менкате мнения и сорсове. То и аз може да се каже че познавам freertos, щото това беше един от осовете чиито сорсове разглеждах докато пишех моя.

Всъщност като избираш ОС може би най-важното е дали търсиш драйверна система. Щото самият кърнел е нищо и половина. В повечето случаи кърнела е около килобайт, а драйверите 10 или 100 пъти повече.

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

Аз пък я харесвам FreeRtos. Работи си желязно. Има доста детайлна конфигурация. Може да правиш всичко с нея. Може да и променяш дори типа и от конфигурацията. Сорса е прост и разбираем. Ако нещо не те кефи може да си дописваш. Миро мрънка че нямала концепция за драйверите. Ама той иска малката OS да изглежда като голяма .
Малко ме дразнеха имената на функциите в API-to но си направих макроси и си ползвам мои.

Ми според мен е грехота да нямаш драйвери при ARM

Просто архитектурата го предполага и улеснява. Не губя абсолютно нищо от това че имам концепция. Нито като код, нито като бързодействие. Може да се провери, но смятам че моят кърнел барабар със съпорта за драйверите е по-малък и по-пъргав от тоя на freertos.
Освен това концепцията ми значително опростява и тасковете и драйверите. Старал съм се всичко да е изчистено отвсякъде. На ниско ниво никъде тасковете не се грижат за абсолютно нищо. Няма инициализации, конфигурации или други простотии. Кърнелът автоматично се инициализира ако може да се нарече инициализация на нещо, което не използва никаква памет... След което директно тръгва main() под формата на таск. Още от първия ред на main() всичко ти е готово и програмиста няма никакви грижи.
По същия начин е и от страна на драверите. Всеки драйвер е просто една структура и 3 опционални функции. Едната функция е примерно за прекъсване (ако драйвера е за някаква периферия). Когато дойде прекъсване, драйверната система предварително си свършва черната работа и ти вика ISR функцията на драйвера. Там в нея програмиста няма абсолютно никакви задължения, нито да се грижи да спасява контексти, абсолютно нищо.... Функцията си обработва само нейните си работи там каквото трябва да се свърши за обработване на прекъсването... нищо повече!
Отделно макар и като прекъсване ISR функцията получава параметри с указател към структурите на драйвера. Така ако имаш 5 UART-a не ти се налага да пишеш 5 драйвера. Пишеш един драйвер само, а го инсталираш 5 пъти или колкото искаш. Щото ако толкова държиш може да си инсталираш различни драйвери за отделните UART-и.

Та накратко спрямо freeRTOS-a:
1) аз съм премахнал всякакви грижи относно ОС-а. Нито в тасковете, нито в драйверите не се викат разни магически макроси или служебни функции. Все едно пишеш приложение за Windows... там инициализираш ли нещо? Не, директно си правиш твойте неща.
2) Повечето неща са далеч по-оптимизирани. Влизането ми в прекъсване или по-точно ISR на драйвер става за по-кратко време, като при това вече е свършена *всякаква* черна работа относно спасяването на контексти и ала-бала...
Нито една от системните функции не ползва юзерски стек, така че тасковете могат да работят и с НУЛА байта стек, освен ако на тях самите не им трябва повече. Контекста на тасковете ми е по-малък по размер и не използвам *никаква* друга памет.
3) Имаш възможност да се абстрахираш от хардуера. Не е задължително... ако искаш пак може да си работиш с някаква конкретна периферия по свой си начин. Но аз просто предпочитам да не го правя и се възползвам от абстракциите.

Тъй де... това беше лирично отклонение и самореклама, която не помага на Zdrav. В крайна сметка на него freeRTOS наистина може би ще му свърши работа, не защото е много добра ОС, просто защото някой вече я е подкарал, което (може би) ще му спести време. Ако ползваше чипове на Атмел щях да му дам моя ОС, но на LPC нямам нито един драйвер... и нямам намерение да имам. Затова колкото и да ми е неприятно трябва да му препоръчам free-то. Освен ако не иска сам да си подкарва перифериите, но не бих могъл да го посъветвам подобно нещо

Да не беше залитнал с твоята към гнуста можеше да се включа в развитието и. Но работата с гнуста е само за мазохисти. При това от големите ;) Аз понякога съм мазохист ама не чак толкова голям :):)

А и малко се съмнявам дали тази концепция можеш да я поддържаш на разни архитектури. Вероятно с много зор може и да се подкара на ARM на друг производител.

Аз казах, че концепцията ми е оптимизирана и натамънена като за ARM. Не че не може да се портне и за други, но няма да пасне толкова добре, освен ако не се пипне самата концепция.
Във всеки случай пак казвам за мен ценното на един ОС са драйверите. Да го сложиш и да тръгне без да се тормозиш с хардуера. Знаеш колко хора изпищяват още на клатене на пин, да не говорим за UART, SPI или USB... Но всичките тия драйвери си искат време да ги напишеш като хората. Аз съм направел само за Атмел и нямам нито време, нито даже желание да се блъскам с други железа...

Иначе за GNU не си прав Зорът е само докато го подкараш веднъж... е виж Цецо с какви простотии се сблъсква и още не е подкарал най-важното - дебъгването... Както се казва няма безплатен обяд. Ако искаш нещо по-хубаво, трябва да се потрудиш. А GNU определено е по-хубаво и по-удобно от IAR. Знаеш... бачкал съм с IAR и не е като да не го познавам. Макар и по принуда да се наложи да го сменя с GNU, то вече ще ми трябва много голяма принуда да се върна на IAR Все едно да ме накараш да зарежа ARM и да се върна на 8051...

Миро, разкажи малко как си си организирал драйверите.
Аз за DPS няма толкова какво да разкажа в тоя дух, нищо нетривиално:
device driver-ите имат стандартни входове за get (еди колко си байта на
еди кой си адрес), put (обратното на предишното), set parameter, get parameter.
Системата ги поддържа доколкото можеш да ги намериш по име, да load-неш
нови и т.н., файловата система ги ползва по предназначение и т.н.
Не много различно от другите OS, предполагам - device independent I/O е част от
всяка ОС, предполагам.
Аз винаги се оглеждам за нови идеи и ми стана интересно ти как си го направил.

Винаги ми е било интересно приложението на ОС върху едночипови контролери. Тоест какъв е смисъла?
И винаги съм си мислел, че това е само за мързеливи програмисти. Имал съм достатъчно ядове с писани неща от някой и съм на мнение, че е най добре да седнеш и да си направиш нещата сам, отколкото да се бориш с неща писани от някой ентусияст (особенно безплатни такива на които не можеш да им хванеш дирите кой какво е творил) и да загубиш двойно повече време от колкото да си го пуснеш сам...

Тишо замисли се. Един съвременен микроконтролер в един чип има повече ресурс от цяла компютърна система от зората на цивилизацията :):).

Да вярваш че твоя код е по читав от код използван от хиляди програмисти и доказан в боя означава че се смяташ за безгрешен.
Обикновенно като се хванеш сериозно ще го направиш по оптимално,с по малко код и по бързо но в над 90 процента от приложенията от това нямаш никаква нужда. По важно е да работи. А докато изчистиш твоя код ще загубиш много време,а обикновенно грешките излизат чак като иде изделието при клиента. Обикновенно кода който е проигран при много програмисти и ситуации е изчистен от грешки.
За нещо много просто да. Но като стане по сложен проекта възможноста да омажеш нещата нараства в геометрична прогресия :):):)

Доста важно е човек да може да работи с чужд код. Аз още не мога да кажа че съм се научил. Все псувам много но си трая и копам нататък :)

tqi, като концепция е същото и при мен... С тая разлика че нямам определена посока, т.е. при серийна операция нямам отделно get отделно set, ами команда, указател и брой байтове.
В самата команда побитове се оказва дали е read или write или и двете както може да е речем при SPI. По точно имам хендъл -структура със следните полета:
* src - указател за (put) данни
* dst - указател за (get) данни (демек буфер на клиента)
* len - дължина два байта
* команда - един байт, но общо само 4 бита ползвам (read, write, lock и cmd)
* res - резултат от операцията.... (статус)


По аналогичен начин и get parameter и set parameter са ми обединени в едно. И мисля че такава е практиката, по-скоро ти си го направил нестандартно
Приерно и в бозата е така... има IO_CTRL-и а пък дали те сетват или гет-ват нещо зависи от самия контрол. Естествено при мен всичко е опростено на макс.... Драверът, както казах е набор от 3 функции:

DCR(driver control routine) - дето се вика с въпросните get/set контроли и е блокираща, демек някой таск като извика DCR, всичко замръзва, влиза се в супревайзор режим, прекъсванията забранени и се вика DCR-a на драйвера, който естествено трябва да гетне/сетне каквото си иска и да излезе максимално бързо.
ISR (interrupt service routine) - за обработка на прекъсвания ако съответното периферно устройство има такова...
DSR(driver service routine) - това е функцията дето се вика при нова заявка за четене/писане... Всъщност заявката предварително е попълнена в хендъл структурата и функцията получава просто хендъл.

Освен 3-те функци драйверът може да има и две структори - info и data. Едната е за константни параметри и информация, примерно базовия адрес на регистрите и т.н. Другата е за данни на самия драйвер. Той може да се добавя всякакви полета. Чрез структурите драйверът може да има много инстанции. Примерно имам 3 uarta, съответно си декларирам 3 различни набора структури и във всяка попълвам info-то конкретния UART. Инсталацията на драйверите е просто попълване на указател към инфото в един масив където са ми всички "инсталирани драйвери".

Те това е, нищо особено... плюс малко на брой системни функции. Примерно тасковете като искат да четат или пишат от някой драйвер, могат да ползват различни функции. Има блокиращи, неблокиращи или пък функции с таймоут. Но всичките тия функци попълват заявката в хендъла и викат драйвера. Самият драйвер нито го интересува кой е клиента, нито дали ще блокира или няма да блокира докато се получат данните. Драйверът когато е готов само трябва да извика системна функция за сетване на резултата от операцията, която има грижата да събъжда клиента ако трябва.
Още едно опростяване.... почти всички функции си имат вариант за таскове и вариант за драйвери. Дефакто кодът е един, но само драйверите могат да викат директно системните функции. Не че в драйверите се налага да викам много системни функции, но може... За тасковете извикванията стават през SWI-та, които превкючват режимите...
И последнито опростяване е, че системните функции се изпълняват (повечето) при забранени прекъсвания, т.е. не ми се налагат семафори за самия ОС. Няма как докато се изпълнява системна функция да бъде прекъсната. Изобщо семафори дори между самите таскове не ми се налага да правя. За синхронизация между таскове се справям само чрез сигнали. Всеки таск си има по 32 сигнала и те се ползват яко. Това донякъде е разлика спрямо стандартните ОС, но го правя умишлено, защото АРМ е много зле от към семафори... Няма атомични операция, не винаги могат да се забраняват прекъсвания или поне не отвсякъде и не много лесно....

А бе за малките MCU-та каква OS, те имат по няколко килобайта RAM.
Някакъв вид scheduler да поддържа multitasking с ниска латентност
стига, дори стандартизацията на I/O то рядко би донесла нещо.
Та в тоя ред на мисли съм съгласен с Тишо, докато се опитвам да проумея
нечие мислене и да го прекроя за целите си десет пъти ще си свърша
сам работата. Правил съм го многократно за дребни системи.
Но от някъде нагоре, когато вече не е "дребен контролер", ами има
повечко RAM и други ресурси за делба, някаква OS обикновено е
нужна - файлова система, мрежа, графика, прозорци.... В повечето случаи
хората ползват готова такава.