Никола каза едното - за съжаление контролерите почнаха да ги правят твърде сложни... Примерно почти всеки ARM има я USB, я Ethernet. Как ги ползваш? И едното и другото изискват сериозни стекове от хиляди редове сорс код. Изборът е между това да отделиш 1-6 месеца и да си напишеш собствен и това да избереш готов. Ако не познаваш съответните стандарти аз не знам дали изобщо имаш някакъв избор...
Но по-важното за ОС-а е многозадачността, защото примерно Атмел дават и os-less USB stack. Но без ОС си с вързани ръце, защото или трябва да ползваш полиране ако искаш да имаш линеен алгоритъм, или да ползващ кал-бак функции, но така алгоритъма ти става нелинеен. В първия случай USB комуникацията ти става лесно, но не можеш да правиш нищо дрго, а във втория може да изпълняваш и други задачи, но всяка задача ще ти излиза през носа...
А пък се налага да правиш много задачи. В един АРМ имаш средно по 15-20 периферии

Миро, ами звучи нормално. Какво, FreeRTOS няма ли такова нещо? LOL, ми
какво му е OS-овото тогава (не го знам въобще де, просто ми е любопитно).

Моите device driver-и, дето ги спонемах, са едно ниво под това, до което
стигат handle-ярките (аз им викам registration, пълното име би било file registration,
като го съчинявах на времето просто не ми хрумна думата handle). Но файловата
система не е част от много ядра, дето им викат ОС, де.
Аз освен споменатото в моите драйвери имам и т.нар. DDA (device dependent area),
която всеки драйвер може да има (колкото голяма му трябва), а прекъсванията
свързани с дадено устройство са си работа на кода на самия драйвер.
Връзката между прекъсването и драйвера е работа на системата, но това
зависи и от платформата (има разлика как съм го направил за CPU32 и PPC),
но няма нищо специално. Истински специалното е ниската латентност, т.е.
прекъсванията не се маскират освен ако наистина не е нужно (и май не се
сещам някой да ги маскира в код извън самите IRQ handler-и, но сигурно
и това го има някъде - за до три-четири инструкции -, мога ли да помня цялата лудост).

Гледайки нещата от към сложност на проекта, е ясно че няма да тръгна да пиша файлова система.
В момента довършвам проект който е с M32C87. Доста проби направих с ОС преди да си напиша фирмуера сам, и все нещо не ми допадаше като фунционалност(най вече че при наличие на 4 DMA канала ОС не ползваше нито един.). Но там нещата са две 485 комуникации, едно графично чернобяло LCD и етернет контролер ама такъв с хардуерен TCP/IP. В момента фирмуера е около 300к (като кода е не повече от 40к останалото е картинки за дисплея и разни таблици).
Но пък има и нещо друго, повечето неща от кода съм ги писал на принципа добави функция. Демек като ми потрябва нещо което досега не съм го правил си го правя така, че в последствие при нов проект само добавям функцията дописвам още 10-20 реда и готово.

Според мен при избора дали ОС или да си пишем всичко, би трябвало да зависи от сложността на проекта. Определено ако правя нещо с SH4 процесор ще ползвам ОС.

Хм.. Това с четенето на чужд код и на мен ми е доста трудно, особенно ако коментарите липсват...

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

Ако коментарите липсват (т.е. няма достатъчно коментари, та човек да може да разбере какво прави
това нещо на практика *без* да чете самия код), четенето не си струва, направо отива как беше
на unix-ки, >/dev/null .... (на DPS-ки е >#null, имам понятието за безфайлови устройства ).

И аз това казвам

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

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

Тук е трика. Обикновенно е много малко вероятно да попаднеш на грешка в самата OS,Файлова ситема,стек или нещо друго с което са работили много хора преди теб. Нещо ако не работи както се очаква първо търсиш проблема в твоя код. Аз съм се сблъсквал 20тина пъти с проблеми по FreeRtos които съм си мислил че са бъгове на OS-a. Но накрая е излизало че аз съм бил крив. С изключение за 2 бъга които си бяха истински. Единия го изчистиха още в следващата версия на OS-a а другия се получаваше при доста извратена операция която моя мозък беше родил :). Познай колко бъгове ще натворя ако изпиша толкоз много код сам :):). Може и да ми стигне живота да си ги открия и изчистя сам :):)
Иначе неоптимален даже глупав код има. Но нали си работи. А това е важното.


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

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

Верно ако драйверът трябва да поддържа всички гъдели на хардуера става по-тежичък, но като изключим USB драйверите ми са обикновено не повече от 200 реда код. Но макар да са малки, обикновено са трудни за изчистване от бъгове и затова предпочитам да ползвам една универсална версия, вместо да оптимизирам за всеки конкретен случай.
Винаги мога да направя една или друга версия на даден драйвер, но по-важното е *всички* драйвери да имат универсален интерфейс. Някой по-горе спомена че това е нещо като "общ език" и ползите от него са големи. Примерно това позволява един таск да си говори с няколко драйвера и/или таска едновременно. Да кажем чакаш нещо от UART-а и в същото време някакво друго събитие.
Ако нямаш универсален общ интерефейс няма как да го направиш лесно това лесно.
Изобщо ползите от универсалния интерфейс са толкова много, че аз даже си вкарвам драйвери за нетипични периферии - примерно не знам как ти звучи драйвер за GPIO

Ето реално примерче в което пускам малко "таск-че" дето трейсва всяка промяна на един пин:


Може би изглежда объркващо щото не съм си направил специализирани макроси за GIPO-та и някои параметри се подават с кастване.... Но въпросът е че всеки един таск може да блокира в очакване на промяна на пин и това става със стандартни операции, т.е. мога в един таск да си пусна четене от пин, четене от UART и още куп неща и след това да заспа докато поне една операция приключи...
Няма полиране, няма губене на процесорно време, няма пръскане на код, щото ти за да го направиш същото ще трябва да "бръкнеш" и в прекъсването на PIO контролера и изобщо не ми се мисли как ще ти изглежда кода ако на 10-на места ти трябва чакане на пинове...

В случая аз се опитвам да гледам на "bare metal или ОС" като на начин за организиране на многозадачна система.
Преди време в момент когато имах конкретен проблем за разрешаване ми попадна една статия за protothreads на Adam Dunkels. Бях чел за тях покрай разглеждането на uIP от същия автор. Но този път ми просветна как мога да ги използвам за да си реша проблема. От тогава до сега съм ползвал още няколко пъти същите идеи, но издялкани според случая. Само че не съм много доволен от този подход.
Например проекта по който работя в момента го започнах с писането на малки тестови програмки за тестване на отделните части от хардуера и проверка на идеите които смятах да използвам. После сложих USB стека който ползвам в няколко проекта вече. След това за около седмица направих основната задача - синхронно мерене по няколко аналогови канала и известна обработка на резултатите. Всичко това със съответното тестване. След това добавих писане във сериен FLASH. Добавих серийна комуникация с една клавиатура която се включва като допълнение. После пуснах големите трансфери на данни да вървят по ДМА и т.н.
И така лепиш отгоре като лястовиче гнездо, тестваш по отделно и след всяка промяна... Трябва да има някаква твърда основа цялата организация на многозадачността. Трябва да има гръбнак около който да се организира конкретното приложение. Трябва да има принципи които да се спазват при писането на кода на приложението и драйверите.

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

А коментарите са нож с две остриета. Ако не са синхронизирани със сорса. А може и съвсем тънко да заблуждават. Например следния коментар: // Изчистваме флага за прекъсване. В някои случаи е по-добре да се напише: // Опитваме се да изчистим флага за прекъсване. Щото понякога веднага след изчистването може да възникне ново събитие и прекъсване. И ако гледаш на сорса само като на С сорс с коментари без да имаш на заден план в главата си асинхронните събития които вървят, идваш до познатия момент с чесането на главата.

Миро, проблема с по-сложните ОС е че когато започне човек да пита сякаш усещам как отсреща поемат дълбоко въздух преди да започнат с абстрактните обяснения. Мисля че разбирам някои от идеите ти, но твоята ОС е доста далеч над bare metal. Това което пишеш за събуждането на таскове от съответно прекъсване е точно както и аз си представям една многозадачна система. Бях останал с впечатлението, че таскерите са само time driven. Явно съм се бил заблудил.

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



Пак подчертавам че не съм измислил топлата вода.. няма мои или твои идеи (поне засега)