ОК, за заетоста приемам че не съм те разбрал, но отново при този вариант джитер има, то джитер не знам дали е точно това което се получава при тебе, но д го наречем така. Съгласен съм и че ако е разликите във времето за изпълнение са малки, и той ще е малък.
То аз първо разбрах че е между 20-30 us след това разбрах че говориш за заетост а вече ми е съвсем ясно какво имаш в предвид, не че не чета но понякога човек чете едно а разбира друго

Миро, шивача си харесва неговия метър, дърводелеца неговия. Тази формула, която си я постнал е с презапасяване. Критерия за schedulability (за това дали някога ще излезе и български термин) който тя представлява не казва че ако U > 69.32% то съответния набор от таскове не са schedulable. Просто казва че под 69.32 % гарантирано са. Има и други критерии, които също гарантират schedulability и не са толкова рестриктивни като посочения критерий на Liu и Layland от 1973 г.
Освен това, да отбележим че стойностите тук са в проценти - относителни единици. И още нещо времето за реакция на системата (системата като цяло) трябва да бъде добре разчетено и транслирано към времена на изпълнение на таскове. Тасковете може да са schedulable, но системата да не изпълнява изискванията за response time нали?
А като казваш за изразните средства, поглеждал ли си какво може да се използва освен асемблер, С/С++ и препроцесора? Прави ми впечатление, че май само gicho го вълнуват тези неща. На мен винаги ми е липсвал начин за описване на интуитивното ноу-хау в ембедед С код. Въпреки че с времето човек усвоява стил, похват или добри практики ето и темата го показва - трудно е да ги споделиш и обсъдиш с колеги които работят в същата област. Няма обективен език за комуникация на тези похвати, какъвто го играе донякъде С сорса. Още повече няма компилатор за тях който да ги преведе и на машината.
Всъщност има, но и те имат своите недостатъци и не са разпространени.

Софтуера отдавна не е математика. И математиката отдавна не е абстрактно ниво което обхваща и покрива отгоре софтуера.
А по въпроса за ПИД-а.
ПИД-а всъщност е като дърводелски метър в областта на алгоритмите за контрол. Linear quadratic regulator, Pole placement control, Model predictive control, Linear–quadratic–Gaussian control ...

Хората отдавна не взривяват влакове

Не, в тази ситуация мотора ще напъва нанякъде с определен момент, може би лимита си по момент ще вдигне. Регулаторите ще стигнат на лимит (и ще сработи anti-windup-а) - това ще стане малко след блокирането на ротора и преходния процес.
Ако говориш за позиционния регулатор, и примера показва ситуация в която мотора е опрял в нещо безкрайно твърдо, то изхода на този позиционен регулатор ще е константа, но няма да е нула - по-точно ще е максимума, понеже setpoint и measured_value се различават - ти си искал на 10000 да иде, той е тръгнал от 0 примерно но на 9000 е ударил стената и стои там, значи error ти е константа 1000. Та тая error от 1000 си стои толкова и това вади задание към следващия (скоростния) регулатор да даде 1000rpm примерно, това кара токовия да напъне на максимален момент - ама стената си е стена и не поддава, та стоим така докато спре тока.
И това си е реални ситуация, която се постига лесно при достатъчно прецизна обратна връзка по позиция (демек добър енкодер).
В една утопична постановка това ще доведе до спиране на всички сметки и в регистрите на pwm-а ще стоят константи - докато не мръдне енкодера поне с 1 инкремент. Не е толкова важно това дали се случва често или рядко, а че това води до адаптация и автоматична оптимизация.
Нещо като tickless vs tick based кърнелите - и двете работят, с регулярния тик всички са съгласни, но tickless пести ток и реално всички вече го искат (вин 8 или 8.1 е първият от майкрософтските които са tickless, линукс горе долу по това време го имат и те, всеки смислен RTOS го поддържа също).
И докато при tickless е било по-лесно в смисъл че информацията за да се направи вече е била налична в АПИ-тата (таймаути на кърнел функциите, sleep и подобни), то за виканията е малко по-сложно поради това че все още няма стандартен начин тия връзки да се описват и параметризират.

Zdrav, прав си за тия неща - но както виждаш те не са дерт за голяма част от колегите. Има езици и стандарти - AUTOSAR и OSEK (ти сигурно ги познаваш по-добре от мен), както и моделните езици от типа на UML и SYSML.
Мисля си че за да се обърне внимание на тия аспекти голяма роля играе формалното верифициране - докато workflow-а в някакъв екип/компания няма изисквания за формално доказване и кара само на тестване, то има и място да се правят ръчни "шедьоври" (в смисъла на неща които не могат да бъдат повторени).

А се чудя на Миро сериозен ли е с онзи милион дето го предлагаше? Само аз ли съм останал с впечатлението че всеки софтуерен продукт се очаква да има стабилно, повтаряемо поведение? Не виждам как така ще има една кутия с 2 бутона А и Б, и две лампи - зелена и червена, и аз няма да мога да кажа (документирам, тествам) че винаги при натискане на бутон А светва зелената, а бутон Б светва червената? Как би изглеждало противното - в документацията на телфера примерно да пише "При натискане на "старт" телфера ще тръгне нагоре, ама може и да не тръгне - не можем да кажем кога ще тръгне, не е само ако е натиснат тотал стопа, има и други причини ама не ги знаем щото нямахме милион долара да дадем да ни разгадаят НАШИЯ код вътре. Ако искате телфер дето да тръгва при натискане на "старт" бутона си купете такъв направен с комбинаторна логика, нашите не са и не могат...".
Особено за човек който се бори с крипто и секюрити трябва да пределно известно че генератор на случайни числа се прави много трудно, и общо взето само с отделен, външен източник на шум. Иначе 1000000 устройства с този фирмуер ще правят точно едно и също. И пак да спомена че си мисля че това е търсен ефект, а не случайност дето да предполага риск за 1 млн. долара....

Нямах предвид крайно застопоряване. А такова което не може да се коригира само с P съставката. Добави и малка грешка спрямо зададената позиция. Особено ако P то е по малко от единица. Но понеже грешката е малка, съответно и коригирания изход е малък. Това е реална ситуация ('мек' регулатор) която се постига опитно. В тази ситуация те спасява викане на функцията на PID ( промяна в dt). Но все пак ако dt варира, особено към по-големи периоди, (това което предложи по-горе?) ще имаш и голям отскок на изхода (малко битове, малка резолюция). Заради това периодично си викаш PID-а и забравяш за подобни оптимизации.

Не ме разбирай погрешно. Като изключа примера с PID то съм съгласен с тебе, че има места където може да се спести извикване на функция ако няма промяна на входа. Примерно приемам пакет по сериен канал. Знам (има протокол), че трябва да е минимум 10 символа - мога да си позволя лукса да пропусна проверка за CRC докато не достигна минимума за валиден пакет. Също реална ситуация, даже мога да пропусна всички проверки ако видя, че адреса за който е предназначен е за друго устройство.

П.П: Мисля че разбрах какво си имал в предвит ?

От скромния ми опит със сервата, според мен сценарият ще е друг.
Драйверът има параметър максимална грешка от заданието - обороти или позиция. Ако по някаква причина излезе от рамките на заданието +/- максималната грешка, вдига флаг за грешка и изключва тоците към двигателя.

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

А онова с args е вярно логически, но разбира се не се подхожда толкова буквално - идеята отпреди 1-2 страници беше за "пропагандиране на промяната". Т.е. това дали 5-те входа на пида са се сменили не е необходимо да се търси и проверява чрез сравнение в предишните стойности, а просто да се регистрира дали някой от входовете (които са не просто променливи, а по-скоро събития носещи и текущата стойност) са се обаждали че има промяна.
Още по-точно, детекцията имало ли е промяна се прави още на ниво "запис на изхода" - имам предвид че ако ADC драйвера е първия компонент, и неговия изход "ulValCh0" отива като measured_value на регулатора след него, то в момента в който цъкне ADC ISR и се извади стойността от регистъра/фифото на ADC се прави там. Примерно адц хал-а има за цел да извади от ADCRESULT[0] регистър и да я сложи в "клетка" (буквално така им се казва в FRP - "cell" по аналогия с ексела) наречена "ulValCh0". Ние гоним да получим сигнал когато има промяна в ulValCh0 клетката - следователно елементарно лесно е да детектираме тая промяна в момента на прехвърляне от ADCRESULT[0] към ulValCh0 - точно преди да прехвърлим едното ни е новата стойност а другото е старото - и израз от типа на:

Кодът е псевдо и е така за да се види че детекцията не иска допълнителен буфер за стара стойност, разбира се това с проверката и сигнализирането може да се направи цялото на функция/макрос и да е generic за различни типове (темплейт).
Онова хипотетично "Notify_CellChanged()" вътре слага новата стойност и повиква 0, 1 или повече ресистрирани като интересуащи се от промяната (observer-и, subscriber-и). В примера един от тях може да е примерно компаратор на ниво, който да провери дали има условия да дръпне шалтера и спре поточната линия. Той реално има вход uint16_t примерно за monitored_value, и още един uint16_t за reference_value, и един булев изход "active" примерно.
Следователно той има работа само и единствено когато някой от входовете му се сменят - бидейки закачен към този "ulValCh0" той е регистриран да му викне функцията при нов, различен ADCRESULT, допълнително е закачен към g_CurrentLimitRefVal0 и ако някой смени нивото на токовия лимит, може би при запис на параметър от сервизен панел или ПЦ, той ще бъде извикан пак - така има всички условия да сработи своевременно компаратора и да шатне защитата веднага. Така се решават и проблеми с това "за да влезе в сила този параметър трябва да рестартирате инвертора...".

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

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

Тестването няма как да се измести от функционална верификация, но като се вземе предвид че тестването изисква време, че струва пари, че един проект се конкурира с други проекти за тестовите ресурси, тогава започва да се оценява хващането на проблеми преди влизането в лабораторията за тест. Да не говорим за излизане на полето. Хеле пък клиента да открива проблеми.

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

Аз казах, че това е формалата за идеална имплементация на алгоритъма. Демек не само че няма презапасяване ами е необходимо да се добави такова, за да се компенсират закъсненията от конкретния кърнел.
Не ми е известно да има други критерии и друг начин на оценяване. За RMA е това. Има други алгоритми, но те са друга бира.



Естествено че съм сериозен, това са основни неща в информатиката.
Наистина седни и прочети малко що е то комбинаторна логика и логика с памет. Това е като 2 и 2 в математиката... Абсурдно е просто да го коментираме.

Това съм го изтървал та ще се върна сега на него.
Понеже го въртим и сучем твърде дълго, дай да вземем един пример и да опитам да свърша работата - пробно, без да чакам милиона. Ако не успея си затварям устата и това би трябвало да е достатъчно удовлетворение
Има две причини да не може да "предвидиш" какво ще даде даден процес съдейки само по входните му данни:
- първо, ако не знаеш алгоритъма на работа на процеса - нямаш сорс, нямаш документация, нямаш модел, няма натрупани данни от тестове (или reverse engineering) - колкото и да зяпам няма как да хвана какво ще направи при следващото "почесване", или поне не и за 1млн само
- второ е ако знаеш алгоритъма, но не знаеш текущото му вътрешно състояние
Доколкото виждам твърдиш че софтуера е "непредвидим" (аз посмъртно не бих казал такова нещо пред клиент или началник, дори и да го мислех) защото имат вътрешно състояние.
Тъй, оттук насетне аз твърдя че в какво състояние е някаква програма е пределно ясно и гарантирано известно, стига да имаш началните условия и пълната история на всички външни стимули, които са го дразнили през живота му.
Единствената причина да не мога да изведа/изчисля състоянието към даден момент при тия условия е да ме цакнеш като кажеш че паметта на предполагаемото устройство не се чисти/инициализира и всяка променлива може да има произволна стойност в момента в който запали main()-a на кода който си ми дал за анализ. Това го класифицирам като рандом генератор, и е безсмислена ситуация - едва ли някой може да напише код който да може да работи без инциализация на променливите и да не се счупва от произволна стойност в тях.

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

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

Абе gicho, колко пъти да ти обяснявам че това не подлежи на дискусия?
Информатиката е такава каквато е. Или я разбираш или не. Само хора, които не я разбират могат да си помислят че функционалното програмиране е алтернатива. Алтернатива на какво??

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

И за пореден и надявам се за последен път ти казвам, че това не е тема за спорове. Недей изобщо да се опитваш да ми измисляш аргументи и контра аргументи. Аз не защитавам лично мнение, говоря ти за основни неща в информатиката. Може и да не ги описвам по най-добрия начин, но не са мои приумици. И няма значение дали на мен ми харесва или не ми харесва. Няма значение дали един софтуер е добре или зле написан. Ако изобщо е софтуер то той по дефиниция е НЕПРЕДВИДИМ. Ако беше предвидим, то всеки един компилатор щеше да генерира идеална последователност от инструкции, неподлежаща на по-нататъшна оптимизация. Както е с комбинаторната логика, там си избираш форма да кажем И-НЕ за хардуер и ти се синтезира схема която няма как да подобриш. И 100 компилатора да пуснеш и 100-те ще ти синтезират едно и също (ако не се бъгнат). Това значи предвидимост. Давам пример с хардуер, защото при софтуера както казах е Ъпсурд да говорим за програма използваща само комбинаторна логика. Съответно доколкото ми е известно няма нито един език да не използва памет, няма и нито един такъв компилатор. Няма и съвършен статичен анализатор. Няма и добър код уизърд, няма и куп други неща. Няма и как да има. Всички работят с някакви евристични алгоритми или някаква статистика или самообучаващ се изкуствен интелект. Това са все следствия от ФАКТА, че софтуерът е непредвидим по дефиниция, дори когато имаш сорсовете му! Казвам по дефиниция, защото ти можеш да напишеш нещо от сорта на hello_world() без променливи и то да е 100% предвидимо. Но за съжаление още никой не си е направил труда да направи специализиран компилатор само за hello_world приложения, правят само за истински софтуер

Шит, колко писания ми се загубиха, ама сигурно е за добро - ще бъда по-кратък.

Не виждам защо наличието на "памет" да води до неопределеност, или непредвидимост - просто още зависимост, която се добавя към нещата на "входа", които трябва да са известни преди да се "обходи" алгоритъма - т.е. стейта в текущия (предишния) момент. А стейта в момента t e зависим директно от стейта в t-1 и входните данни, а този в t-1 е получен от t-2 и входните данни, и така нататък до t0. Това дава тази предвидима стойност дори в момент t+89898932, стига да се знае какво е било в t0 и какво е идвало в t1, t2, t3, ....
А функционалното работи защото е на практика комбинаторна логика, която обаче е еквивалентна на stateful логика - това се постига чрез извеждане на стейта извън областта на функционалната логика - т.е. превръщайки го във I/O - вход ("стейта в текущия момент") и изход - "стейта за следващия момент".
Разбира се изхода "за следващия момент" може да се превърне в "в текущия момент" за следващото повикване - т.е. така се запаметява стойност и се прави "обратна връзка". Но има много аргументи защо такъв стил на представяне е по-качествен от "скрития" локален стейт - по отношение на качеството на кода на тези "стейтлес" алгоритми, които се ползват вътре, но и откъм скалируемост и поддръжка на кода (а и тестване).

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

Казано е от човек, който знае едно-две неща за информатиката.

gicho, не знам на теб пък защо ти е толкова важно да се връщаш назад към момента t0. Останал съм с това впечатление от няколко поста в различни теми в разстояние на няколко години тук във форума при които все натам отиваш. Как всичко някъде някога е започнало с ивент. Какво те ползва това?
Да, все някога програмата е стартирала и това също е ивент(събитие). И какво от това?

Ето един бисер който съм срещал из functional requirements на един проект:
"The software should provide interface to keep the software active."
Очевидно ако използваме една и съща дума "софтуер" за да говорим за различни проявления по различно време и погледнато от различен ъгъл, ще изпаднем в абсурдна ситуация.
Ето и едно изречение извадено от контекста от един от последните постове тук:

За някои хора, софтуера това са сорсовете, за други софтуера това е програмата заредена в машината и въведена в действие.
Аз поне разбирам функционалните терзания на gicho като първия вариант. Не става въпрос за сорс написан на функционален език, който преведен пряко ни дава байнъри код който се зарежда в машината.
Има софтуер, който описва друг софтуер. Най-простия пример е С препроцесора. http://pfultz2.com/blog/2012/05/10/turing/
И това което някой наричат стил на писане е всъщност неявен език за генериране на софтуер. Генериран в смисъл писан от човек де. Функционалната мода аз я виждам като доразвитие при което за "стила" е разработен специфичен език за описание, с който експлицитно се описва модел. От този модел просто се генерира друг сорс. Машина която познава метамодела, превежда на друг език. И чак след стопяването на този "syntactic sugar" или "model sugar" се превежда на машинен език(да речем тук се включва вече и С компилатор) и получаваме програмата, която се зарежда в машината.
Ако добавим още поне едно ниво на абстракция комбинаторната логика и автомата с памет вече не са двата основни типа системи.
Миро разбирам че със свалянето на нивото на абстракция се опитваш нееднозначно да определиш изчислителен домейн. Но все пак и ти каза - не говорим за частни случаи като hello_word(). При по-сложни задачи имаме не един и два домейна. И езика който е удобен за един от тях не е също толкова удобен за останалите, въпреки че може да се опитаме да минем само с един език.

Връщането към момента t0 не ми е важно в смисъла, който влагаш - просто това е доказателството че една такава система си с строго предвидима на база начално състояние, алгоритъм и входни събития. И за да е такава не бива да забравяме всички промени на състоянието - от момента t0 до текущия, за който говорим. Т.е. че стейта не е рандом число дошло свише, а си е съвсем логична стойност, дошла поради някаква дълга поредица от събития. И че независимо дали има 3 и 3млрд събития, които се клатили тая система, то тя ще стига все до едно и също състояние - може да се 10000 различни платки, пуснати едновременно за тест в голямо хале - стига да са една и съща "програма" (фирмуер), да тръгват от едни и същи начални условия ("конфигурационен" и/или "параметризиращ" файл), да им е здрава паметта и да бъдат обстрелвани с един и същи входни събития, то те ще направят абсолютно едно и също, поне в областта на дефинираното (специфицирано) поведение.
Ако има разлики то те показват че или има изпуснат стимул (събитие), в смисъла на неотчетено при анализа на влиянието, или сме излезли от зоната на комфорт на тази платка - т.е. теста е бил вид бенчмарк и стигането до резултат, различен от "предвидения" (специфициран, моделиран) значи че там е границата на работа на тази система (примерно клок на процесор или входен сигнал, скорост на пакети само че точно в тая поредица). Тия ограничения са заради физически лимити на системата - ако имаме процесор с безкрайна тактова честота и времето за реакция и произволна обработка клони към 0 пикосекунди, няма да видим проблеми свързани със състезания, а ако имаме и безкрайна памет няма да видим други ресурсни проблеми.

Функционалното е интересно защото се опитва да извади навън всичко което не е строго определено (детерминистично или е side effect)- в такъв смисъл там дори достъпа до паметта (mutable стойности, променливи в класическия програмисти смисъл) се превръща в I/O, неразличимо от достъп до диск примерно. Какви са предимствата на такъв подход не е за текущата дискусия, а и е въпрос на натрупан опит и обърнато мислене. Но целта е да има "математически" алгоритъм и "I/O"(памет) и тия двамата да не се обединяват.
Затова го виждам че минаването от "автомат" с памет (stateful алгоритъм) към комбинаторен, математически алгоритъм изисква автомата да се раздели на "чист алгоритъм" и "памет" (т.е. стейт). Контролът на стейта не е част от този автомат, в смисъл че може да се извади от класическата машина и да има "state controller" и изпълнителни алгоритми (action-и, или I/O-та които се описват най-удобно в императивен стил). Същите три действия примерно може да се използва по друг начин (да се преизползват действията на друго място), както и същия стейт контролер да клати 3 други, съвсем различни действия в последователност "1,2,3".

Бате Бонго пак не ме (до)разбра:
то ПИДрегулатор може да направиш и с операционни усилватели - един филтър от втори ред е точно това
идеше реч за критериите с които ще подходиш да решиш проблема.

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

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