Миро, какви са критериите които ползваш за да определиш дали дадена имплементация на многозадачност покрива изискванията и постига целите на дадена задача.

Това което s.ivanov е направил е също вид многозадачност. Дали мирише добре или не, автора казва че постига целите.

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

Имплементацията не би трябвало да влияе, ако влияе лошо!
Аз по-горе обяснявах за шедулинг алгоритмите, те определят резултатите. Аз, както и повечето други ползвам RMA и по него си планирам. Не изпадам в детайли щото не правя супер критични неща, но долу-горе до нивото (приоритета) което ни е важно гледаме да няма над 60-70% usage. А когато има фал, по закона на Мърфи клиентите веднага го забелязват. За щастие не умират хора, просто бъгове



Да, аз казах че така "може" да работи. Въпреки това изброих и евентуални проблеми

Интересна тема сте заформили, аз още не съм отмил солта от кожата та съм я изтървал, а вие гледам сте се поуморили да пишете
Относно прилични библиотеки (HAL) за stm32 - libopencm3 е добра, HAL-а на chibios от няколко години е разделен от ОС-a чрез абстрактни апи-та и може да се ползва с друг ОС.
А проблемите на team stm32 са повсеместни - последният интересен подход беше алоциране с прекъсване

По-концептуално, аз гледам на прекъсванията като на място за разполагане на тъй нареченото в старите книги "входно-изходна операция". Като учехме преди много лета пишехме алгоритми, и те започваха с вход, и завършваха с изход. Това предизвиква едновременно носталгия и насмешка в повече програмисти, но нещата са толкова базови че е хубаво да им се отдели някой друг час (седмица, полугодие) обмисляне.
Та това което твърдя е че споменатото прекъсване е събитието което дава начало на изпълнение на нещо (или на нищо, но то затова има и забрана на прекъсване). То казва еднозначно кога има смисъл да се върши някаква работа - Миро спомена нещо, с което искам да не се съглася - не мисля че има друго нещо освен промяна в статуса на периферия, което да налага мръдването и на един тригер в ядрото. Има разбира се дървени постановки в които липсват прекъсвания (изобщо, или за конкретно интересно събитие) - но в общия случай хардуера много обича да казва кога нещо е станало и го прави чрез флагове - ма тука се отнасям.
Понеже конкретиката е за контролер алгоритъм (loop) то софтуер има нужда да се клати, т.е. да прави глобално затопляне, само ако има промяна във входните променливи които участват в сметката. С случая на мотор контрол това са:
- позиция на енкодер (ако има)
- стойност на ток или напрежение
- задание за векторите
- и, да не забравяме, ВРЕМЕТО
Т.е. ако пишем математически модел на тоя контрол ще имаме променливи за всички тия неща - вкл. и времето.
Да си представим че имаме подобна реализация под формата на сорс код, и спазвайки някой принципи, за които може да разтеглим локума по-късно, си имаме функция която прави този мотор контрол искайки тези стойности на позиция, ток, напрежение, вектори, ВРЕМЕ, и тем подобни.
Даже да упростим нещата до един ПИД регулатор (2-3 екземпляра обикновено се мъдрят във всеки уважаващ себе си мотор контрол блок).
Та този пид регулатор ще да има входове Kp, Ki, Kd, делта (между задание и обратна връзка) и ... време t. Та твърдението се свежда то това че ако нито едно от тия 5-те не се е сменило спрямо последното викане на функцията няма смисъл да хабим ток пак да повтаряме викането със същите входни данни (щото тя ще изкара същия изход - понеже сме и хванали спатиите (т.е. всички зависимости като входове и сме я направили чиста функция - pure function).
В по-реална ситуации това значи че докато ADC-то не премери нещо ново, или енкодерния блок не отброи/измери нова позиция, и, да не забравим, таймер някакъв не каже "тик" и да ни осведоми че са минали още 100мкс, то няма смисъл да циклим празни (безсмислени) сметки.
Та за да има нужда да върви какъвто и да е код в ядрото трябва нещо у периферията да се е сменило като състояние.

Това ни връща на I/O - алгоритъм - I/O постановката. И ролята на прекъсването е да улесни откриването на промени в състоянието на ПЕРИФЕРНИ блокове, които не могат по друг начин да бъдат "закачени" към алгоритъма. Това идва да покаже разликата във взаимоотношенията между двойката хардуерен-софтуерен блок и другата типова връзка - софтуерен към софтуерен блок. При вторите връзките се правят програмно, а за хардуера има нужда от exception-и (или див полинг, ама нека да не се излагаме).

Има една концепция за играждане на програми от преизползваеми алгоритми и тя се основава на "препредаване на промените" (propagandation of changes). Това му викат общо взето реактивно програмиране и беше засегнато наскоро в друга тема за RxCpp, още може да се види и в FRP програмирането, което е близко.
И това "предаване на промяната" идва да каже че софтуер може да се игражда от блокчета които си правят техните сметки (PID примерно), имат си вход които изисква да бъде "информиран" (закачен) към промяната на някаква стойност (например измереното ADC) и той от своя страна (PID-а) ще има начин да предизвика (информира) следващия по веригата (DAC, PWM, някакъв софтуерен модул като филтър примерно) тогава и само тогава, когато изходът на PID-а се смени (бил е 50, става 51 - информира, после входа от ADC-то мръдва но изхода на PID-а остава 51 - следователно филтъра след PID-а не бива информиран (извикан) понеже няма промяна.
В другия край на веригата стои друг периферен модул - UART, или по-вероятно PWM, DAC или нещо подобно - и съответно последното нещо в тази верига което е нужно е да се тресне новата стойност в PWM регистъра.
Това е т.нар. directed graph или unidirectional data flow - данните "текат" само в една посока - няма "аз ще поискам от еди кой си да ми даде новата стойност на ADC-то, той пък ще поиска от еди кой си хендъл на един какво си че да ми каже че временно няма връзка с този номер...", има "някой ми даде нова стойност и аз бързам да смятам изхода си и да кажа колко е новия".
Тук идва тънката част че ако аз си напиша един код, в който "твърдя" че входа ми е само delta-та (за PID-а от горния пример) то ще сгазя лука - щото ползвачите ми ще ми дават нови делти, а аз ще ак.м лоши данни понеже не ми били дали Kp примерно, или те ми дали делта, тя повече не се сменя и те не ме викат - обаче аз съм си бил сложиш един extern към глобален брояч на ms, или си викам вътре GetCurrentTime() - това е сбъркана постановка понеже вътре в кода се крият връзки навън (зависимости), които не се решават само с това кода да се компилира - ако някъде има имплементирана тая GetCurrentTime() кода ще се билдне, ама софтуера ще взриви мотора - понеже не е спазено друго изикване - да се вика "постоянно" или другата интересна фраза "колкото е възможно по-често". А? Че като му трябва време да си каже, и да не се прави на интересен да иска точно GetCurrentTime() да му правя.

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

А дали този изчислителен алгоритъм ще е в прекъсването или не зависи от изискванията към системата - ако наистина това е най-времекритичното нещо, и няма друга работа, то нищо не пречи кода да си тича вътре - от тегленето на ADC регистрите до мушкането в PWM регистрите. Въздух за други дейности ще има ако честотата на този луп (който обикновено се "тик-ва" от PWM честотата чрез някакъв тригер от таймер към ADC за да се хваща тока в "тих" участък от цикъла) е съобразена с продължителността на изчисленията в прекъсванията.
Ако примерно някой зададе контролен луп на 100КХз (10мкс), и алгоритъма дърпа нето 6мкс, а преключването на контекста на някакъв шедюлър иска по 2мкс (примерно), е ясно че кода няма да тръгне ако му турим по няколко прехвърляния от ISR към IST. И ако клиента си ги иска 100-те килохерца или правим кода без превключване, или ходим гладни.
То затова всеки уважаващ себе си RTOS гледа да позволи да има прекъсвания с толкова висок приоритет, че да не могат да бъдат забавени от тредове. Което на кортексите е лесно и се ползва активно.

Към Ivanov и въпроса за лесен начин за организиране на шедюлър - ще опиша една нарастваща градация, която може да е полезна:
- най-отдолу е елементарния дизайн в който всичко се клати само на прекъсвания - красива утопия която не е много лесно да се постигне, но ако си покрил техническите задания използвайки нея, то наистина няма причина да бърбальокаш още код
- ако обаче има ситуация, в която не ти стигат прекъсванията като вектори - например имаш ADC прекъсване и в него получаваш както токовете на мотора, така и например температура на силова част (на отделен канал на ацп-то) и искаш на всеки 10 минути да логваш температурата примерно в eeprom, или карта, или да пращаш по uart или друг интерфейс, т.е. като цяло ти се налага да направиш нещо което може да те блокира за повече от допустимите ти 10мкс, то тогава имаш разклоняване на кода в някаква точка на ADC прекъсването. 999999 цикъли си смяташ само пид-ове, кларки и парки, но на 1000000 цикъл искаш да викнеш един "eeprom_write()". Но тоя eeprom_write пише че може да дръпне до 200мкс и ти виждаш какъв голям те чака ако просто го викнеш. И разбира се усещаш че трябва да го пуснеш да тича в по-нисък приоритет - извън твоето прекъсване. Тук можеш да вдигнеш флаг и да очакваш че някой в main()-а ще го свърши, но това има недостатъци като например неизвестно време докато му дойде на мейн-а да запише щото някой добавил едно цикълче и такова кооперативния дух в мейн-а. Та тук идва другата лесна опция - генерираш софтуерно прекъсване, или друг ексепшън, който лесно можеш да го жулнеш на по-нисък приоритет.
- ако изчерпиш и всички приоритети за софтуерни прекъсвания отиваш на версията в която "разширяваш" броя на нивата на приоритет чрез софтуерно приоритизиране, т.е. ОС или поне шедюлър, за който Миро говори.

Тънката част тук е останалия ти код да е така организиран че за половин час да можеш да минеш от първия до третия вариант, и за още толкова време да сменяш към произволен шедюлър. Което ни връща на много по-важната тема как да се пишат алгоритмите, така че да можеш функцията на пид-а да е можеш да я викнеш директно в прекъсването, но и да можеш да в турнеш в тред който е на 5 контекст свича от прекъсването Онова с GetCurrentTime() е много вероятно да ги изиграе шега (ако го имаш вътре в TheBestPid() ), но ако ThePurePid() има аргумент currentTime_ms може и да е по-гъвкаво?

Тука не съм съгласен:

"Та този пид регулатор ще да има входове Kp, Ki, Kd, делта (между задание и обратна връзка) и ... време t. Та твърдението се свежда то това че ако нито едно от тия 5-те не се е сменило спрямо последното викане на функцията няма смисъл да хабим ток пак да повтаряме викането със същите входни данни (щото тя ще изкара същия изход - понеже сме и хванали спатиите (т.е. всички зависимости като входове и сме я направили чиста функция - pure function).
В по-реална ситуации това значи че докато ADC-то не премери нещо ново, или енкодерния блок не отброи/измери нова позиция, и, да не забравим, таймер някакъв не каже "тик" и да ни осведоми че са минали още 100мкс, то няма смисъл да циклим празни (безсмислени) сметки."

PID трябва да интегрира грешката докато я направи нула или поне близка до нула. Това само по себе си налага периодично викане. Работата му е да направи грешката близко до нулата чрез интегратора. Също конкретно този процес е динамичен, поддържането на нулева скорост/позиция постоянно променя обратната връзка така, че вариант да не се промени нищо на практика няма (за тази задача).

С другите неща съм съгласен даже ми дават идеи за някои проблеми. Засега съм на точка две от списъка с възможни решения за 'многозадачна' работа.

Относно пращането по сериен канал: пуснат е ModBUS и работи добре. Предполагам и работа с SD карта няма да му пречи. Имам io модул с атмега и чужд Интернет стек + четене от карта (включително web страници), modbus rtu/tcp и д.р. и работи прилично добре (като скорост).

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


По-скоро това важи за всеки RTOS... Трябва много да НЕ се уважават, че да пуснат нишка над прекъсванията И цялата тая тема е точно за това, че не бива да се изпълняват нишки в прекъсвания точно защото така те стават потенциално "над" други прекъсвания.
А при “уважаващите“ се ОС-ве номерът е друг - позволяват се прекъсвания с по-висок приоритет от кърнела. Отделно нито в нишките нито в кърнела не се ползва забрана на прекъсвания. Така системата се разделя на две части - хард реал тайм част с малко задачи, но които никой не може да забави. И обикновени задачи/нишки дето се търкалят от кърнела.
Тая концепция се налага тъй като няма как един софтуерен кърнел да е многозадачен или реентрант. Повечето системни функции не го позволяват. Затова тъпите ОС-ве забраняват прекъсванията, а по-добрият вариант е вдигането на нивото над всички OS-aware. Пък тия които не са aware те могат да си прекъсват без да чакат.

Разбира се че е така. Това което искам да кажа е че това "периодично викане" се случва понеже променливата "време" се сменя, т.е. по същата логика по която се случва викане понеже променливата "делта" се е сменила, или някой от другите входове. Няма нищо специфично във времето, то може да се разгледа като допълнителна входна променлива, нужна на някой алгоритми (пид-а, филтри, интеполатори и много други). Няма математическа разлика която да изисква специално отношение към нея - стига да има един таймер, който да може да казва "смени се времето", примерно с дискрета 100мкс, или 1мс или нещо подобно, то цялата логика за пропагандиране на промяната се запазва същата както и за ADC резултата.

Миро, може и да не съм те разбрал напред някъде - мисля че споменаваше нещо в смисъла че има и разни "вътрешни" събития - исках да уточня че такива (вътрешни) събития няма, всичко което смята сметалката е логически започнало с някакво прекъсване, пък било то и таймерско (таймера го гледаме като периферия някаква). Пост-ване в майлбокс, сет-ване на евент са начини за създаване на вътрешни сигнали между различни контексти (тредове/процеси). Но те описват една верига от действия, която като се разгледа примерно в трейса стига до някаква хардуерно прекъсване/ексепшън.
И тази верига (активити да го наречем) почва винаги от прекъсване и ако има нужда се движи в различни контексти докато стигне го финалното I/O действие което обикновено е запис в периферен регистър.
Ако имаш подходящите условия тази последователност можеш да я опишеш като низ от викане на функции, първата от която е хендлъра на прекъсването и последната да е писането в регистъра - това е което е направено явно в дискутирания код.
Много често обаче се налага същата последователност да се разпредели в различни тредове - началото в прекъсването, после в по-нисък приоритет (софтуерно прекъсване, тред), после в друг и т.н. Важното обаче е описания алгоритъм, по-точно последователността от елементарни действия, да са така "кодирани" че да могат лесно да се цепят във възможните точки за да се играе с приоритетите.
Точно в тая зона има много да се борим докато стигнем достатъчно "качество" - сега често се среща тия "връзки" да са част от алгоритъма - т.е. в самия PID да е записано да праща в мейлбокс на един кой си когато изчисли.
Стремежът в някой езици/фреймуерки е тази работа да бъде улеснена - например в Rx (RxCpp/RxJava и сие) има оператори с които казваш в кой тред да се изпълни останалата част - subscribe_on, observe_on - това позволява да укажеш че същата последователност, която си описал като лесен за проследяване call graph да се прехвърли в друг тред от някаква точка нататък. Концепцията е кода да е толкова чист като визия че да липсват усложненията които ние виждаме като пост-ване.
Това в новите езици, дори cpp го развиват до "async-await" идеята - palavrov я спомена покрай node.js, но тя е концептуална и я има в много езици - това е следващата стъпка след callback идеята - при колбеците имаш викащата функция, примерно file_read() и на същото място в кода виждаш "onData" колбек и можеш да проследиш мисълта на автора (особено с lambda синтаксиса или просто с анонимна функция, които ги има и в cpp след c++ 11).
Това е много приятно, ама когато имаш едно ниво на асинхронна операция - когато в колбека за който говорим трябва да имаш следващо викане и следващ колбек, и после още няколко нива кода почва да изглежда претрупан (макар че пак е много по-добре отколкото да трябва да търся дадения мейлбокс кой го чака, и това да е някъде в друг файл ...).
Номерът е че има едно по-високо ниво на абстракция, свързано с трединг модела и при него примитивите на ОС-а като шедюлър и синхронизации са вътрешен проблем, който не се вижда от потребителя - примерно такива са active objects, observable патерните. А другото му викат "free threading" - т.е. модел при който не се спазва такъв паттерн, а всеки си решава къде да сцепи, как да синхронизира и т.н.
При active objects програмистите не виждат апи за тредове - те виждат апи за поискване на работа от съществуващ "актьор", със или без връщане на резултат. Това е една имплементация (иска c++ 11) която показва идеята доста добре:
https://github.com/lightful/syscpp
Има и много други, вкл. на C като например QP фреймурка на Miro Sameк.
Но идеята е такава - паттерн с който да не се оставя на програмиста да работи с апи-то на ОС-а, а да се обхване с абстракция която да "извади" от кода всякакви "boilerplate" неща които нямат отношение към "алгоритъма" (PID-а) а са там за да пригодят кода му за работа в специфичния контекст.
Преди години бях върл фен на active objects, но се оказа че има и по-напредничави неща като observer-ите, сигнал-слот и нещото което в момента се смята за "връХта" - FRP от типа на sodium-frp.
Palavrov може да удари едно рамо, но той си го е казвал - това е много силната страна на node.js и като цяло на libuv - там хората са извадили цялото I/O (файлове, сокети, ....) и ти остава само логиката на конкретното ти приложение. Това като идея светва лампичката че този подход позволява накрая огромни приложения да тичат в един-единствен тред (понеже всичкото i/o е в отделен). Там всичко се пише асихнронно - по-рано като колбеци, напоследък прилатат и async-await и кода е, бих казал, безкрайно по-чист от нашите ембедед изцепки. И не е причината че имат много ресурси - а това че ползват добри концепции.
С влизането на std::threading са тръгнали по подобен път - по същия начин по който не мислиш за библиотечки неща като математика, алокатори понеже ползваш newlib или друга C рънтайм библиотека, те искат да превърнат OS абстракциите, които ползваме за да не се "женим" за един ОС в поредната функционална библиотека. Засега в ембедед света само mbed съм ги хващал да разчитат на тия неща и спокойно да ги ползват - т.е. те имат имплементация на нужните услуги за да работи std::threading в тяхната библиотека за техните ОС или ОС-ове (мисля че могат да сменят между RTX и freertos).

gicho, пишеш много и за различни неща. Фокусирай се малко че така трудно ще се получи диалог



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

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

Аз бих казал друго - груба грешка е при разработката на алгоритъм да се опитваш да мислиш как и каква синхронизация ще има - алгоритъма винаги започва с входни данни и приключва с резулат, който трябва да е зависим само от входните данни (и алгоритъма, и евентуално стейта ако не е изчистен от това). Затова един от подходите е да се правят малки и по възможност чисти функции, които да правят сметкита за дадения алгоритъм, а на друго ниво да се мисли за интеграцията.
Тук идват тия async-await и подобни за да те оставят да пишеш само алгоритмичната част, да маркираш/декларираш къде може да има асинхронна операция (което значи да означиш "вход", "алгоритъм" и "изход" - като typedef и прототип на функция), и оттам насетне компилатор, рънтайм, библиотеки да се оправят с това нещата да работят. Това може да се автоматизира - в смисъл да има описания на ограничения, да кажем времеви, и една достатъчно развита среда/компилатор да направи нужното за да ги разхвърля по прекъсвания, тредове и т.н.
Няма алгоритъм, който да изисква синхронизация - такава ти трябва само за да разделиш отделни части, т.е. малки алгоритъмчета, и искаш едното да тича в един приоритет, а второто в друг.
Когато пишеш криптото можеш ли да кажеш колко треда, с какви приоритети ще има във всеки един възможен проект, които дай боже ползва твоята крипто библиотека? Аз поне не мога и съответно гоня екстремума - единични, самостоятелно използваеми функции, без зависимости (ползването на post_xxx() e вид зависимост която не е добре да я има в кода).
В примера с мотор контрола може да се види че има няколко пид-а примерно - един за токов контрол, един за скорост, един за позиция. Всеки един от тях тича в определен и единствен контекст, може и трите да тичат директно в АЦП прекъсването, може нито един да не е там, а просто ADC драйвер да пост-ва резулататите към тред - но това не променя факта че първия (токовия) си остава целия в един контекст (тоя тред дето получава ацп данните). Имам предвид че не е типично един пид да може да се скърши посредата и половината сметки да тичат в прекъсването, половината в треда. Ако такова нещо има, т.е. ако някой е успял да пусне една част от даден алгоритъм в един контекст, а друга част в друг, то той е успял да довърши работата и да "открие" че всъщност има два отделно използваеми алгоритъма, които някой мързелив е блъснал в една функция. И има сечение между тях което може да ги раздели чрез прехвърляне на данни.
Иначе не се удовлетворява условието да имаш вход-сметки-изход, имал си вход-сметка1-междинен резултат-сметка2-изход, което се разлага до вход-сметка1-изход + вход-сметка2-изход.

Може би не се изразявам ясно, но това което искам да наблегна е че трябва да се избягва вкарването на каквито и да е сихнронизации в нивото но алгоритмични компоненти - дори и да са псевдо-ОС-абстрактни викайки примерно Posix API. Проблемът е че някой ми е сложиш в края на PID-а някакво постване в мейлбокс и държи да получи подобно АПИ (post...() ), то това ще е излишно в случай че искам да го ползвам без ОС и ще трябва да правя mock-ове и стъб-ове за да му задоволя исканията, или ще трябва да ползвам неговия ОС, или ще трябва да правя адаптация на друг ос да изглежда (и да се държи) като този за който той е писал.
Дали ще трябва синхронизация, дали ще има тредове или не изобщо не е от компетенцията на програмиста, който прави функционални алгоритми, например пид-а или криптото. Когато се прави интеграция на система (проект) използвайки такива компоненти ще се направят връзките, ще се сложат тредове, кюта, ос-ове - ако е необходимо.

gicho, говориш за висша математика, а очевидно не знаеш таблицата за умножение

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

Всеки компютър е автомат с памет. А това е такова животно чието състояние зависи както от входовете така **И** от съдържанието на паметта му. Само по входните въздействия НЕ МОЖЕШ да определиш каква ще е реакцията. Това не ти е комбинаторна логика, където може да развъртиш комбинациите и да кажеш при такива стойности на входовете ще има такива стойности на изходите.

Иначе казано ако ти можеш да предскажеш какви събития ще ти генерира една софтуерна нишка на базата на прекъсванията или други нейни входни данни, директно ти давам 1 милион $ в кеш. Не можеш! Не и в тази Вселена в която й остават само още няколко трилиона години живот

Моля те седни и прочети малко повече за основите на информатиката. Знам че обичаш да четеш теории. Не се заяждам, наистина вярвам че ще ти е полезно

gicho, не съм ти чел подробно другите неща, дето си писал, ама и това горе не е вярно така както си го написал. Ако от Kp, Ki, Kd, делтата и времето в един ПИД закон нищо не се е променило ИМА смисъл да се вика изпълнението на процедурата за калкулиране на закона, защото дори и да няма промяна има натрупване на грешката, което неменуемо ще доведе до промяна на И часта от ПИД закона, т.е. при непроменени входни данни на един ПИД закон вероятността да се промени изходното въздействие клони към 99%. Единствено няма да се промени ако делтата е нула, при всяка друга стойност на делтата, дори и тя да остава непроменена изходното въздействие на ПИД закона ще се промени (разбира се докато не стигнеш долната или горната граница на изходното въздействие). Та ако си правиш така ПИД законите (да не ги викаш ако няма промяна) е време да си смениш тактиката .

+1

Az бих добавил че не опростяваш нещата с ПИД-а ами вече се мъчиш да изместиш темата на дискусията нанякъде защото тезата ти явно издиша.
а лакардията за ПИДа дето се помъчи да я почнеш си е откровенна тъпня

е, не търси чак такава умисъл...
На gicho му се говори. Не знам за вас но темите дето иначе несвързано повдига са интересни.
Грешката с викането или невикането на ПИД-а няма да остане незабелязана и няма да събори никого. Това се коригира лесно.
Дет' се вика това да ни е проблема.
По-важното е че за разработчиците на motor control алгоритмите някой трябва да осигури достатъчно абстрактно ниво така че те да не мислят за RTOS, примитиви за синхронизация и т.н. Да не се налага да цепят алгоритмите на части за да може после да се натъкми многозадачността. Това ми напомня за един колега, заклет писач на асемблер, дето ми обясняваше как пренареждал и вмъквал инструкции тук-там за да получи почти паралелно изпълнение на няколко(май бяха две) задачи.
RTOS-а трябва да е невидим. Драйверите да не са пипани с години. И в същото време трябва да има точно разписани и после измерени параметри които да показват, че задачата е изпълнена и с какво качество.
Такива неща като:

да не кажа че намирисват, но просто дрънкат.
Миро, нищо лично, но няма как да четеш инженерен морал на s.ivanov ако мериш с такъв дърводелски аршин.
Без да омаловажавам опита ти, напротив, ти си един от малкото останали хора във форума, чиито мнения прочитам внимателно.

това на 100% съвпада с моето скромно мнение.
Характера на някои задачи предполага използването на ОС в същото време други задачи в същата система се решават елегантно с прекъсвания (особено ако имаме МЦУ с интеръпт контролер). ОС и прекъсвания не са взаимноизключващи се просто по-принцип.

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



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

Що се отнася до шивашките метри... За съжаление много пъти сме обсъждали дебъг инструментите и съм обяснявал от какво има нужда, но така или иначе не седнахме да го направим. Аз все пак имам сравнително бърз трейс, но има още много какво да се желае. Така че срам, не срам иситината е че всички (без изключения) работим с "дърводелски метри" и няма какво да се правим на ощипани девойки. Може би някой от тия дето се занимават с лайнукс, там има някакви софтуерни решения, но при контролерите... уви.
Далеч, далеч по-важно е обаче да знаеш какво мериш и защо го мериш, а не дали ползваш китайски мултицет или 8.5 digit meter. Но преди това май трябва да се поговорим още на тема що е то многозадачност, система за реално време и имат ли почва у нас. Нещо имам чувството че не се сме на едно мнение и от там мерим различни неща.

Въпреки че много пъти ги описвах нещата, хайде още веднъж ОТНАЧАЛО:

#Abstract
Има дава проблема.
Първият е, че основно се ползват алгоритмични езици, с които може да се опише алгоритъма на един процес. Но в реалния живот имаме повече от един процес/задача, които трябва да се изпълняват паралелно. Как да стане това, след като изразното ни средство не позволява паралелна обработка и отдолу също имаме само едно изпълнително устройство?
Вторият проблем е, че в някои системи задачите не просто трябва да се изпълняват правилно, но трябва да се изпълняват в рамките на някакво време. Неспазването на времето е провал. Примерно кола се движи срещу бетон. Имаш определено време да натиснеш спирачката... после е късно.
Това са системите за реално време и при тях *всяка* една задача има времева рамка. Нито една задача не бива да се проваля във времето.

#Решение (едно)
Има много решения, но едно се ползва в над 90% от случаите. Това е RMA scheduling.
Алгоритъмът го има описан в нето, много пъти препоръчвах да се чете....тук само ще подчертая че това е алгоритъм. Как точно ще е реализиран тоя алгоритъм - с кърнел, без кърнел, софтуерно, хардуерно - няма значение. Доколкото се спазва алгоритъма, останалото е подробности.
Ще се опитам възможно най-простичко да го обясня:

Значи имате задачи...
1) Гледате всяка една задача с каква честота може да се появява. Примерно получаването на един байт UART на 9600 - това е задача горе-долу с честота 1khz. Демек тая задача може да ни се налага веднъж на 1ms. Не е казано че всяка милисекунда ще получаваме, интересува ни максималното натоварване.
2) Всички задачи се сортират по тяхната честота. Иначе казано на задачите се поставя приоритет еквивалентен на честотата им. Задачата с най-висока честота е с най-висок приоритет. Много програмисти определят приоритета според "важност". Не, при RMA всичко е важно няма маловажна задача, има само задачи с различна честота.
3) Във всеки един момент от времето задачата с най-висок приоритет, която иска управлението трябва да го получава. Как точно ще е реализирано това, дали с кърнел и смяна на контексти, дали с хардуер няма значение.

Това е. Нищо сложно!
Останалото е математика... Тя не е сложна между другото. Условието да се изпълняват n задачи, всяка изискваща изчислително врене Сi и имаща период Ti e:

В случая U е CPU usage-a. Aко са 2 задачи той ще е под 82%, ако са клонящи към безкрайност е 69.314...%
Без да задълбавам ще обясня само на "дърводелски" език какво следва от математиката:
Ако имате система само с една задача, примерно UART-a за да не изпуснете нито един байт очевидно всеки получен байт трябва да се обработва максимум за 1ms. Aко изберете такъв процесор, който изпълнява тая обработка точно за 1ms и байтовете идват всяка ms ще получите 100% CPU usage. Системата ще е на ръба, но ще РАБОТИ. Няма да има изпуснат байт.

Сега нека да добавим още един UART който е да кажем 115200. Демек имаме две задачи. Нека задачите са независими. Ако ги изпълняваме на два отделни процесора можем да сметнем единия колко инструкции в секунда са му необходими, на другия колко така че и двата проца да са 100% натоварени. Това би било най-високото възможно КПД на използването на ресурсите.
Сега ако вместо два искаме да използваме само един проц, то неговата производителност не може да е автоматичен сбор от производителността на двата. Трябва да има запас, иначе той пак ще изпълни същия брой инструкции като двата, но не в абсолютно същия порядък. Може да се изпуснат байтове. За да не се изпускат е необходимо при две задачи проца да е толкова бърз че да се натоварва не на 100% а само до 82%.
С увеличаване броя на задачите, трябва да се увеличава и запаса и математиката казва че при безброй трябва да сме под 69% cpu usage. Математиката обаче не взема предвид времето за превключване на задачите както и някои други подробности. Затова като казвам 69% на практика като се планира е добре да се оставя още запас. Да не говорим че на практика НИКОГА не е добра идея да сметнеш всичко до дупка. Всяка една система трябва да може да се ъпгрейдва софтуерно и утре ако се наложи добавят още задачи. Така че е съвсем в реда на нещата да не се гони ТОЧНОСТ в сметките. Ако изчисля че ми трябва около 100MIPS CPU не е важно дали са 95.644 или 107.232232. Аз така или иначе ще сложа ПОНЕ 200MIPS.
Сметките се правят за ориентир и "дърводелския аршин" е повече от достатъчен като точност! А и като почнеш да пише предварително така или иначе няма как да знаеш точно колко инструкции ще отнема максимално обработката на един байт от UART-a примерно. С времето се натрупва някаква интуиция, но все пак интуиция т.е. нямаш точност предварително. Истината е в дебъг инструментите, които вече като си изградил системата да замериш коя задача какво процесорно време отнема и тем подобни статистики. Но това е "следварително"... пък и за съжаление не разполагам с такива инструменти, уви.

И чисто практически съвет... Значи пълен анализ на една система е трудна работа. Обикновено няма как да се направи предварително. Но трябва да се знаят критичните места. Те за щастие се откриват сравнително лесно. От горния алгоритъм след като си направиш списъка със задачките и тяхната честота се отделят потенциално опасните. Примерно задачката с UART дето се прави на 1ms. Ако на избрания проц тая задачка изисква микросекунди, тя трудно ще създаде ядове. Ако обаче изисква няколко стотин микросекудни трябва ти светне една ламбичка. А ако изисква над милисекунда вече ламбата е в червено и трябва да се върне проекта в изходно положение
Така си оглеждам задачките до определен приоритет, щото реал тайма винаги е до едно ниво. От там надолу са задачи които не изискват реал тайм и съответно за тях няма какво да смятам времена/cpu usage. Досега за толкова години проблем с тоя подход не съм имал, затова и не съм седнал да правя онези дебъг инструменти дето спомнах...

Хайде помисли малко още веднъж и се фокусирай върху отговора на един лесен въпрос, очаква се "да или не":
Та, ако "времето" не се е променило, т.е. веднъж сме извикали пид функцията в момента в t=12345.00мкс и тя е дала изход 10000 единици, ако я повикаме втори път при СЪЩОТО ВРЕМЕ, т.е. t=12345.00мкс, ще има ли различен изход от предишното 10000? Да го кажа като теб - ако твоя регулатор извади различно от 10000, значи не е коректен...
Не случайно натъртих многократно на ВРЕМЕТО досега - много е типично за "класическите" (императивно-обектни) програмисти да го изолират и да си усложняват нещата. А те са по-прости, стига да се мисли малко по-математически.

А за многозадачността ще пиша след малко - не споря че я има и както Миро спомена, си има математически начини - следователно е задължително тези изчисления, ограничения (constrain) да се декларират и да се ползва методика за гарантирано правилно разделение по "тредове" - а след като има методика, значи това е въпрос на инструментализация - описване на изискванията и ограниченията и оттам насетне инструмента да намери решението.
Това е като pcb дизайна - може да рутиш ръчно или да си поиграеш да опишеш правила за да може инструмента да ти помага или дори да я върши вместо теб. В единия случай нищо не гарантира че ще стане правилно, в другия случай иска да се напънеш веднъж да направиш правилата (и инструмента да е наличен разбира се).

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

Пак да го кажа - ако така си правиш регулаторите да викаш пид закона когато ти падне - време е да попрочетеш малко теория на регулирането