mass storage-a има два недостатъка - първо предполага изключителен достъп, демек като захапе USB-то трябва да спреш фатфс-а. И второ предполага FAT, с нестандартни файлови системи става сложно...

Та има някакъв нов usb клас - multimedia нещо си... На таблета го имам, но не съм го разучавал. То май няма много информация, четох че първоначално го измислили за фотоапарати (picture transfer protocol или нещо от сорта беше). С две думи това позволява устройстовото да си бачка и да си ползва картата и в същото време като го закачиш на компютър (usb host) и той да му вижда файловете.
За повече информация трябва да се чете... аз не съм стигнал до там. Като стигна ще кажа, пък ако някой е минал по тоя път вече - да казва

Темата е стара, но ровейки днес из нета попаднах на това:

RTX with CMSIS-RTOS API under Open Source License

http://www.keil.com/pr/article/1253.htm

РТОС-а се дистрибутираше с КЕИЛ МДК-то, но преди година са сменили лиценза и са отворили сорсовете.

Компилира се и с ГЦЦ.

Media Transfer Protocol е това, за което Миро говори. Съгласен съм с описаните му предимства, но имайте предвид че на XP много често не сработва (не намира драйвер). Не знам как и къде се съпортва, но ако някой се насочи към него да пробва с мобилно устройство за подобни проблеми.

Напоследък и аз си поиграх с чибито, на ниско ниво не съм ходил да ровя, но това че няма драйверна подсистема е , меко казано, заблуждаващо. Сигурно липсват някой драйвери, това е нормално за по-новите чипове.
Кое не ви харесва в имплементацията му? За мен всичко си е наред. В момента в който ОС-а ти предоставя ефективни средства за имплементацията на ISR към IST, значи всичко е наред. Не е проблем на ОС-а това че някой работи с портове, без да ползва API-то на GPIO драйвера, или жули ДМА-то пак директно през регистри.
В случая, ако има пропуск, можем да говорим че Джовани е имплементирал нещо зле (но ми се иска да видя конкретен пример за това преди да се съглася). Но чибито в никакъв случай не налага такъв начин на ползване.
Това че липсва силово наложена, задължителна, претрупана подсистема, т.е. някакъв тиртип за правене на драйвер, за мен е предимство и е свобода да се работи както е оптимално за конкретния чип, продукт или фирма.
Прекалените генерализации и универсални интерфейси са в тежест за приложения, в който няма динамично зареждане на софтуер, няма динамично добавяне на хардуер и тем подобни. Т.е. в така наречените ембедед системи. Набора от периферии, с който ще живее тоя продукт докато стане на скрап е заложен на конкретната платка много преди да е мислено за софтуера, дори си е точно определен от типа на чипа. Наличието на бъсове като УСБ, които ви създават главоболения не променя нещата - и SPI, и I2C, и CAN са бъсове и са си там от много години. Няма нищо принципно различно в по-новите (от гледна точка на драйверите за периферия, т.е. на USB HOST драйвера да кажем). Другото са софтуерни модули, реализиращи протоколи - точно както модбъс върху сериен или тцп.
Тия 20-30 таск-а, с които "заплашваш" Цецо, са тотално излишни за подобна система и означават грешно организиране на софтуера, което понякога е наложено от споменатите от теб "подсистеми". Примерно можеш да наложиш да има по един RX и TX таск на всеки клиент на даден драйвер - и така може, ама е грешно и ненужно. На кортекс ядрото нямаш нужда от повече таск-ове, отколкото прекъсвания ти трябват за да обслужиш използваните в дадената конфигурация (разбирай, приложение) периферни контролери, плюс един таймер за времезакъсненията и таймаутите. Но това изисква кода е написан чисто, структуриран правилно и отделен от другите нива, като ОС например.
Джованито си има идея за драйверите, и ако се замислиш, тя си е напълно коректна и много елегантна, без да има излишни неща.
Пак казвам, че ако някъде не е отделил нива и има директно, конфликти достъпи, значи просто не го е довършил. И ми се иска да видя тези места.
Един хинт за размисъл - какви събития има в една система, различни от периферните прекъсвания? Идеята на "wait for interrupt" на ядрото (sleep на други процесори) е много важна. Когато работата на всички таск-ове завърши, само и единствено прекъсване може да събуди системата. Това е логиката - няма друго освен периферни събития. Е, има периферии които просто не могат да генерират дори базовите такива, и искат polling, но това значи кофти хардуер. И се решава с полинг, ама само за това липсващо прекъсване.

Аз имам една теория, или по-точно визия, за тези неща. Драйверът на дадена периферия има една-едничка задача - да скрие спецификата на КОНКРЕТНИЯТ КОНТРОЛЕР и да предостави API за клиентите си, максимално близко до ОБЩАТА ЛОГИКА на контролирания обект, например бъс. Пояснявам - има десетки различни I2C контролери, всеки със собствен набор регистри, прекъсвания и така нататък. Работа на конкретния драйвер (при чибито това е *_lld.c) е да знае и работи с този конкретен контролер. И ДА НЕ ПИПА други контролери директно, а само през драйвери, подобни на него си (ДМА, ПОРТ, ПРЕКЪСВАНЕ). Извън този драйвер, т.е. навътре в софтуера, се намират неговите клиенти. В примера с I2C това са други софтуерни компоненти, например по няколко драйвера за:
- сериен епром тип 24LCxx
- дигитален потенциометър
- сензор за температура
- ....
Всички тези клиенти:
- не се интересуват дали са на ПИК, AVR, ARM или на ПЦ симулация(за тестове), т.е. какъв е I2C контролера
- им се налага да знаят какво е това I2C шина - че има адреси на нея, и че по нея могат да се пращат данни напред и назад
- нямат задължението да минават изкуствено през генерализиран интерфейс от типа на read/write/ioctl
Това пращане на данни напред и назад е единствената работа, която те имат, и за която имат нужда от I2C драйвера. Драйвера за епрома има нужда да работи само при възникване на събитие от тип:
- прекъсване от I2C контролера (регистрирано през драйвера за закачане на прекъсвания)
- заявка от горе (например, файловата система) за писане или четене
- таймаут (който също се заявява през "драйвер" за таймерни услуги)
Първият ред е ясно че е прекъсване. Таймаут-а реално пак е долъш от прекъсване - този път от HW таймер на чипа. Заявката за четене или запис също са възникнали поради прекъсване, макар и не директно, а преминавайки през други модули. Примерно UART-а или MAC-а са вдигнали прекъсване за налични данни, драйвера на UART-а е сигнализирал на протоколната стейт машина че има данни, тя е разпознала команда за запис в I2C и стигаме дотук.
По пътя може да се наложи смяна на приоритета на това събитие, т.е. scheduler-a да смени таск-а (например ISR-a стартира съответния thread, за да може да се освободи за следващи данни). Това зависи от системата, ако има ОС значи ползваме ОС-а за целта (мейлбок, кю).
Само че има и случаи, в които не искаме смяна на контекста, защото знаем че прекъсванията идват рядко (FIFO в периферния контролер) и знаем че контекст switch-а дърпа двойно повече време от пълната обработка в клиента. В този случай единственото, което трябва да се подмени, е "връзката" между ISR и IST, т.е. как ISR-а вика IST-то. Реално аз ползвам в тази точка няколко избираеми механизма:
- директен call (не ми трябва ОС, няма забавяне от switch, но може да се стигне до overflow на контролера и загуба) - има проблеми само когато се обслужват повече от един клиент през един контролер, или протокола поддържа множество паралелни логически сесии (т.е. няма проблем в случая с AT команден интерпретатор :- )
- софтуерно прекъсване - в комплект с горното решение би трябвало да покриват 99.8% от ембедед приложенията
- ОС - когато го има го ползвам като алтернатива на софтуерното прекъсване, макар да няма принципна разлика и да няма предимства.

Ей, Гичо, на тия работи последните 50-ина години им казват "device dependent I/O" и
"device independent I/O", част са от всяка операционна система .

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

Радвам се че има дискусия.
При ОС-овете с общо предназначение може и да се гледа ефекта на улесняването на приложенията с цената на консумиране на ресурси и ниска ефективност. За да могат милионите уеб програмисти да пишат на кило, без да имат идея какво пишат. За да могат хора без идея какво има отдолу все пак да напишат нещо. И това е полезно, но не и в ембеддед системите - просто не са толкова масови. Е, има и масови, за по-ниско квалифицирани любители - ардуино например.
Здрав, можеш ли да ми дефинираш какво е то туй "вътрешен тик на системата"? Какво е то туй, дето е вътрешно, и каква е нуждата от него за потребителя, за какво е там, щом е вътрешно? Има и tick-less ОС-ове, и напоследък хардуера се прави с идеята да се прави така - SysTick, HPET (и в ембеддед, че и в GPOS). И tick-а се заменя с реални, необходими събития, моментите на изтичане на таймаут-и например. Реално какво има в tick кода на ОС-а - проверка на списък с активни таймаут-и генериране на събития ако някой изтече. Т.е. имплементация на софтуерни таймери на база на един хардуерен такъв (т.е. на едно таймерско прекъсване). Другото е за round robin викане на таск-ове с равен приоритет, което пак е доста уклончиво, и рядко имплементирано в ембеддед (е, чибито го може и това).
Прекъсванията не синхронизират свободно въртящи се вътрешни процеси, напротив, те са реалния "тик" които тактува нещата. Вътрешните процеси са дейности, предизвикани от външни събития. Няма такова нещо като вътрешен процес, който да прави неща от само себе си, или за себе си - просто няма смисъл от него ако той не контактува с "външния" свят. Точно това е принципната разлика - откъде идва "повика" за свършване на нещо. Дали тик-а е водещият? Доста RTOS-ове могат да си вършат основната работа чудесно без нужда от таймер, стига реално да не се стига до таймаут поради някакъв дефект, и да не разчитат на "sleep" в таск-овете си, за да подменят хубавия preemtive multitasking в кооперативен такъв.
Има варианти отгоре надолу, и отдолу нагоре. И двата се ползват, но това не значи че са равносилни по ефективност. Особено ако говорим за хардуерна абстрация и драйвери на хардуер - там няма съмнение. Нагоре ако има нужда може да се обръщат нещата, да се конвертират интерфейси и да се правят компромиси. Моята мисъл беше че правилно структурирания модел на драйвера, това за което миро говори, трябва да позволява да се пишат драйвери с различни подходи, без да налага ограничения. Т.е. в изходната (и входната) си точка да може да се закачи както към елементаристична система само с прекъсвания, така и към коя да е ОС, така и към междинния вариант на софтуерни прекъсвания. Досега не съм видял ОС, която да може да си позволи да предлага само варианта с "device independant I/O", винаги има и варианта със зависимите. Което само по себе си значи че независимите са приложими в частни случаи.
Какво значи да ползваш ОС-а с неговите услуги като алтернатива? Да му повикаш API функция, в която да сигнализираш че вече нямаш какво да правиш, и искаш да пратиш сигнал за необходимост от друго, следващо действие. Т.е. по твое усмотрение, в избран от теб момент, да поискаш rescheduling - значи, да генерираш вид софтуерно събитие (прекъсване). Това, което трябва да има в тази точка на кода, в сорса на драйвера, трябва да е гъвкав код който прави точно и само това - сигнализиране за нещо случило се. Оттам насетне дали това сигнализиране ще вика директно функция на друг модул, или ще вдига флаг за софтуерно прекъсване, или ще вика API на ОС-а, то потребителя ще реши за конкретния проект в зависимост от следващите компоненти, които ще консумират това събитие и данните от него. Пак той ще раздаде приоритетите в системата. Колкото и да звучи примамливо, няма как това решение да бъде взето предварително от някой, който не знае спецификата на проекта и изискванията към него.
Колкото до моделирането на UI, съгласен съм че е дълбока тема, и често пренебрегвана, може би именно поради сложността си. Не че при правилният подход не се стига до резултати, но все още пазара поема и недовършени неща. Броят възможни събития е известен във всеки един момент, така че единствената трудност е че този брой обикновено е голям. Прескачането на тази стъпка не спестява време, за да се стигне до качествен код моделирането се замества с диво тестване на ръка.

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

меко, меко, колко да е меко като няма (null) изобщо драйверна система?

Иначе поздравления, че си седнал и се ровиш. Това е пътят. А относно драйверните системи не знам дали на теб ти трябват и дали искаш да разучаваш тая материя, но ако искаш бих ти препоръчал да погледнеш как работи примерно Windows Driver System. Просто тя е доста добре документирана (MSDN), иначе всички големи ОС-ве, че и по-малки като да кажем ecos имат също.
Ако не ти се чете накратко пълната картинка включва API, драйверна система и с нея бъс драйвери, клас драйвери и дивайс драйвери. Обикновено има (не е задължително обаче) някаква абстракция демек HAL, но не е един лейър само а е пръснат - в АПИ с което бачка клиента е видимата част. Останалото е пръснато, т.е. нещата дето са къстъм за конкретната периферия и производел са в дивайс драйвера, общите за тоя клас устройства са клас драйвера и т.н. Нещо подобно си видял и в Чибито, но не си видял драйверна система, защото такава няма или поне аз не мога да я видя (въпреки че съм човъркал десетки осове).
То по принцип една добра драйверна система наистина е невидима с невъоръжено око Простичко казано товане "лепилото" и не е желателно да се набива на очи... Все пак ОС-а трябва да изолира клиентите и евентуално АПИ-тата от драйверите. Обикновено това става през 2 тръби - една за команди или синхронни заявки и друга за данни или асинхронни заявки. Ей тия тръби ако не видиш, значи нищо не си видял от драйверната система
При някои ОС-ве освен тръбите драйверната система включва и други карантии, но тръбите са принципно най-съществената част. Значи ако концепцията за HAL ти дава някаква основа за работа с хардуера, то тръбите са концепция за работа с драйвери изобщо. По друг начин казано това е стандарта на съответния ОС за интерфейс между какъв да е клиент и какъв да е драйвер. Ключът на бараката е "какъв да е". Не е ли прост и универсален тоя интерфейс - забрави за тоя ОС!
Предплагам, че може да ти е трудно да го разбереш сега, но това е нещото което осигурява гъвкавост. Примерно един девайс може да ти е закачен на PCI шина, или AGP или скъзи или през 1394, или комбинация от 1394 през pci. Абе дори да е на SPI или вграден в проца пак няма значение, защото ако ОС има драйверна система, тя ще осигури "тръбите" от клиента до драйвера. И другата магия в тръбите е, че за някои неща примерно данни могат да си осигурят директна връзка. Но за други драйверната система е посредник. Примерно сигнализацията задължително става през посредника, т.е. клиентите пращат заявки кой когато му скимне, без значение дали драйверът е свободен или зает. Драйверната система има грижата да подреди заявките в опашка и да ги подава когато драйвера иска. Когато драйвера обслужи заявката той само казва "върни тва" а пък системата има грижата да сигнализира клиента. Така драйверът не се интересува кой клиента дали е някакъв таск дето трябва или не трябва да се събужда, дали е друг драйвер и т.н.

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


ааа... абе ти пак си писал, е.утре ще ти чета, ама честно казано не ми се спори или дискутира.

Това е прекалено конкретизирано. Tick означава наличието на някакъв часовник, какво и дали някой
прави според него е отделна работа. Примерно в power има 64 бита "system timebase registers"
(всъщност са 2 32-битови), които просто се въртят безспир. По-рано в 68к това ми се налагаше
да го правя с таймер. Тия регистри са част и от user level регистровия модел, т.е. винаги могат
да се четат.
Пак в самата архитектура има и т.нар. decrementer регистър, който брои надолу и генерира
прекъсване на 0. Много по-удобен и опростен начин от това scheduler-ът да си осигури изкарване
на таска след определено време ако той не излезе сам преди това едва ли може някой
да измисли. В 68к версията на DPS-a пак ползвах таймер (периферия) за целта.



Няма нужда да се избира между preemtive и cooperative. По-лесно е да се намаже само
така или само инак, но нищо не пречи тасковете да си излизат кооперативно и да бъдат
зорлем изкарани само ако се заплеснат над даденото им време (както е в dps-а открай време).



"прекъсване" не е равно на "софтуерно събитие" поне в моя речник.
Прекъсването може да е хардуерно (IRQ жица) или софтуерно (trap инструкция).
Освен това с думата прекъсване има свързани още куп детайли които не са свързани
с понятието "софтуерно събитие".



По-просто от това е обикновено всъщност. В dps даден драйвер като види, че има да
чака, просто трябва да излезе (за rescheduling). Може да го направи със или без съгласие
за приспиване на системата (която ще бъде приспана за някакво време ако всички живи
таскове са излезли с такова съгласие).



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

задълбахте в тежък теоретизъм, за който има десетки "съвременни" течения и теченийца: extreme programming (XP), Test-driven development и т.н.
според мен може много да се спори, доколко тези методи за писане на софтуер са удачни, особено на фона на днешни крайни продукти и особено тяхното качество.

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

Не знаех, че му викали XP.
За приложението и единствеността му (поне съотнесена към програмирането) съм 100% съггласен,
всъщност няма съществен софтуерен продукт написан от повече от един човек. Многото идват
и доомазват картинката след като продуктът вече се е наложил. Но то програмирането и писането
на литература си приличат немалко (само дето програмираното трябва и да работи ... ) та
не е толкова изненадващо и това, колко колективно написани неща са били запоменени с нещо.

По-добро обяснение за ХП не бях чел. Евала

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


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



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


Тъй де, още една форма на таймаут, или времеделене (time quanta), засегната вече в темата за тик-а. Ако на дадения хардуер (т.е. е дадения порт на ОС-а) имаш 666 таймера, няма лошо сървиса за таймаут на ОС-а да ползва всичките таймери (по един за приоритет на таск примерно) и да оптимално да ползва хардуера. Ако на следващия чип има един 8-битов, имплементацията на таймаут услугата в kernel-а се променя. Имам предвид че всички изредени време-базирани услуги трябва да минават през драйвер за таймаут, включително имплементациите мейлбокси на ОС-а. Така и те ще могат да се възползват от 666-те хардуерни таймера, или не, според хардуера.


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

Аз говоря за event-базирани системи. А в нашите среди всички обекти са такива и правилното описване / дизайн / моделиране е по този начин. А оттам идва и да търсим такава реализация в кода.


Е, няма какво да говорим, според теб значи само DPS-a е съществен продукт Че е най-удобно да си го напишеш сам, може би да, ама за да стигнеш до съществен продукт ще ти трябват доста години.
Всъщност, кой съществен продукт е написан от сам човек? Или какво разбираш под продукт - ако говорим за компонент от рода на кърнел, алгоритъм или нещо подобно съм съгласен. Ако говорим за съвкупност, за цял софтуер, не съм.
Имам спомен от един приятел, техният бизнес вървеше на подобен принцип (малък екип) до момента в който изкараха версия и един от големите хареса идеята - 6 месеца по-късно бизнеса им тотално умря, сещаш се защо - големия беше изкарал еквивалентен продукт и можеше да си позволи да го продава много по евтино. Не че бяха откраднали нещо от тях - тотално различна имплементация. А те го бяха мъчили 4-5 години. И пари нямаше.
Изключения могат да дойдат от уникални хора, имащи уникални идеи. И сигурно за тях е по-добре да бъдат оставени да развиват идеите си самостоятелно, без да им се пречи. Но (вие сте) единици. И предполагам че при твоите продукти е съвкупност от идеи, хардуер и софтуер.

Е такова е де, баш като таймер си е. Но е част от регистровия модел на процесора а не от периферията,
т.е. няма как някой да ти продаде "power architecture" процесор и да забрави да ти сложи такъв таймер.
Инак функционално е същото, слагаш му там колкото бройки искаш (тоя моят сега май е на 8MHz
наклочен някъде) да отброи до прекъсване и пускаш таска да пасе.



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



О не, защо бе? Всеки процесор си има свой си decrementer регистър и всеки таск си получава
ограничението преди да бъде пуснат колкото поиска да му даде scheduler-ът, разрешаването
на приоритетите е отделно/допънително, в смисъл кой таск да избере в за пускане scheduler-ът,
това може да зависи от зададени приоритети и да се влияе пряко от външни събития, но са
все софт механизми (настрана от евентуално някое IRQ което да сложи заявка за еднократно вдигане
приоритета на еди-кой си таск и да вкара машиината в rescheduling - което го имам и звучи много
добре ама почти не го ползвам).

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

От твоята гледна точка сигурно си прав. Моята е че съм се борил с наложени ограничения "щото такава била системата / идеята", щото така се правело в Вин/Линукс/ххх.
Спорът тръгна от това, че твърдиш че в чибито нямало драйверна подсистема - е, има, не е като твоята, но приеми го че има и други варианти.
Изискванията към ембеддед се различават от тези към общопрактикуващите точно по няколко неща според мен:
- степен на специализация с цел производителност и сигурност - излишни неща не се толерират с едничката цел да му е комфортно на всеки трети машинописец с компютър, ако ще работиш в тази област си длъжен да имаш знания и разбиране;
- начин на "deploy"-ване на кода
= на персоналните компютри по презумпция работят потребители, а не специалисти; това налага да се мислят варианти за безкрайно лесно качване на нов код;
= при ембеддед се прави почти стриктно тотална "преинсталация" под формата на ъпгрейд на фирмуера (когато има да се деплойва нова функционалност, пък дори било то само бъг фикс)
= при ембеддед конфигурацията на системата е практически константа - изключвам вариантите когато има опционален елемент като sd карта, усб устройство , но и тогава се очаква наличие или липса на един от няколко поддържани типа; тука усб-то си е много добре с разделението на класове устройства; т.е. на ниско ниво конфигурацията пише "има USB HOST, 2 броя"; отделно тия допълнителни устройства рядко могат да са произволни, просто защото никои сериозен производител не допуска ей така да слагаш устройства от кол и въже, а първо ги проверява за съвместимост, и то наново с всяка версия на софтуера)
= от горното следва че при ембеддед почти винаги имаме "прекомпилиране" на софтуера; прекомпилирането е техника за напреднали, която се поддържа от всяка ОС (вкл. вин, уникс, ххх).
= при GPOS почти винаги се работи с опознаване (PnP) на наличния хардуер, по простата причина че за да има успех сред потребителите този ОС, то той трябва да може да върви на хиляди различни конфигурация; ако се тръгне с монолитен фирмуер това значи размерът да стане непригоден и времето за стартиране да се удължи неимоверно (то лесно ще разбереш че имаш у-во ААА, ама докато му извадиш драйвера от архива на фирмуера може да минат минути); в линукс, както знаем, всеки един драйвер (kernel module) може да се вгради в самия кърнел и практически да няма нужда от зареждаеми модули (ако предварително е известен набора от устройства, с които ще се работи). Оттук идва и по-бърз и малък код, най-малкото заради по-ефективната работа на компилатора по оптимизиране на целия код.
= при ембеддед се разчита на предварително дефинирана хардуерна конфигурация (board.c, board.h примерно). Ако има вариации в някои от модулите те са описани там подходящо, с информация кой е задължителен и кой е опционален, и кой кого може да замести); съответните драйвери трябва да имат начин да кажат - намерих си съвместим хардуер, или не; това е и една от промените във версиите на линукс за ембеддед устройства - стартирането и описването на хардуера.

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

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