Гичо, на чист български ти казвам, че Чибито НЯМА драйверна система. Още малко ще почнеш да ме убеждаваш как се казва майка ми... Няма как да споря за такива глупости! Казах ти, това което имат е HAL а и те самите на сайта си казват "HAL component supporting a variety of abstract device drivers".

Миро, чест и почитания! Но, докато не изясниш веднъж за винаги твоята терминология относно ОС-ите и компонентите и, не можеш да очакваш, да бъдеш разбран. До тук за мен gicho е прав относно ембедед ОС-а и драйверната система конкретно в чибито - "HAL component supporting a variety of abstract device drivers" - има "драйвери"!

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

Значи "драйвер" е много общо понятие. За него нямам претенции и всеки може да си го ползва както намери за добре. По подобен начин е и понятието "задача". Примерно имаш една задача, която като получи байт по серийния го връща, демек прави ехо. По всички правила на наУката тва си е задача. По подобен начин може да имаш още няколко глупави задачи в едно задание. По дефиниция тва му се вика многозадачна система и няма никакво значение как точно ще я имплементираш. Тя си е многозадачна...
Може примерно в main() да ги викаш циклично... на тва му се вика кооперативност. Може да ги наблъскаш в различни хардуерни прекъсвания и ще получиш нещо като приемптив. Забележи, че дотук НЯМА никакъв ОС. Демек тва че имаш задачи и многозадачност не ти дава правото да твърдиш, че имаш ОС. Ако някой го твърди, значи е или некадърник или се опитва да ти продаде зелен хайвер... защото осът предполага наличие на кърнел и т.н.

Абсолютно по същия начин е с драйверите. Нещо което се грижи за някаква периферия може да го наречеш драйвер - няма проблем. В случая Чибито има и HAL, демек покрива напълно критериите за драйвери, щото без унификация на клиентския интерфейс по-коректно щеше да го кръстят библиотечка...
Но липсва драйверната система, демек онова звено дето е аналог на кърнела, който дава ново качество на задачите и те вече се наричат нишки. При драйверите също се променят качествено нещата, макар че името им си остава просто драйвери...
Сега какво прави това звено (драйверната система) много зависи от системат. При бозата е едно, лайнукса друго, при ecos трето и т.н. То ако погледнеш и разликите в кърнелите са огромни
Няма как да направя обобщение на всички, още повече че и не ги познавам всички достатъчно. В общия случай драйверната система се грижи за инсталирането, за конфигурирането. Примерно има един UART драйвер и без да се бара по сорсове, само чрез конфигурация се слагат 2-3 или повече инстанции. Обикновено всички драйвери имат много прост интерфейс на ниско ниво, за да може да се каскадират или заменят. Примерно GUI си работи с някакъв драйвер, ама не се интересува къф точно. Ако щеш закачай дисплей на I2C, ако щеш на SPI ако щеш директно на процесорната шина. Въпрос на конфигурация, а не бърникане по сорсове...
Може би най-важната характеристика на драйверната система е връзката с клиентите. Простичко казано ако HAL ти дава някаква абстракция за определен клас периферии, то драйверната система е абстракцията за работа с периферии изобщо. Примерно ако една нишка трябва да слухти по някакъв сериен и в същото време да
следи за натиснат клавиш, откачане на кабел или просто таймоут, то това е работа на драйверната система. Не че не може да се направи и без нея. Но с далеч по-големи компромиси, защото съвременните контролери често са с ДМА-та и ако нямаш нейтив заложено в драйвер интерфейса понятия за заявка и понятие за канселиране на заявка става боза. Не става отвън да човъркаш...
Абе хората са го измислили... вика му се драйверна система. В нея е общия код за синхронизация, така че един клиент да бачка с колкото си иска драйвери едновременно, или много клиенти да бачкат с един драйвер без да стават инфекции. Няма нужда нито клиентите да се притесняват, нито пък драйверите. Последните просто трябва да спазват някакъв както казах доволно прост интерфейс. Това също е отличителна черта, защото без драйверна система може да си направиш някакъв нов коренно различен драйвер. Докато със система трябва да спазваш протокола, иначе - боза! Ама то така е и при хората, ако искаш да си сред хора трябва да спазваш някакво приличие, иначе като мен си стой на село и си дивей на воля

И аз се радвам, макар след проветряване на мозъка за два дена извън града седя и се чудя какво ми е щукнало да се включа в дискусията.
gicho, що за въпрос е това: "дефинирай вътрешен тик"...
След като програмата ти се изпълнява на някакъв твой клок и ако твоето устройство се вързва и към външни обекти/устройства, които имат собствен клок или пък собствени периоди на събития. Мисля че това автоматично дефинира "вътрешен тик" и защо е вътрешен.
Като прибавим и ходещите задклавиатурни устройства, които си имат собствени "клок домейни" мисля че е ясно какво имам предвид.
Някакъв частен случай е когато твоето устройство живее някакъв собствен егоцентрично-аутистичен живот. Цъка по една задачка и си писука като R2D2 и толкова.
Всъщност знам, че това ти е напълно ясно. Както и че темата е конкретно за ChibiOS.
Сори за спама.

ROFL, то кой ли от нас не се е сблъсквал с аутизъм от страна на силиция, добро е

Zdrav, остави общите приказки - за какво се ползва този така наречен вътрешен тик, и какво ще стане ако примерно спра таймера, който клати тик-а? Какво ще се случи? В една нормална система - нищо няма да се промени. Изключвам случаите когато се ползва sleep() за да се "даде въздух" на по-нископриоритетните таскове - за тази работа си има синхронизиращи механизми на ОС-а и евент-и, нормалното е таск-а да спре в чакане на евент; другото е , както казах, изкуствено ограничаване до кооперативен мултитаскинг, водещ след себе си всички недостатъци на кооперативния, само че пуснат върху система (ОС) който поддържа и преемтив. И това направено поради лош дизайн на системата (лошо моделиране, неуспех да се открият отделните модули и събитията между тях).
Искам пак да кажа, че тик-а е само и единствено за таймаут механизъм, т.е. е необходим само за реализация на таймерни услуги. Няма общо с кърнела, по-точно общото е че кърнел-а също е клиент на тази услуга. Трябва ти за реализация на софтуерни таймери, и то защото в общия случай нямаш достатъчно хардуерни такива.
Началните моменти на тези таймаут-и (или закъснения, няма значение) винаги е външен хардуерен евент (т.е. прекъсване), или евентуално изтичане на друг таймаут. Ако проследиш веригата до началото, ще видиш че това "Начало" е периферен евент.
Ако го няма това Начало (т.е. периферния евент) няма да се случи нищо смислено. Ако имаш предвид че ти трябва за полинг, то това е заобикалка за да се открие периферен евент, за който няма прекъсване. Следиш бит, който се вдига от друг таск - вместо да спреш докато не бъдеш сигнализиран че другия таск е сет-нал евента и имаш работа за вършене.
Ако системата е тотално евент-базирана, то тя никъде не прави полинг, всичко тръгва, свършва си работата и спира, чакайки нова заявка за работа. И в тази система имаш времеви събития - таймаут-и, но всяко едно от тях може да се опише като стартов периферен евент + време (таймаут). И се ползват основно за откриване на грешки, т.е. в коректно работеща система не се случват (не изтичат таймаут-ите).

Ще започна отзад напред - в коректно работеща система не изтичат таймаутите, но в една реална система, когато връзката между мастър-а и слейва се скапе за да не увисне единия от тях като сопол се случва да му изтече таймаут-а.
А embedded устройствата не работят в академична среда и подобни ситуации трябва да са предвидени по проект, не само за дебъг.
Аз съм заклет писач на event базирани системи. И съм си имал разправии за това с шефа, който настояваше винаги да ползвам полиране. И не знам защо тук в дискусията все ми се струва че ме поставяш в противниковия лагер.
Но и мойта дебела глава отдавна е увряла, че има случаи в които полирането е неизбежно. Неизбежни са и таймаутите и то не само използвани като защита от увисване. Всъщност таймаута също може да бъде начало и това е основното в моите представи, че достигането на момент във времето също е събитие. И тъй като го измерваме по вътрешен клок, за мен това е вътрешно събитие. И ако се замислиш, както мен ме караш да проследявам връзката чак до корена. При асинхронна комуникация точно събитията по време бележат границите на битфреймовете. И това са си чисто вътрешни събития, може и на прекъсване да ги закачиш, може и да ги полираш все едно. Разбира се говоря за асинхронна комуникация с bit bang, без използване на някакава периферия(UART модул например).

Не знам защо намеси на едно място кърнела и това че таймера не бил част от него... То и светофара не придвижва колите по кръстовището, двигателя е който движи всяка кола. Но без светофар при интензивен трафик стават задръствания.
И пак ще повторя на 75% споделям твоите разсъждения и за event-те и за това че те могат да служат като такт за цялата система. Да не се окаже че говорим дори за едно и също. Но ми се струва че малко се оплиташ.

Дали? Тоя момент от времето реално се намира къде - на еди колко си мкс/мс/с от ... прекъсване. Така че пак е същото.
Колкото до полинг-а предполагам ще се съгласиш:
- че се налага ако нямаш или не можеш да използваш събитие, базирано на хардуерен евент (прекъсване, прекъсване+закъснение след него през таймаут, ...)
- полинг-а е най-бърз когато върви без таймер ... (пояснявам - има си ниско приоритетни / айдъл таск-ове, ако нямаш евенти и искаш полинг, слагаш го там - за да имаш максимално бърза реакция, лимитирана единствено от текущото натоварване на системата в по-високоприоритетните таскове).
Ако държиш да го правиш "не по-често от ..." за да пестиш ток примерно, ок, ползвай го през времево събитие. Само че в примера ти със софтуерния UART, аз се сещам за няколко варианта:
1. ако имаш чист, не-сихнронизиран с входа полинг, трябва да тичат на няколко пъти по-висока честота от бит рейта - 3х е минималното за сигурна работа, и трябва да правиш арбитриране на семпълите, т.е. имаш много по-високо натоварване;
2. имат прекъсване по фронт за първия преход (началото на старт бита) и после БАЗИРАНО на него започват таймаути за битове
3. имаш само прекъсвания по capture или по фронтове (преден и заден) и гледаш timestamp-ите на преходите - това е евент базиран софтуерен UART; има най-ниско средно натоварване за системата, но същия worst case като номер 2.
Сега, има вариант да нямаш нито capture, нито прекъсване по фронт - тогава си на варианта 3х (1.), няма начин. Но това е ултра рядка изгъзица и значи че си инвестирал в чип с много CPU мощ ама с калпава (неподходяща за целта) периферия. Имам предвид че този вариант е изключение, и иска изключителни мерки. Може би и той може да се оптимизира до първоначален полинг на 3х скорост, и после отделни таймаути за семпъл точките на битовете.
В другите два метода (2. и 3.) спират полинга след приемането на последния (стоп) бита и пак изчезват от пейзажа до следващо прекъсване.
Предаването не е много по-различно - и там битовете са дефинирани като последователност от 8-9-10 таймаута, но първия евент не е времеви, а е в последствие от хардуерен такъв (UART приемане на запитващата команда, на която пращаме сега отговор, прекъсване от бутон за което искаме да печатаме по серийния, изобщо завършен някакъв процес в системата, който е тръгнал от външен евент).

Гичо, а бе то всичко на тоя свят е някъде на 14 милиарда години от началото на вселената ни .

Настъпването на даден момент във времето е събитие и още как - примерно курдисана аларма
(да не се обади само някоя дето Той я е курдисвал преди 14-те милиарда години да угаси
захранването ) .

Не че не си прав, че всяко събитие е следствие от друго такова - но пък и всичко се случва
във времето, поне доколкото нас ни касае това.

Представи си следния сценарий: две едновременни събития, за пълната обработка на всяко
трябват по 10 mS но и всяко трябва да се обади навън всяка една от тия десет милисекунди.

Как ще го реализираш?

Ами в почти всичките многозадачни неща които съм правил при стартиране пускам един 32 битов freerun таймер. После всяка задача на която и трябва текущо време си взима от него таймщампа и примерно следи за изтичането на таймаут преди да свърши нещо. В този пример както казва tgi, единственото външно събитие от което се измерват всички други е включването на захранването на системата(или някакъв друг вид RESET) и тръгването на таймера.


Не веднъж срещана ситуация. В напреднал стадий от разработката ми донасят един външен remote control за системата която правя. Клавиатурка и едноредов дисплей вързани по кабел към UART. Вътре един PIC16 и малко код на асемблер. Само че се оказва че сега процесора с цялата му мощ освен че тича да събира данни от няколко АЦП-та, с последващ постпроцесинг, поддържа комуникация по USB, драска по един сериен FLASH И няколко други дребни задачки - сега се оказва че трябва да чака клавиатурката да се натутка докато получи данните. На всичкото отгоре кабела на клавиатурката е вързан на куплунг и задклавиатурното устройство може да се спъне в него когато си поиска освен че когато то само прецени го включва и изключва. А тази клавиатурка е лицето на цялата система. Ако не се изписват адекватно съобщенията върху дисплейчето и, за юзъра цялата система не работи и е пълен боклук. Разработчика дето е драснал малко код на асемблер е външен човек и се е покрил. Познай дали такива ултраизгъзици не се случват.

Друг случай за който се сещам - правим редизайн на едно древно устройство дето още основателите на фирмата са го мъдрили през 80-те. Но понеже има продадени няколко стотин бройки по целия свят и трябва новия дивайс да е съвместим(ако се наложи) за известен период от време със стария протокол за комуникация, мислен някъде там през 80-те в младежките години на шефовете-собственици. Комуникацията пак е по кабел този път още по-дълъг(до 50 m), минава през n на брой разклонителни кутии. Сигналите на физическо ниво са пълна скръб. Няма периферен модул. Комуникацията е с клатене на GPIO-та. MCU-то в моята система има и други задачи, поддържането на стария протокол е така да се каже optional, но познай с коя задачка губя най-много време, коя има най-стриктни изисквания за латентност, куп проверки и таймаути.
Мисля че това са съвсем реални ситуации, които се случват на всеки от нас.
Да спра с тоя пост до тук че се сещам и за още няколко случая.
Спорен ден от мен!

Хубаво е като има реални примери, става по ясно.


Както и да го гледам, тука просто си забравил да направиш "драйвер" за работа с таймера. Т.е. липсва ти централизирано място за мерене и сигнализиране на време. Ако имаш 20 задачи, всяка една от тях ли има кода за вземане на време, за правене на разлика и за сравняване? Това е еднотипна задача и би трябвало да е на централно място. Пести време, нерви и разходки по гори, поляни и заводи. И би имал шанса да я пуснеш на различни места. Какво става ако тоя код (тия таскове) трябва да ги пуснеш на процесор дето няма 32-битов таймер? А какво става ако имаш (реален случай) с 64битов таймер (IEEE1588) и достъпа става на няколко такта? Как синхронизираш конфликтите? Таймерът се води периферия, много често достъпа до нея е през външен бъс за ядрото и отнема повече време. Къде ти е кяра всяка задача да го прави, когато можеш да го направил само на едно място и да имаш списък от събития и получатели (абонати) на известията?

Това, за което говориш, е вид имплементация на софтуерен таймер. Лоша, добра - няма значение. Какво обаче правят тасковете ти когато имат нужда да изчакат? Нали не правят busy-waiting в себе си? Това с таймера може да работи ако ти трябва мерене на изминало време между вече налични събития. За друго не е оптимално.

Тги, много отнесено ми звучи това което казваш. Сигурно има системи, в които неща трябва да се случи еди колко си секунди след power on. Не се сещам за реален пример, но да кажем че има. Значи базовото събитие ти е power on. Или по-скоро ти е нещото което кара процесора да иде на ресет вектора? Да му кажем ресет събитие - остава да решим дали е вътрешно за процесора ...

Колкото до шумните комуникационни сигнали - на това му се казва цифрова обработка на сигналите. Обикновено става периодично, но почти винаги може да се дефинира по-прецизен момент:
- прекъсване на ADC за готово преобразуване - показва точно момента на наличие на нови данни за обработка - ако се вържеш на таймер ще трябва да пуснеш ADC-то и да зациклиш чакайки неговият ready сигнал
- прекъсване от GPIO
В една проста система изглежда че моментите за семплуване са вътрешни събития. Ама реално са външни по няколко причини:
- идват от тактов генератор - това може да е вътрешен таймер (вътрешен за микроконтролера, ама външен за ядрото; то иначе и GPIO прекъсванията може да ги броим за вътрешни за микроконтролера)
- за софтуера не му дреме кой и откъде му дава сигнал за мерене - може да е таймер, ама може да е външен такт (примерно SPICLK), PWM изход от друг процесор на платката (с който трябва да работим синхронно), софтуерно събитие от друг модул, ...

Е не, въобще не казвам това, виж пак. Има и конкретен въпрос за конкретен сценарий, опитай
да му отговориш - може и да не те разбирам за какво се бориш, от отговора му навярно ще
разбера доста.

За кой от двата случая да се хванем, кой ще е по-ясен за развиване?

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

Две едновременни събития, примерно две едновременно напълващи се FIFO-та, които трябва
да се обработят за 10 mS и двете (т.е. по 5 отиват на всяко), и на всяка милисекунда след
началото трябва да се изкарва междинен резултат от всяака от двете обработки през
нещо си, примерно в някакъв DAC (общо два DAC-а), като толерансът за писане в тия
DAC-ове да е примерно 100 uS.
Как би подходил?

Първоначално разбрах че искаш да развиваме някой от сценариите на Zdrav, с дългите кабели.

Отзад напред по описанието ти, то май изчерпва въпросът де, щом имаш нужда да пишеш на определено време, значи имаш някой който тактува, това е събитие. Частният случай е когато не ти пука за фазата на тези моменти на семплуване/вадене на сигналата. Само че в по-сложният случай може да ти се наложи да съобразиш (синхронизираш) фазата на тези моменти с друг сигнал/система.
Какви са вариантите да получиш това събитие, в което да пишеш на DAC-а:
- най-логично е това да е таймерско прекъсване - на всяка мс;
- възможно е да е външен такт - ако имаш 2 CPU-та (заради safety обработка, или заради interleaving семплуване от 2 ADC-та примерно, или заради паралелна мерене от няколко сензора) тоя такт вече е сигнал - например PWM линия между отделните платки/ЦПУ-та;
Доколкото съм се борил, при подобни цифрови обработки на информацията се гони прецизен и дефиниран момент на измерването. Кога да приключи семпъл периода и да премине на холд, започвайки мерене след това - прав ли съм и за твоя случай?
Така, дали няма изисквания към този момент във времето? Ако мериш примерно токовете в един мотор, точката на мерене трябва да е в точно определена фаза на PWM-ите които го клатят (за да е чисто и вярно меренето). За анализаторите ти си нямам и на идея, но бих предположил че има подобна оптимална точка на мерене.
Тоя сигнал, които ще излиза на DAC-а за какво се ползва? Питам, защото в моята идеология гледам кой е консуматора на данните/сигналите, което произвеждам. Ако DAC-а е за наблюдение на сигнала на осцилоскоп примерно, предполагам че се гони да няма фазова разлика с измерения вътрешен сигнал. Т.е. ако виждаш един семплуван сигнал от DAC-а, то е важно дадение семпъл да знаеш от кои входни данни произлиза. Как се съотнася спрямо входния (във фифото). Аз бих очаквам че сигнала показва измерената стойност в последния семпъл момент. Това ни води до необходимостта да знаем (върху осцилоскопа) къде е семпъл момента. Аз бих сложил сигнал (даже PWM) който обръща точно там, където някакъв таймер дава автоматичен семпъл към АЦП-то. И този таймер е онзи, дето клати прекъсването ти.

Кой пълни фифото? Какви флагове/прекъсвания има от него? Това пълнене сихнронен процес ли е (примерно АЦП дето щрака на всяка мс)?
Софтуерът как разбира че има нови резултати за да работи - поллинг на флаг, прекъсване?
Струва ми се че фифото няма много общо с дефинирането на началната точка, от която DAC-а ще започне да подава данни? Наличието на това фифо за oversampling или филтриране ли е?

Ако не съм разбрал нещо, дай да го изясним.