Хайде и ти не се измъквай
Твоето твърдение беше, че синхронизациите може да се оптимизират едва ли не винаги. Според теб задачите не внасят нищо ново, внасят го сигналите на техния вход. Следователно самите задачи може да се шунтират и всички зависимости да се сведат само до някакви входни сигнали.
Подобно твърдение е изпълнимо само за процеси, които нямат вътрешно състояние (памет) и резултата от процеса може да се предскаже ако знаеш входовете му. Това са много малко ситуации. В общия случай Е НЕВЪЗМОЖНО да предвидиш какви резултати ще даде един процес съдейки само по входните му данни. Това дали е софтуерен или хардуерен процеса няма никакво значение. Софтуерът също е НЕПРЕДВИДИМ на практика.
Затова и твоята идея да нанижеш задачките асинхронно една след друга по някакъв статичен алгоритъм няма как да стане. Няма как да направиш шедулер който гледа само входни събития и по тях да решава какво да се прави. Всъщност то може, но ще е ебати неефективния шедулер ;–)

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

Гичо, примера който даваш е супер объркващ според мен. Затова и Димитър така ти е писал. Връщах се поне 3 пъти да ти чета частта с обяненията, за да загрея какво искаш да кажеш.
Отговорът ще е "не" само ако целия ти пид се клонира и изпълни паралелно на 2 процесора едновременно, при еднакви входни параметри - само тогава ще имаш еднакви резултати. Като си го написал "повикаме втори път", става ясно, че времето не може да не се е променило - тогава отговърт ще е "да".
Още повече пишеш за "предишното 1000", което пак намесва времето и дава сигнали, че си ги сметнал последователно а не паралелно.



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

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

Гледайте го по просто - имате глобална променлива uint32_t current_time_ms или функция uint32_t GetCurrentTimeMs().
Свеждаме въпроса до това дали имаме основание да предполагаме че тази променлива може да има една и съща стойност при две проверки/викания? Някой дава ли гаранция за това? Все пак е външен код, и номера "аз го пробвах, викнах го два пъти с един while(1000000) между виканията и то върна различно" не е много валидно основание.

Това, за което исках да говоря, е че кода всъщност е някаква ръчна или автоматична имплементация на някакъв по-висш модел (най-често математически). И има идеи според които това преобразуване от математика до дискретно цъкащ C код, с тредове, синхронизации или без, да е по силите на автоматичен инструмент.
В ембеддед обичаме да си представяме нашите проблеми като много сложни, от страшно високо ниво, и да се оправдаваме с малко ресурси - т.е. да си мислим че само висш интелект като този на ембедед програмист може да измисли как от прекъсване да се викне верига от алгоритми, и да ги раздели по тредове така че спази някаква дефинирана логига. Само че ръчният, занаятчискийски подход е рискован - изцяло в ръцете на програмиста е да провери и предвиди всичко. При автоматизиране това става задължителна част от дизайна и не може да се прескочи докато не се изчисти този проблем (грешка).
Реално ще е много приятно ако компилатора (или подобен инструмент) след края на билда каже "грешка - time overflow на един кой си процес". Това си го има и се ползва много отдавна в по-критичните отрасли - визирам AUTOSAR. Там планирането на времето е основна част от процеса и кода не се билдва докато не се задоволят поставените изисквания.

Когато пиша ПИД имам две опции - да кажа че съм направил най-бързия пид, но той е такъв защото съм вкарал на предкомилатор Kp, Ki, Kd, лимити, размерности на променливи и дискретата на времето, или да направя друг, които може да приема промерни на всички коефициенти и дискрета рънтайм. Да, втория сигурно ще тича по-бавно, но на някой може и така да му трябва. Може да има и темплейтен вариант, в който компилатора да направи по едно копие на регулатора за няколкото използвани набора от коефициенти, но това няма да работи ако тия коефициенти се сменят рънтайм също.

Пак да те питам - ти кога викаш ПИД-а? На предварително известни равни интервали от време (съответно и дескретизацията на входните ти сигнали работи на фиксирани интервали от време) или в някакъв цикъл правиш разни работи и също викаш нещо от сорта на uint32_t GetCurrentTimeMs() и викаш ПИД-а само когато тая функция ти връща различен резултат от предишния. В същото време викаш още няколко други такива функции за входните въздействия (АЦП-та, енкодери и т.н.) и ги вкарваш и тях в условието за викане на ПИД-а?

Вярно ли ще си обясняваме такива неща?
Основна цел при писането на кода е да се разделят "алгоритмите" от "данните", с които те работят.
И да подскажа - алгоритмите по правило стоят в една памет, дето и викат read-only, и няма как данните (входове, изходи, стейт) да са пак там Или още те (алгоритмите) стоят в библиотеки, в които данни няма.
Та тия три неща - входни данни, изходни данни и стейт (контекст) стоят в RAM си мисля. И една и съща функция от флаша - примерно PID() на адрес 0x80000000 мога да я ползва с 14560 различни набора от вход, изход и стейт (или с нула, или с един, или с три, ...)
Сигурно е възможен подхода в който в рам се правят 14560 копия на инструкциите на PID() функцията и за всяко копие се добавя стейт като структура от 8 байта примерно, но аз така не го правя Просто ме мързи, но понякога и рам-та не стига за такъв висш пилотаж.
Реално входните данни са изход на някой друг, изходните са вход за друг. Само че има и по-сложни връзки - 1 към много и много към 1. Например ADC резултата е една uint16_t променлива примерно, която освен вход на PID-а може да е вход на един компаратор за реализиране на защита по ток, на един интегратор за I*I*t защита, на още един компаратор за да светка лампичка ако има ток и т.н. А изхода на пид-а се ползва като вход за филтър, но и вход за втори, трети, четвърти компонент. Така че не можем да кажем че някой си вход е на точно еди кой си алгоритъм. Изходите са по един, но и там не са собственост на алгоритъма заради инстанциите.
Стейта (вътрешни, инстанционни данни) са по един за всяка ИНСТАНЦИЯ на алгоритъма - понякога (в обектния стил на програмиране/дизайн) това се водят вътрешни данни. Във функционалния стил не са - там са приравнени до входни данни.

gicho, остави лопатата, достатъчно се закопа

ПИД-а се вика при всяка промяна на всеки от входовете му - по време на работата разбира се вика основно при промяна на променлива време, която се сменя +1 да кажем на всяка 1мс. Така че функцията PID() се вика на всяка мс - нищо различно от твоята идея. Но ако накарам променливата за време да скача през 100мкс ще получа викане на всеки 100мкс. И поради това че имам стойност за време (timestamp) мога да променя изчислението, или да открия дупка във викането. Ако кода се вика неравномерно - примерно някъде се прескочат 9 викания, кода би могъл (има данните) за да направи корекция и пак да изкара приличен резулат. Или просто да вдигне грешка че не му играят по свирката.

Функцията за ПИД не вика никого - тя не събира входните си данни - просто декларира аргументите си с техните типове, и изисква/очаква който когато поиска да я вика. Ако няма ограничения откъм процесорно време и/или има достатъчно бърза плаваща математика може да ползва на всяко викане времето за да изчисли математически верен резултат, независимо че е викан през 1, 6, 17, 2, 3, 10 мс.
Ако има лимит може тотално да игнорира аргумента време и да си приема че го цъкат на зададените 1мс - или да проверява само дали е различно от очакваното и да вдига грешка.

Реално тази тикваща на 1мс променлива се ползва за да се създаде събитие за викане на веригата на тоя контрол луп.

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

И аз ще кажа като Миро - заеби лопатата вече .

То нали има древен закон, според който всяка програма има свойството да се усложнява докато надскочи възможностите на програмиста.
А правенето на читав ПИД е достатъчно сложно (и понякога трудно предвидимо) за да го разбъркваш излишно.

батеБонго, не доливай боза в гювеча
правенето(имплеметирането) на пид регулатор е сравнително лесно. трабва да се спазват правилата и готово. Сложното е конфигурацията и настройка. И преди да почнеш правенето и настройването трябва да си отиговориш на едни такива неудобни въпроси от кой ред ти е системата която искаш да регулираш, например с ПИД може да се регулира нагревател на бойлер и управление на 5Кв синхронен двигател или на стрелата на кулокран . обаче са системи от различен ред, има си критерии за стабилност, за време за установяване, за адаптивност.

темата беше за съвсем друга ама искахме да стане по-хубаво - пък се получи както винаги

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

Тони,

нещо не си разбрал какво съм писал. 20% при 100uS или 30% при 60uS период на PWM. Така ясно ли е ? FOC с всичките други неща: 20 uS без оптимизация и float. Има код качен в github, има видео в youtube. Ако има нещо неясно ще отговоря но не мога да приема да ми се преписват твърдения само защото някой е чел-недочел.

https://www.youtube.com/watch?v=-H6VtrKg9PY&t=0s&list=PLE616v1yP137koahQjisksADdZlHxYS2S&index=11

Да има jitter, но не е 10uS...

П.П: Чудя се дали изобщо когато се напише нещо то бива прочетено?

Даже се оказа, че сметките са под 20 uS...

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

Не отричам че "може и така", т.е. пид-а или подобен алгоритъм да се вика през определено време - и повечето имплементации са оптимизирани точно в тази посока за да се спестят деления. Това е пределно ясно и проиграно многократно.
Въпросът е има ли и други начини, и дали има специфични ситуации в които да има алтернатива? За целта поглеждаме псевдокода у википедията:
https://en.wikipedia.org/wiki/PID_controller#Pseudocode
и обръщаме специално внимание на "dt" променливата. Представяме си че loop-а го няма, а тялото е направено на функция, която и трябва и dt аргумент. Мислим, гледаме и разсъждаваме дали има място под слънцето такава реализация, и какво различно ни дава?
Големият проблем е това:

т.е. нуждата от деление. Ако то (делението) не ни притеснява - щото имаме бърза математика, щото не ни пука за консумираните CPU цикли, щото няма да ползваме D частта, може да си позволим да продължим еретичното мислене дали пък в някоя странна ситуация екстрата да можем да викаме през не-константно време няма да ни даде някакво предимство?
Пак да кажа че в 95% процента от случаите отговора е твърдо "нйе" и си караме по старому - махаме и делението сменяйки го с шифт или подходящо скалиране на коефициентите - преди, вътре или след регулатора и си пием бирата.

Тука не знам дали няма да изтърва аудиторията понеже навлизаме във функционалното програмиране и FRP, но ще опитам по-простичко - като гледаме псевдокода във викито може да ни светне че за да постигнем т.нар. чисти функции трябва да извадим още два елемента - "integral" и "previous error".
Т.е. аргументите стават:

Връщаните след приключване са:

Във функционалното има един термин "memoization" - това е нещо като кеширане на резултата от викане на функция с цел ако при следващо викане аргументите са същите да се ползва кеширания резултат отпреди, вместо да се повтаря наново цялата сметка.
В нашия сложен пример с пид-а това значи че изчислението може спокойно да се прескочи ако оня списък с аргументите не си е сменил стойността.
Та в този случай даже виждаме че dt има голям шанс да е константа, ако се вика равномерно, но има допълнителен шанс за оптимизация, т.е. за спестяване на същинското викане/сметки - например в някакъв установен режим в който setpoint-а не се сменя, измереното примерно е също стабилно, грешката ще си е все една и съща, както и натрупаната интегрална част.
Колко това ще е практически използваемо зависи от конкретното приложение, но такъв подход спестява сметки - в най-лошия случай има подобна консумация на цикли, но е много вероятно да освободи въздух за други процеси поради намален брой повиквания.

Това изглежда малко излишно погледната за един единствен пид в контролния луп - но когато бъде погледнато в контекста на няколко последователно свързани компонента - примерно пид, лимитатор, филтър, писане в лог, парк/кларк, пвм драйвер... се появява следния случай:
В общия случай всички компоненти се викат на всеки тик на лупа, понеже всичко се сменя. В някаква ситуация лимитатора във веригата опира на лимит и изхода му спира да се променя, независимо че входа от ацп си мъдра. Поради това всички изчисления след лимитатора (филтър, ....) спират да се викат и да консумират време.
Има и друга екстра - когато изхода на някакъв компонент остане несвързан (примерно във веригата горе някой просто забрани pwm драйвера) то рънтайма може да блокира виканията напред по веригата - дори може да стигне до това да забрани ацп прекъсването. Това е реална ситуация когато например мотора бъде де-енергизиран - спрян от контрол.
Това обаче е доста дискутирана тема и има различни течения във FRP - и по-точно в това какво да се прави когат дадената верига (flow) бъде отново активиран, дали трябва да му се подадат всички пропуснати данни, или да се почва "на чисто"?

Интегратора в PI(D) не се слага за красота... Той се променя (сумира с грешката) при всяко извикване на пида (вътре), изкарва се нов изход, нова реакция на обекта от там нова грешка, нова сума и. Отчитайки факта, че PID се ползва обикновено в системи без устойчиво състояние шанса грешката да стане нула е нула... Тук с математика и dt може да направите магия но по надолу пиша защо според мене няма да стане (*).

Ами ако грешката е останала същата (заедно с другите параметри) ? Супер ама не: примерно ротора е застопорен, позицията не се променя, не се променя и грешката. Спрели сме да интегрираме и какво? Няма да има ново задание за скорост и ток... Супер, няма да се достигне зададената позиция...

Математика позволява да се опише процеса напред/назад във времевата линия (с подходящ модел) но в практиката се налага да се работи с множество променливи (смущаващи въздействия) на който не им дреме за програмистки техники за оптимизация.

(*) Още по лошо - ако викате PID през големи интервали от време (относително) губите динамичната резолюция (дори не знам дали се нарича така, пропуснати лекции по сигнали и системи). В смисъл почвате да работите с по-големи грешки и по-резки промени в изхода (по-малко битове). А ако интервалите са различни... Става страшно (въпреки, че математиката го позволява ?).

Пример за 'магия':

Model-based control:
http://www.mitsubishielectric.com/fa/products/drv/servo/pmerit/mr_j4/amp/machine.html

Заедно с основния control loop работи и модел на мотора/процеса. Това е нещо подобно на това което иска да постигне gicho (поне така ми се струва). Но почти 100% съм сигурен, че основния контролен цикъл е 'класически'

П.П: Лично аз разглеждам PID като модел (огледален?) на контролирания обект, чиято цел е да пресметне с колко и с каква 'скорост' да вкара енергия (със знак +-) в обекта. За това сигурно ще бъда порицан но какво толкова