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

Има и още един аскпект... Значи драйверите не са всичко и не са еднакви. Може да са прости както е да кажем УАРТ, ама може да са малко по-сложни. Пълната картинка е:
1) Bus driver
2) Devices
3) File system or language

където бъс драйвера е интерфейсната част на стандартен драйвер, който обаче не си говори с хардуер а с девайси. Девайсите са всъщност нишки.
Примерно имаме root driver в него са монтирани като девайси един или повече слотове за SD карти или дейтафлашове и т.н. Като тръгнат те почват да си детекват и примерно SD картата като й ръгнеш FAT се създава 3-тия елемент - файлова система, който на практика е С++ клас (обвивка на fatfs). Имаме и наши си файлови системки. Общо взето е динамично, т.е. каквото ръгнеш това тръгва...
Същото е с принтерите, сега тъкмо правя usb хост, ръгаш... и то си детеква, инсталира... Приложението обаче няма грижи за тия работи.
Казвам това защото при тоя архитектура драйверът е всъщност много прост - 2 функции по 20-на реда. Няма какво да се динамизира.... Най-обемисти са файловите системи (езици) но те са динамични като концепция. Единствено както казах интересно ще е да се линкват и като динамичен код.

В бъдеще при първа възможност може ще сменя само индексирането на драйверите. Навремето си мислех че трябва да е просто и затова го направих драйвера да се указва по номера му в таблицата. Примерно ако прекъсването на УАРТ2 е 5-то поред то драйвера му е 5-и номер. И така се отваря хендъл - казваш отвори 5-и.
Но като добавихме и файловете системи вече стана сложно и се наложи викане на второ отворяне. То пак има някаква логика в смисъл първо отваряш хендъл към руут-а с какъвто номер се пада там. После викаш отваряне на файл и се дава стринг от сорта "/sd0/1/file.txt" където sd0 e съответния слот, после 1 е дял-а и след това пътя е ясно... Естествено може да листваш, т.е. да видиш какви дискове има монтирани, те какви системи и дялове имат, какви файлове и т.н.

Та така де... темата е безкрайна

да, прав си. всъщност не си поставих правилно въпроса и оттам объркването. интересуваше ме този ос може ли да се докара до ниво, където да изпълнява външно подадени апликации (дори и под формата на драйвер или там както искаш го наречи)? демек за пример ти давам винцето (win ce), седи си някакъв прекомпилиран сет от функции във флаша и цялата периферия е фиксирана, но ако речеш, можеш да пуснеш и нещо твое по време на изпълнение, без да се налага да прекомпилираш всичко и да слагаш твоя код вътре. не знам дали си ме разбрал, но предполагам ясно се изказах

не, нямам го като фючър...
Може да се добави, знам как.. всъщност в nuttx-а го има и там даже май имаше и динамично линкване ако не греша. Макар че по принцип при мен динамично линкване не е толкова важно, защото повечето ми системни функции, включая и работата с драйверите става през SVC/SWI т.е. няма адреси и няма нужда от линкване...

Но.. както намекнах нямам намерение да го правя, защото си мисля че имам по-добро решение. Повярвай ми от много години се боря с тоя проблем. Мислил съм какво ли не - PIC (position independant code), мислил съм за интерпретаторни езици, но все има недостатъци.... Скриптовете са бавни за някои неща, линкванията пък рано или късно пак създават ядове. С една дума не ме кефи...

За съжаление решението към което сме се насочили не е толкова универсално. Но за определен тип проекти, да го кажем клиент-сървър приложения мисля че ще се получи. Накратко пак е нещо като скрипт логиката, ама не интерпретатор а имплементация на Ц++. Още не е написано, само планове... Идеята е от опита ни с WML. Там сървъра ти дава страници, в страниците освен визуално да показват нещо може да изразяваш логика, защото има понятия за event, има понятие за променливи има понятие за задачи. Може да кажеш при това събите да се изпълни тая задача и т.н.
На тая основа ще направим първо GUI-то. Ако искаш да отвориш някакъв джам подаваш стринг. Тоя стринг може да ти е в кода, а може да си го получил отвън нама значение. Практически няма да стане по-бавно от сегашното ни GUI, но ще работи по-лесно и по-гъвкаво. По подобен начин е и комуникацията със сървара и другите задачки. С две думи няма да ни се налага смяна на фърмъера, защото почти цялата логика е в стрингове. Променяйки съдържанието на стрингове се променя почти всичко... или достатъно

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

Освен nuttx сега се сетих че и Тейлър ( www.coactionos.com) също предлага вариант за динамично линкване...

nuttx е сложен до ниво минимум два аналгина на ден
това другото не съм го и чувал даже...

уф... аман от капризни клиенти

Хем без пари ви предлагаме неща, хем недоволни

кой е недоволен бе, аз само разпитвам за възможностите

Миро, гледам сега ОС-а, в частта му за STM32 естествено.

Нещо не мога да открия драйвер за GPIO-тата. За луминари и атмел има. Ама за STM32 не го откривам. Аз ли гледам криво?

Исках да видя как си организирал тред сейф операциите при работа с пинове.

Значи малко инфо преди това...

Всеки проц (независимо от производителя) дефинира pio_set тип, това е битово поле за колкото пина там е порта. При Атмел са 32-битови портовете, при ST са 16, при Луминари май бяха 8..
След това всеки си експортира PIN_DESC - това включва един или повече пинове от сет-а плюс описание как да се конфигурират. В описанието може да кажеш дали е вход/изход/ пин на периферия, абе там каквото поддържа чепа. Допълнително съм добавил активно ниво, за да може да го асертваш...
Обикновено в един хедър си слагам дефиницията на всички пинове от платката, изглежда примерно така:



Освен това за всеки проц си имам и набор от функцийки (не драйвери, просто функции):

Oбикновено се ползва PIO_Cfg() - конфигурира по даденото описание, естествено Read/Write четат/пишат, Assert/Deasset сетват изходи в активно/неактивно ниво и т.н.
За STM F2 може да видиш как са направени в gpio_f2.cpp.
Ползвам атомични функции (с LDREX/STREX) за да барам регистрите и да е thread safe

Всичко до тук няма нищо общо с драйвери... По-скоро е унифициране, така че да работиш с пинове независимо какъв ти е проца... Иначе драйвер ти трябва когато искаш да ползваш прекъсвания. Може да разгледаш key_drv.cpp - това е виртуален клавиатурен драйвер. Сканира клавиатура там дебоунс ала-бала... Виж нишката му key_drv_thread(), тя отваря хендъл към GPIO драйвера и после с тоя хендъл може да се чете и пише. Естествено четене през хендъл е една идея по-бавно от PIO_Read(), обаче ако се ползва tsk_read_locked() четенето излиза само след промяна (т.е. след прекъсване което си указал в дефиницията на пина).
Всъщност и в demo_evals има пример с нишка дето мига светодиод и друга чете бутон. Забележи че не се грижиш за прекъсвания, шини и глупости, може да си пускаш колкото нишки искаш, те да четат различни пинове... и всичкото това е платформно независимо, демек ако ти кефне утре сменяш чепа и само прекомпилираш (ех почти де)

Това горе долу ми е ясно. Но не виждам driver за gpio в директориите за STM32. за луминари си има gpio_drv, за Atmel - pio_drv, с разните му там dcr, dsr и isr. Ама за STM - тц.

Едит: да не е exti_drv, това дето издирвам?

да, exti-то е щото драйвер се прави за прекъсвания основно, пък ST там са заврели прекъсванията...

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

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

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

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

Принципно драйверната система си се грижи за синхронизация, така че клиентските нишки нямат нужда от допълнителна синхронизация. Примерно ако на един и същ SPI имаш дисплей, дейта флаш и още неща, SPI драйвера си се грижи да не стават инфекции. От там насетне всеки клиент си ползва неговото си нещенци и не му пука за останалите. По същия начин е в GUI, както и всякакви стекове... Е, като махнеш драйвери и стекове какво друго имаш да споделяш? Остава някакви си твоя абстрактна софтуерна логика. Ми прави си я както намериш за добре Имаш на разположение сигнали, всеки таск има сигналчета, може да блокира или да не блокира, специално куртекса пък има и есклузив load/store и може да си правиш доста неща.
Аз по принцип съм фен на едно общо синхронизиране. Целта ми е една нишка да може да чака за какво да е... мразя полирането. Затова всичко го правя със сигналчета. Така може една нишка да чака сигнал от някакъв интерфейс/мрежа/сървър, сигнал от лузера (GUI-то) сигнали още от един куп неща плюс таймооут разбира се. Ако се ползват различни синхронизационни примитиви обикновено става боза. Примерно ако едното ти е на критична секция, другото на семафор, третото на опашка кво прайш? Ще ги полираш ли?
Всъщност големите ОС-ве позволяват да правиш синхронизационни обекти за различните примитиви и накря да ги обединиш в един общ WaitForMultipleObjects().. Ама чак такива глезотии не мисля че са нужни за малките ни куртексчета. Дюс мама, дюс.. семплото не е за нас!

Страхувах се, че така ще ми отговориш. Какво имам да синхронизирам - ами една нишка примерно чете данни от SPI. Буферира ги и ги дава на главната. Главната ги обработва и дава на друга, която пък ги записва на флешкарта (през друг SPI). И това си тече като стрим. Ta трябва ми някаква форма на поща, опашка и т.н., тръба по която да търкалям пакети. Вероятно ще ми кажеш да си я организирам сам, не е сложно. Особенно на c++, дето алокирането на памет е по-опростено.