Е няма смисъл от повече детайлизиране, сценарият ми е хипотетичен. Внимавах да е
възможен и реален но не е базиран на нещо конкретно.

Целта на примера е да покаже, че обработката на външни събития "от събитие до край
на обработката му" (доколкото разбрах ти натам биеш) не е практична в голяма
част от случаите.

Допълнително изменяйки малко горния пример - примерно закъсненията до писането
в DAC-овете да зависят от входния поток данни дето идва през FIFO-тата или как
да е инак, да кажем от ADC-та - може да се покаже, че външните събития мога да
бъдат източник и на последващи във времето, зависими в още една посока
"вътрешни" събития.

Да, това имам предвид - run-to-an-end. А относно непрактичността - струва ми се че в такъв сценарии не е едно събитие, а са две, следващи едно след друго. И изпълнявани с различни приоритети, първото свършва и дава сигнал за събуждане на другото. Според приоритета второто тръгва веднага или след време. А приоритета се сменя според изискванията към конкретния проект, и сменяйки само него се постига желания резултат.
Ако в твоя пример искаш да повториш сигнала от АЦП-то върху ЦАП-a, синхронно, без обработка или закъснение, ще сложиш копирането от АЦП в ЦАП в първото събитие с висок приоритет - примерно АЦП прекъсването. Но примерно за някакъв вид автоматично регулиране на усилването ти трябва и филтриран сигнал. В прекъсването можеш да натрупаш история от 8 резултата примерно (във ФИФО) и на всяко 8-мо прекъсване събуждаш ниско приоритетен AGC таск да ги отфилтрира и да ги прати някъде.

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

Е значи правилно съм те разбрал. Не е практично това, което предлагаш, трябват 5 милисекунди
за цялата обработка на първото събитие и още 5 за второто, а междинни резултати трябва да
почнат да излизат на първата милисекундаи за двете. Съвсем реален сценарий, повечето неща
са така всъщност (примерно имаш два потока от две ADC-та, с DAC-овете базирано на някакво
филтриране 1 милисекунда назад коригират някакви аналогови нива за да върви входът нормално,
а резултата който търсиш се получава от всички семпъли от 5 милисекунди - и двата процеса
изяждат 90+% от ресурса на процесора).

Гичо, първо викаш - "дай да не говорим общи приказки". Като започна да говоря с конкретни примери явно пък на това му викаш: "развиване на сценарии".

Единственото което целях е да ти покажа че за мен няма антагонизъм между event driven и time driven. Щото ги комбинирам и двете. Но има антагонизъм между оптимизация и организация. Аз съм се отказал да удовлетворя и двете едновременно. Щото двете са обикновено в конфликт и в най-добрия случай се получава - оптимазация.
Там където трябва ниска латентност - повярвай ми не само че имам прекъсване вързано към подходяща периферия(вътрешна или външна) ами и съм взел всички мерки да намаля до възможния минимум латентността при обработка на прекъсване(приоритети, вложени прекъсвания, банкирани или резервирани регистри, писане на асемблер и прочие). А полирането на фриирън таймера го оставям на задачки които не са толкова капризни че да искат да ги извиква прекъсване по timer match и не им пука дали таймера е нейтив 32 бита и колко такта на периферната шина са необходими за прочитането му.

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

А и не е винаги, както споменах по-горе (timebase, decrementer - все регистри от ядрото на power).

Здрав, не ти схващам разделението - ако говорим за не-прецизно време, това се осигурява лесно и е производна на прецизното. Защо ти трябва 32-битов таймер?
И да разбирам ли че тези "не толкова капризни" задачи наистина ги пускаш в while(1) да четат таймера докато им дойде времето ??? Сигурно със слийп вътре?
А таймерите са външни за ядрото, мисля че няма какво да спорим за това.

Тги, да де, значи имаш някакво едномилисекундното дето е по-високоприоритетно от дългите 5мс. Високоприоритетното ъпдейтва DAC-а докато 5мс си върви.
Реално към DAC-а данните от фифото, или данните от 5мс обработка, трябва да излизат? Ако ти трябват някакви данни от 5-те мс, значи трябва някак да гарантираш че за първото едномилисекундно ще има данни още на първата милисекунда (т.е. че 10% от работата в бавното 5мс е свършена, да кажем средното на семпъл 0 и семпъл 1). Иначе вадиш грешни/стари данни.

Относно тоя декремент при power - достъпът до него би трябвало да е възможен само от някакъв привилегирован режим, иначе таск-а може да си го омаже? Отделно, кога го презареждаш - предполагам при викане на функция на OS-а за rescheduling?
Този декремент кога брои - ако ядрото заспи (wait for interrupt), какво се случва?

Добре, "няма" да спорим


Не съм се замислял. Може би съотношението прецизност, време за препълване. Или може би защото не рядко MCU-тата които ползвам са 32 битови.


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

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

5-те милисекунди са примерно 50 килосампъла, междинните резултати са резулта
на филтрирането на 1/5-а от тях всеки, а общият резултат е от филтрирането на всичките
50 килосампъла. Няма как да ти стигне времето за всичко освен ако не го разделяш
подходящо. Т.е. не можеш да си позволиш да вземаш решение какво да правиш
базирано на едното събитие и да караш до края, всичко останало отива на кино
ако опиташ така.
Въобще операционните системи и понятията като "таск", "приоритет" и т.н. са
се появили преди толкова години и са просъществували и досега "for a reason" .




Той е достъпен само в супервайзорен режим, да. Но timebase регистрите (с няколко наносекунди
разделителна способност) си се четат и в user mode. Специално в dps-a декрементъра го пише
шедюлърът, малко преди да пусне избрания таск да пасе. Използвам го (рядко, не съм сигурен дали
въобще това се случва в работещ анализатор примерно - но и не мога да помня, то са
десетки М сорс) и за да предизвикам rescheduling от IRQ handler. Това последното е по-трудно
отколкото звучи, защото би предполагало всяко прекъсване, което ще предизвиква rescheduling
да знае как и къде да ходи за целта, да мисли и за демаскиране и т.н. А това, което аз правя,
е прекъсването да си каже (оставя хабер един бит някъде) кой таск иска да бъде пуснат, след това
слага декрементъра на 0 (или на 1, не помня) и си се връща (ползвайки само IRQ стека, не системния
и не user-ския, без дори да се интересува кой таск върви в момента). Декрементърът прави своето прекъсване
няколко цъканки по-късно и вкарва системата в rescheduling, той друго и не прави.

[edit] Забравих да ти отговоря за декрементъра и спането. Както аз най-често го ползвам,
той не спира. Ядрото влиза в "nap" режим, престава да снупи бъса, а бе почти всичко му
спира освен таймбазата и тоя декрементър. На прекъсване би реагирало, от декрементъра
или външно. Ако ядрото иде в deep sleep режим или нещо подобно, когато и клоците
спират, естествено всичко спира - но аз не го ползвам така дотук. А и печалбата откъм
консумация е почти никаква - повечето печене и в nap, и в sleep иде от leakage [/edit]

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

С риск да стана досаден... има термин "real time system", който означава че това е система, в която правилният резултат зависи не само от логика, ами и от времето.
Простичко казано за провал (отказ на системата) се счита не само грешен резултат, ами и закъснелия. Примерно компютърът който управлява ABS на кола може да работи логически правилно, но ако е със закъснение... имаш провал!

Задачите в една такава система си имат dead line. Или се изпълняват в зададеното им време или имаш провал. Времето винаги е реално, няма никакво значение как ти вътрешно го мериш и дали изобщо го мериш. Ако искаш ползвай прекъсвания, ако искаш полирания, това си е твой проблем. Важното е ABS-а на колата ти да реагира навреме, т.е. така както е по задание.
Единственото нещо, което има значение за теорията е как ще си рапределиш задачите в рамките на броя процесори с които разполагаш. Ето с това се занимават операционните системи. Ако имаш 5 задачи дали ще се изпълняват 1-2-3-4-5 или в някакъв друг порядък. Редът, се определя от използвания алгоритъм за scheduling. Има различни алгоритми, като разликите са дали се набляга на простота, дали се набляга на надеждност или се набляга на гарантирано време. За съжаление няма алгоритъм, който да постига всичко на куп. Винаги е компромис. При RTOS обикновено се набляга на предсказуемост на времената. Това означава, че ако имаш задача с по-висок приоритет от останалите, тя ще получава винаги процесора, съответно нейното време е ясно. Като знаеш нейната честота и продължителност, може да сметнеш какво ще остане за следващите и така до най-ниския приоритет. Проблемът при тия сметки е, че не отчитат бъгове, примерно ако има ограничен ресурс в системата, който може да се използва само от една задача в даден момент - може високоприоритетен таск да блокира в чакане на ресурса и ако не пусне процесора ще чака во веки веков.
Затова в десктоп системите се ползват техники като random boost, които дават шанс и на нископриоритетните нишки да кретат, дори ако някой отгоре е бъгясал. В резултат системата е малко по-надеждна от към софтуерни бъгове.
Та така, не винаги предсказуемото е надеждно, а надеждното е предсказуемо.... Но няма "правилен" или грешен подход. Ако си мислиш, че си идеалният програмист и никога не правиш грешки - ползвай най-върлите hard realtime OS техники. Ако ще участват индийци, може би не е зле пък да се застраховаш

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

Миро, съгласен съм с повечето неща. Само няколко дребни коментара:
- ето един признак, по който ТИ различаваш десктоп системите от, предполагам, ембеддед/real time такива А на мен ми твърдиш че няма разлика...
Относно предсказуемото си в грешка - стандартите за надеждност имат няколко критерия в тази насока:
- степен на сложност на кода (брой редове, ниво на вложени условни конструкции, ...)
- ниво по покритие на кода от тестове
Ако една система не е предсказуема, за мен тя няма място въобще в класациите за надеждност. Т.е. ако не е мислело върху нея от тази гледна точка.
Конкретно (бях говорил вече) за разпределянето на приоритетите и липсата на priority inheritance в повечето ембеддед rtos. Какви може да са причините (според мен):
- системите трябва да са разработени (моделирани), анализирани, тествани, ... с целта да няма възможност до достигане на такива deadlock-ове и инверсии на приоритети, и това е възможно ако се моделира правилно и достатъчно детайлно системата. Защото priority inheritance, които е спасителния механизъм в десктоп, не върши работа в ембеддед-а (почти гарантирано води до нарушаване на real time границите); стигането до такава ситуация в реални ембеддед система би трябвало да значи само едно - девелоперите обратно на тръстиката докато не решат проблема чрез редизайн и последващ ъпдейт; т.е. това е индикация за грешка, водеща до деклариране на дефект в системата; не е сериозно такава система да остава да работи (е, ако е светодиодна реклама може и да и го преживее клиента). Ама в твоя случай с АБС-a не е така.
Виж примерно AUTOSAR и по-старите OSEK стандарти. Динамичността там е забранена, дори времево отделните процеси трябва предварително да са описан и със точни времена за изпълнение. Това пък ако има аналог в десктоп машините... Това е начина АБС-а да работи (надеждно). Не 40 таска, които реално представят 4-5 паралелни процеса, ама са пръсната в отделни таск-ове за да му е удобно на индиеца. И вътре има още 40 семаформа, мейлбокса или тем подобни за закърпване.

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

Тук говорим за реални ситуации и подход за постигане на познание за процесите в системата и техните причинители. Целта на това изследване / моделиране е да се достигне разбиране на системата. Оттам насетне дали с ОС, дали без ОС, който както иска да го прави. Кооперативно (бавна реакция), прекъсвания и superloop, таймслот, софтуерни прекъсвания, ... все реализуеми концепции, но със своите ограничения (и изисквания към хардуер).
ОС-а е нищо повече от съвкупност от няколко общо познати техники за шедулър, синхронизация на процеси, за времеви услуги и т.н.

Как може да се гарантира че дадена система постига зададените real time параметри? Може би с хамалско тестване - я си представи ако имаш 2 цифрови входа и един изход, разглеждайки ги в оста на времето, колко възможни тест кейс-а могат да се дефинират? А при реална система? Можеш да пробваш, но не е продуктивен подход.
Алтернативата, която имаш ако познаваш процесите, е да изведеш тези времена. Това извеждане е толкова по-лесно, колкото по-добре си моделирал и колкото по-точно си намерил реалните събития и вътрешни състояния на системата.
Ако в десктопа е допустимо да има неясноти и странно поведение, то в ембеддед не е.

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

Преди бях попитал какво е предимството на този "device independant i/o" модел. Все още се питам същото. Имам някои идеи и се чудя дали има и друго:
- на ниво прехвърляне между kernel mode и user mode изпълнение, и на ниво интерфейс между процеси в различно мемори пространство (т.е. където директен call е неприложим например), използването на лимитиран набор от няколко възможни функции с фиксирани параметри ще е улеснение (за който разработва този интерфейс, едва ли за тези които го ползват). Честно казано, не знам как точно се прави това - и затова не знам дали реализирането на свободен интерфейс там ще е проблем?
Хм, друго май не се сещам в момента?

Ако направим аналогия с OSI модела, даденото ниво в софтуера познава (длъжно е) интерфейса към съседното ниво. Ако ще работя с TCP/IP стек не искам file i/o API. Искам socket. Ама на същото ниво, ако искам UDP трябва да знам спецификите му и sendto()/recvfrom(). Сигурно може и да се уеднаквят апи-тата, но по наблюдения в такива случаи се появяват безброй "setsocketopt", "ioctl" и подобни механизми. Не знам дали това е по-удобно за потребителя. Дали си документирал бит за опция, или контрол код, или си сложил отделни функции, и двете искат документация. Ако функцията е по-бърза (ако е специална за дадената опция имам предвид).
Ако работя с SPI, не искам да знам какво прави конкретния SPI контролер. Общото между всичките SPI контролери е ... SPI стандарта. Т.е. интерфейса към SPI драйвера трябва логически да следва идеологията на стандарта. Това не може да стане през "device independent I/O".

Това като драйверна подсистема ми изглежда по-добро?

Аз твърдя, че теорията е една и съща. Разликите са в имплементациите, както и различни практически и исторически причини. Примерно това за динамичната памет, ами на чисто Ц и аз много внимавам, защото хич не е трудно да се допусне гаф. Но отдавна има решение на тоя проблем, вика му се Ц++ и от както го ползвам съм забравил какво значи memory leak.
Между другото това с динамичната памет е типичен пример за грешно решение. В смисъл няма и никога не е имало теоретичен проблем. Напротив, имаш съвсем очевАден проблем, когато не ползваш динамична памет.
Същото е и с решението, че проца дето прави ABS не бива да прави нищо друго. Глупости на търкалета. И други и други такива примери, когато някой голям "практик" почне да дава акъл за теории. Все едно говорим за законотворчеството на нашите дупедавци и връзката им с правото....

Принципно, всичко това са примери с ограничен ресурс - дали ще е процесорно време, ограничена памет или дали ще са други ресурси, те са си ограничени по дефиниция. Няма как да заобиколиш теоретични проблеми с практически трикове. Не става.
Проблемът с динамичната памет е практически - как да се ползва, а не дали да се ползва. Същото е с изпростяването на ABS, убаво - ще го опростиш, няма да прави нищо друго. И така още 100 детайла в автомобила и накрая ще се опетлаеш в мрежа от 100+ компютрчета. Гарантирано се получава по-зле, защото ти на практика не можеш да направиш надеждна мрежа, а пък теорията казва, че няма и НЕ МОЖЕ да има надеждна синхронизация по ненадежден канал. А автомобилът е един и по задание се налага отделните му части да работят поне в някакъв синхрон. И работата стана от трън на глог, че по-висок...

Операционните системи НЕ са решение, те са инструмент...

Писали сме заедно ...
Къде съм говорил за динамична памет? Говорех за динамични задачи, и създаването на таскове runtime.
А паметта - според зависи. Стандартната имплементация на хиипа си е враг на real time. Има техники за заобикаляне, но никоя не е достатъчно добра.
Но дори за real time linux-a авторите препоръчват заделянията да стават само по време на инициализация.
Дали може на един процесор да върви всичко ... сигурно може. Е, когато се гони надеждност се прави обратното - едно и също да върви на 2 процесора. А и като гледам текущите решения, нещо не виждам някой да се е престрашил да сложи абс-а като таск в еку-то на мотора. И разчитат на определените от теб като "ненадеждни" канали да си комуникират.
Някъде ми беше попаднал (май беше блог на някакъв мениджър в тая област на freescale) че досегашните системи (абс, есп) се правят на 2 отделни процесора, с принципно различни архитектури, и се пише кода независимо един от друг. Те (freescale) са работили много време за да го докарат до това да е в един чип, ама май пак беше 2 ядра, с общ код. Но за да постигнат надеждност са сменили целият си развоен процес, като са тръгнали на моделиране (UML) на системите. Просто по този начин на работа се доказва че кода е по-чист от бъгове, отколкото при писане на кило и тестване на мегатон.
То там цялата хватка е да достигнеш достатъчно нисък коефициент на отказите. Прави го както искаш. Като искаш сложи 3 еднакви процесора с еднакъв код - тогава смятат че вероятността за грешка от неправилно изпълнение на кода спада до незначителни нива. Но ще трябва да докажеш че алгоритъма и (единствената му )реализацията са достатъчно сигурни. А това не е лесно. Ако имаш различни алгоритми в два процесора, пък било то и еднакви ядра, печелиш точки. Ако пък са различни ядра, още по-добре.
Ако имаш гащи, ще се явиш пред одита с платка с един процесор и един код (едно решение, един алгоритъм). Който върти и АБС, и контрола на двигателя, и радиото, и климатроника. Само че докато го напишеш да им покриеш нивата за вероятност от отказ закона на Мур ще е ударил 10 с 20 нули отзад, C-то ще има вече 14 плюса след себе си и т.н.

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

Едит: за C++ - съгласен съм напълно че е по-добрият избор. С вметката че той е една стъпка над C-то, а над него (над C++) има още по-високи нива. Оценявайки предимствата на ++-а, трябва дедуктивно да предположим че в бъдеще ще има още по-високо ниво. То това бъдеще някъде е дошло. Някой ползват UML, SysML, други си пишат код генератори.
А това моделиране изхожда отвън навътре и се опитва да идентифицира малките обекти и run-to-an-end процеси в тези обекти. И откривайки ги позволява да се види системата по друг начин, без прекалено усложняване и излишъци. И пак то ни показва че последователността от действия винаги започва от входна точка по формата на пин, интерфейс или нещо подобно.

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

Е, предполагам се сещаш че нивото на отказите там си е в порядъци по-ниско от нашите кодове. Сблъсквал ли си се с реалния процес в аутомотив/сейфти индустриал? Щото аз съм, че има мижи да те лажем, и там има. Ама е доста трудно да минеш между капките. То нямат и финансова изгода - сбрали се tier 1 производителите и си направили стандарт за парлама, да им е гадно. Те и MISRA-ата са си я измислили, а тя си е много реално полезна.

Колкото до десктоп vs ембеддед - аз говоря за потребителските програми, не за кърнел. Там определено има доста зле написан софтуер. Е, и в ембеддед, да. Поне на нашето ниво. Иначе има доста качествени кодове (и стекове, и ОС-ове) ако имаш пари за трошене.

Ако ти е интересно, разгледай "драйверната подсистема " на АУТОСАР. По диагоналната система аз "independent i/o" не видях. Ето едно репозитори view за справка:
http://www.arccore.com/hg/arc/file/76ca74884a50

не разбрах какво да им гледам? ако имат нещо интересно подсказвай....

Просто напоследък се нароиха много, не мога да ги следя всичките, даже никой не ми се следи