Чакай сега, какво очакваш от микрокърнел за ембедед - да има мрежови стекове вградени? Алокатори бол, но като се замислиш явно си вършат задачите без да им трябва динамична памет - което не е кусур, ами пример за подражание.
Библиотеки? Това не е гитхъб, библиотеките за това са библиотеки защото са отделно.
На мен примерно ако не ми трябва мрежа, или ssl, защо трябва да хабя време и мрежов трафик да ги дърпам, и то точно техните? Какво да го правя тяхното GUI - може да не ми трябва изобщо GUI, може да не искам тяхното? Като ми трябва стек има lwip и подобни - е те това е библиотека, която може да се ползва и с други ОС-ове, но може и с този ОС да искам друг стек. Къде трябва да е "връзката", която според теб липсва?
А HAL-а им е точно както го харесвам - незабележим, т.е. неналагащ свой стил и сложен абстрактен модел. Имам предвид без напомпани абстракции да докараме SPI да прилича на UART, или I2C на ethernet, или USB на firewire и т.н. И зависимости от типа всеки зависи от всеки.
Ако погледнеш примерно драйвера им за ADC на някой STM ще видиш много конкретен код за АЦП точно на този стм, а не на някакъв утопичен абстрактен преобразовател дето може да има PGA, или да няма, да има софтуерните граници на нивата (компаратори), може и да няма, който за някой таргети 90% от функциите са празни и връщат грешка дето трябва да я гониш рънтайм, вместо чисто и просто да видиш че я няма. Как се прави това абстрактно? Какъв интерфейс ще ми върши работа в моето приложение да го ползвам? Как аджеба ще си сменя "абстрактно" времето за семплуване? Предполагам с IOCTL - и какво правим когато попадна на таргет дето не поддържа тоя IOCTL - грешка ли да вдигам, да се правя на невидял ли? И като избера някакво поведение, дали няма следващия дето е решил да ми ползва приложението или кода да ме псува че съм избрал нещо, което по начало не е било моя работа (да решавам интеграционни проблеми)?
Трябва да си отворим тема, или то май ще е по-скоро раздел, за "софтуерно инженерство"? Предполагам че ще има какво да обсъдим и да научим.

В един читав ОС няма проблем с нещата които "не ти трябват"... Затова обикновено има конфигурация, където избираш каквото ти трябва и само то се компилира и ползва.
Проблемът обикновено е като ти затрябва нещо дето го няма в ОС-а дето си харесал. Е тогава може да ти се такова... мамата. Щото то има библиотеки всякакви, ама само докато ги разгледаш всичките и избереш коя ще ти е подходяща минават дни и седмици. А ако трябва и портване, тогава ела да си говорим пак.



Как се правят нещата ли? Е точно в това е смисъла на ОС-а. Може би наистина е предмет на нова тема, щото вариантите са много. Но като цяло ОС се ползва, когато:
А) Имаш да вършиш повече от едно нещо (демек многозадачност)
Б) Върши се от повече от един калпак (демек екип)

И друг път сме го коментирали при спора bare metal vs OS, че да може без ОС, може без абстрактности, обаче като се сблъскаш с горните две условия и трябва да измислиш нещо. Това нещо може и да не го наричаш ОС, изобщо няма значение как го наричаш, важното е дали то решава тия проблеми или не. Смисълът на един ОС обаче е да дава възможно най-доброто решение. И ако ти си мислиш че имаш по-добро решения на тая тема, дай ми го и аз ще го ползвам! Но повярвай ми едва ли имаш по-добро решение... Старая се следя (доколкото мога) всичко в тая област и да скрабвам най-доброто. И това го правя от много години. А с времето повярвай ми проблемите леко се променят. Щото ти сега си мислиш как било най оптимално с STM, ама утре тия убавци може и да ги няма на пазара (както се купуват/продават и фалират като топъл ляб). И като имаш 20-30 проекта дето трябва да им смениш джелязото или и ти също да фалираш сам ще се убедиш че нещата не са толкоз прости.
Иначе нищо не пречи и да се ползват специфичните възможности на тоя или на оня чеп. Има си начини как да става тая работа. При различните ОС-ве е различно и затова няма да се впускам с примери, но начин има. И да ползва се, въпреки че след това може и да ти създаде проблеми, но общо взето целта е това да остане "target-specific" и ако решиш да сменяш таргета си знаеш къде ще са ядовете евентуално...

Казваш, нещата които не ти трябва се махат с конфигуриране (или добавят, няма значение). Е, аз казвам че за монолитен фирмуер (без динамично линкване, т.е. баш за ембедед) има по-добър, по-бърз и по-ефективен начин за това - и той се казва ... компилатор и линкер, плюс garbage collector-а на линкера...
Т.е. не ползвам SPI в моят проект - кода на SPI драйвера трябва да изчезне от само себе си. Не ползвам мрежа - еми, няма го кода. Защо трябва да конфигурирам нещо и да имат "възможността" да сбъркам нещо и да чакам минути, часове или години докато го разбера?
Това с конфигурирането има смисъл когато compile time не знаеш какво ще ти трябва - т.е. дали някой динамично, в рънтайм, няма да поиска нещо. Класически пример с кърнела на линукса, който се опитва да събере и драйверите там. И тая дивотия device tree, дето е точно обратното на това, което е нужно за ембедед.
Проблемът, който решава "конфигурирането" е по-скоро следене на зависимости - т.е. ако искам SPI а той е ползва нещо друго, то да ми включи и това другото в проекта.
Друга възможна употреба е чрез "конфигуриране" да избереш компонентите, които да се включат, в смисъл изтеглят като сорс от отдалечено хранилище. Само че от това има нужда когато имаш силни зависимости между компонентите - т.е. дадена библиотека (файл, компонент, драйвер) не може да се компилира без нещо друго. По-точно не може да се линкне - и тук идва семплото решение - в platform.c, board.c, main.c или както и да го наречем се очаква ти да Include-неш използваните от теб неща и да направиш инстанциите на обектите, които по-късно ще навържеш (а не да сложиш Modbus и да очакваш той да закачи УАРТ, т.е. конструктура на Modbus обекта да създаде uart обекта - това е грешно и противоречи на инверсията на контрол). Така компилаторът и линкера виждат точно кое се ползва и останалата паплач не влиза в елф-а.
Имаме примерно платформа с iMX6 и правим кърнел за него. Не знам обаче тоя чип на каква платка ще е - дали ще има опроводени SPI, I2C и т.н. И държим кърнела да е общ - което пак е силно безсмислено, за дадената платка ще си има собствен BSP и по-добре да няма изобщо SPI драйвера ако не са изведени тези пинове - само пречи и води до объркване, бавен стартъп и подобни "екстри".
А дори и да е общ, клиента по всяка вероятност ще си направи дистрибуция за дадения продукт, която пак може да включва точно нещата, нужни на тая платка, или всичко.
Имам предвид че това за което говориш прилича на линукс - имаш всичко в един голям проект, а в изхода ти влиза 1% от тоя сорс.
Повечето успешни RTOS-и (дето са успешни в ембедед сферата) са микрокърнели. Ако имаш предвид че е добре същата "фирма" да дава и други продукти като стекове сигурно ще е удобно, но тогава лесно се залитва към техните специфики и кода става оженен за тая фирма.
Много често разните библиотеки или компоненти, както и да го наречем, идват с ОС абстракция. Т.е. свестните библиотеки се стремят да изведат услугите, които ползват от ОС-a или рънтайма така че да могат лесно да се адаптират.
Ако говорим за компоненти от една фирма (ОС, мрежов стек, усб стек и т.н.) тази абстракция липса - т.е. компонентите са правени да работят с техния ОС. На практика се отива в посоката и потребителския код да става много по-директно свързан с тоя ОС и техните библиотеки и после трудно се разделят (ако трябва да се смени към друг ОС). Има и приятни изключения - ChibiOS. От известно време техния HAL е отделен от ОС-a им и може да се ползва с друг ОС.
Моята идея и цел е да търся подход, при който имам минимални зависимости между компонентите. Т.е. не допускам SPI драйвера да include-ва GPIO.h, въпреки че някого може да му се струва удобно да инициализира SPI като един компонент подавайки clock rate и списък с пиновете, които да се ползват - това по моята идеология (не че съм я измислил - тази, с която съм съгласен и следвам) е неправилно структуриране. По същата концепция няма нужда от динамичната памет в класическия и вид, които познаваме. По-точно ползването и е ограничено до силно специфични проблеми.
Реално говорим обаче за различни неща - според теб ОС-а нещо всеобхватно, което ти предоставя почти всичко и за програмиста на приложение остава да опише само точно специфичния проблем, който бори в момента. Това бих го нарекъл по-скоро таргет-специфична дистрибуция, или фреймурк, или BSP, не мога да измисля точната дума. Но това е нещото, което даваш на клиента и той трябва да е максимално улеснен да си напише приложението, без да трябва да пише нищо допълнително. Моето виждане е как да си структурирам моя софтуер (сорса на тази дистрибуция) така че да мога лесно да сменям таргети и да преизползвам максимално кода.
Аз говоря за кърнела и неговото отделяне от останалата част. Реално това което ми стига за ембедед в кърнела е preemtive scheduler и thread-safe FIFO. Никакви мутекси, семафори и подобни! Това е идеята на active objects (actors). Много често ми се налага да пренаписвам и адаптирам обаче външен код, за да се впише в тая система, това е недостатък. Но той идва от нежеланието на авторите да отделят добре изчистена функционална част и после да си я закачат към интеграции всякакви. Т.е. най-ниското ниво от софтуера да са "чисти" функции ("pure functions") без зависимости помежду си, описани като run-to-an-end стил. Този стил също така е далеч от класическото процедурно програмиране и повече програмисти сме увредени от досегашния си опит - затова трудно се обръщаме. Това е пак голям недостатък - клиента няма да се зарадва да му налагаш стил, колкото и предимства да има - и той е прав да се съобразява с ресурсите (програмистите) които има под ръка.

Гичо, не знам спорим ли за нещо и за какво, ама според няма за какво точно да спорим...

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


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


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


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

А що се отнася до конкретиката...

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

Относно дали SPI, UART, I2C и т.н. трябва да имат унифициран интерфейс. ДА, ТАКА ТРЯБВА. Повярвай ми, налага се ежедневно да се заменят. Примерно сложил си дисплей с SPI и си мислиш че ти трябва SPI, обаче като тръгнеш да го оживяваш се оказва че не си доскифал че е 9-бит SPI, а пък си сложил STM32 дето няма 9-бит SPI и кво прайм? Ми закачаме го на UART-a и ако си бил така добър да си направиш унифициран интерфейс то това си става без проблем. Обаче ако си правил изгъзици си е твой проблем. Подобни примери като тоя могат ти изброявам цял ден. Все реални и все от практиката. Просто се НАЛАГА да е ТАКА. В същото време това не означава, че унифицирания интерфейс не може да се поддържа нестандартни конфигурациии на перифериите. Напротив. То по принцип конфигурацията ВИНАГИ трябва да е специфична независимо, че след това интерфейсът ще е унифициран.

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

Относно нуждата от динамичната памет.... Направо ме утрепваш. Сега сигурно ще кажеш че и от Ц++ няма нужда... Щото не виждам как ще ползваш възможностите на Ц++ без темплейт лайбрари, а тя пък без динамична памет (не че е невъзможно) ама е малко като секс без партньор
Просто не бъркай това, което ти имаш нужда в тоя момент с това от което по принцип има нужда. За невероятно голям кръг от задачи е необходима динамична памет. Това че то сега ги нямаш тия задачи на главата си нищо не значи...

Относно "абстрактното" и "конкретното" при ADC и други периферии си има много решения. Мога ти кажа какво аз ползвам. Както казах инициализацията на която и да е периферия при мен винаги е специфична. Т.е. като се отваря хендъл към нещо си, винаги се подава "mode" който е структура с формат, полета и стойности дето само конкретната периферия за конкретния хардуер си знае. С други думи не може да конфигурираш нещо с "абстрактни" настройки.
Това не значи че не може да пишеш абстрактен код. Примерно ако пишеш някакъв стек, както споменах по-горе дисплеи. Просто стекът си получава някакъв мод, който за него е просто "void*" получава си индекс на драйвер. След това си отваря хендъл към въпросния драйвер и с въпросния мод. Самият стек не се интересува дали драйвера е SPI, UART или нещо друго. Не се интересува какъв е мода/режима. Но това не означава че те самите не са конкретни някакви...
По същия начин и с ADC-тата - всеки конкретен хардуер си имат мод структура с всички възможни настройки на ADC-то или на ADC канала или каналите, щото при мен едновременно могат да се ползват няколко канала. Няма нужда от никакви IOCTL (не че ако имаш нужда щеше да е проблем). В настройките има всичко, а те още веднъж са си съвсем специфични. Останалото е "кога" ще имаш данните. Ами според това как си конфигурирал АЦП-то, тогаваш ще имаш и ще имаш каквото си конфигурирал да мери. Самото получаване си е унифицирано, просто едни данни идват (евентуално). По същия начин както от UART/SPI/USB и т.н. могат да дойдат някакви данни евентуално някога си... Демек няма никакъв проблем работата с драйверите да е унифицирана. Както и те да си работят със съвсем специфични настройки, даже напротив - пак ще се повторя, те винаги работят със специфични настройки, а не само като имат pGA или нямат PGA...

edit: още на тема конфигуриране на периферия/драйвери. Всяка периферия си има набор от регистри. За да я конфигурираш по един или друг начин съответно трябва да запишеш едни или други стойности в определени регистри. Е те затова най-логичното е конфигурацията (мода) да е структура сходна на конфигурациониите регистри. Така драйвера просто шляпа каквото са му дали. Ех понякога има особености за реда на писане по регистрите в зависимост от стойностите, но затова тоя дето пише драйвера чете чаршафите и се чеши по главата достатъчно дълго време. Въпросът беше, че в общия случай няма проблеми един що-годе универсален драйвер да се ползва след това с най-различни конфигурации. А пък различни драйвери да се ползват от що-годе универсални стекове. Демек няма проблем да има абстрактни неща, няма проблем да има специфични неща. Има и полза и нужда обаче много неща да се правят унифицирани!

Да пусна едно ниско-приоритетно IRQ
Миро, казваш че драйверите ти в твоя ОС са унифицирани до отваряне с конфигуриране и получаване на данни. Също така казваш че конфигурацията е специфична за дадения контролер. Tова което не ми стана ясно е какво праивш при евентуална смяна на контролера с такъв от друг производител? Обикаляш си целия проект и променяш mode структурите да отговарят за новия контролер ли?

Ми въпрос на организация
Не ми се налага да обикалям много, тъй като в моята организация таргет-зависимите неща са изведени в отделна директория само за тая цел...

Като цяло обикновено проектите ми обикновено са на 3 нива. На първо ниво е ОС (и стекове), който си го компилирам до библиотека. В ОС-а си имам директория boards, където са настройките за тая или оная платка и/или проект. Настройките обикновено се свеждат до 2 файла (за мейк и за сорсовете) дето с Y/N или нещо подобно казвам какво се ползва.
На 2-ро ниво са ни private библиотечки/стекове, пак така с директория... и се компилират до библиотечки.
И на 3-то ниво е проекта, пак с директория (tagets) щото един и същ проект може да има вариации, най-малкото за дебъг/релийз. Като за всеки таргет си има един файл с който избирам и конфигурирам драйверите. Щото те самите също могат да си имат настройки. Сравнително просто е понеже драйвери и стекове не се пуска с код, а просто се задава със структури. 1 драйвер = 1 структура. Попълваш я и го има, не я попълваш - няма го. А да, всъщност има и още нещо, тъй като при мен прекъсване означава драйвер, вектор таблицата ми е просто таблицата с драйветите, така че има и още една структира - вектор таблицата или драйвер таблицата....
Отделно пак в тая таргет директория слагам и определени модове дето се ползват в проекта. Умишлено са изнесени в тая директория, така че останалата част, т.е. другите директории да нямам таргет зависими неща. По-точно да не са много, щото все пак се налага.... примерно "ако има еди какво си, тогава ще имам такова меню примерно"... Но това обикновено е с #ifdef и то за неща които са по-скоро свързани с изделието, а не толкова хардуера.
За някои от стековете също се налага таргет инициализация... обикновено по един setup файл. Примерно usb_setup.cpp ... и ако той е таргет зависим ествено е в таргет директорията

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

http://www.nvidia.com/object/drive-px.html

5 терафлопса на чип... Баси технологиите правят тия

Банане, не ти прави чест.

Сигурно е минала година от събитието в Майкрочип- но едва вчера го срещнах.
Поръчаха ми да купувам 8кракови PCT25vf032 .
Запомнил съм , че тая марка я купиха SST, тях пък Майкрочип. Накрая - греда , SST 032 и 064 - спрени от производство И изтеглени от пазара . И някаква миграция към серия 26. Да ,ама устройството едва ли е чувало за 26 серия. Хубаво , ще го мисля. Обаче - вчера си писах драйвер за sst25vf016. Te и по-малките не са спрени(още), ама ме обхванаха едни съмнения....Ако са открили грешка в чипа - да го напишат. Ама такова нещо не намирам и това ме кара да се замисля и да бягам от Майкрочип. Което пак е тъпо от друга гледна точка.

SST продукти бяха убити при поглъщането от MCHP. Сякаш предимно патентите им трябваха.

NRAM, mass production planned 2018
http://electronicdesign.com/embedded/me ... ive-weapon
http://nantero.com/

Бреййй, да видим

Хайде на десетките Гигахерци!
For First Time Ever, Carbon Nanotube Transistors Have Outperformed Silicon
For the first time, scientists have built a transistor out of carbon nanotubes that can run almost twice as fast as its silicon counterparts.



http://futurism.com/for-first-time-ever-carbon-nanotube-transistors-have-outperformed-silicon/

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