Не... Аз когато изказвам лично мнение предупреждавам

В случая говоря за категорична (без капка съмнение) и груба грешка. И изобщо не пресилвам. Такова едно мазане е абсолютно недопостимо, защото нарушава не един или два принципа.

№1
Като почнеш от това как се разделя код, щото Иванов е взел едни сорсове и ги е модифицирал, при това без да документира какво е взел и къде е мазал. Това значи че утре ако ST пипнат нещо то няма как лесно да се разнесе. Хайде, те ST не са от тия дето чистят бъгове или си подобряват сорсовете. Но въпросът е принципен, за да се поддържа чуждия сорс от неговите автори - не трябва да го пипаш. Твоят код си е твой, но за целта не го слагаш на чуждо място. Всяка жаба трябва да си знае гьола, съответно правата върху сорса, задълженията за съпорт и т.н. И не на последно място разделението на труда, т.е. сорсовете трябва да са отделно за да могат да се поддържат с отделни специалисти. А не да трябва гений който хем пише прекъсвания, хем управления на двигатели, хем не знам си какво...
Просто в софтуера си има граници, къде трябва да свършва библиотечния код и къде започва твоя. И тия граници трябва да ги усеща всеки един програмист. И не само да ги усеща ами и да ги уважава.

№2
Секюрити, права и т.н. Такова мазане е възможно щото Иванов не го интересува секюрити, не го интересува правото. Що не вземе да си шляпне кода в някое прекъсване на майкрософтски драйвер? Ще вземе, ама един друг път щото нито сорсове ще намери, а и да намери после така или иначе няма кой да му подпише драйвера. Същото е и с всеки OS, който има някакво секюрити. Ако има security measurements с TPM просто забрави да пипнеш и един байт (било то код било данни). А дори и да няма, то са адресни пространства, права за достъп...

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

Сигурно има и още, но мисля че и това е достатъчно

Миро,

по точки:

1) 'Иванов' си е писал сорса гледайки PDF с теория, сорсове от AN и аналогични проекти от Интернет. 'Иванов' си е сглобил проекта сам но все пак не е измислил топлата вода. Кода/проекта е на 'Иванов'. Не на други автори (copy/paste).

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

Само за едно си прав: има голямо мазане в проекта. Заради това е в github. Все пак основната част от FOC е приемливо зле.

По 2) и 3) - това са проблеми по които ти работиш. При мене най-важното е управлението на тока през мотора. И да няма OS, няма многозначност - единствената задача е мотора другото е бонус.

" Що не вземе да си шляпне кода в някое прекъсване на майкрософтски драйвер? " - това подсказва нивото на дискусията. Ниско... И от техническа гледна точка и от личностна. Нищо чудно че TGI изчезна от форума.

Имам спомен че причината да спре да пише във форума беше друга...

Миро, имах подозрение, че говорим за различни неща, сега вече съм сигурен.
Всяка жаба да си знае гьола, но ако жабата си седи все в средата на гьола, никога няма да знае къде са границите му. Няма да ги усеща и уважава. Трябват и хора които не се страхуват да стъпват когато се наложи с единия крак от другата страна на границата. Интердисциплинарността трябва да се насърчава щото иначе ще си отгледаш бройлери, които всяка дискусия я започват с "it's not my job" и "works for me".
Без лоши чувства, но аз отдавна не обсъждам тук в темата конкретния пример на s.ivanov от втора страница. Опитах се да опростя примерите за да бъдат по-разбираеми. Но ти с тези Майкрософстки драйвери вероятно искаш да повдигнеш интелектуалното ниво на темата.
И благодаря че в точка 3 си включил и изключението 'супер елементарен' многозадачен модел.

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


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

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

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

Заради undersampling-а - като проверяваш GPIO-то през даден интервал, теоретично можеш да пропуснеш ако може така да се израза, шум с продължителност горе долу колкото е интервала на проверка. Виж като имаш детекция на гличове тогава можеш да си оставиш контролера да спи през целия интервал и да не пропуснеш никакви промени.

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

Миро,

само едно не ми стана ясно: какво общо има ST с проекта? Изключвам контролера. Не ползвам тяхната библиотека за мотор контрол. Дадох ги като пример. Предполагам не става дума и за CMSIS. Ще се радвам ако споделиш какъв подход би предприел за да решиш подобна задача.

Защо ползвам прекъсването: таймер генерира центриран PWM за трите фази. В средата на периода се стартира ADC с няколко Injected канала. АДЦ генерира толкова спорното прекъсване. Уловката е, че текущата прочетена стойност на тока да мине през векторните преобразувания, ПИД регулатори и се подава като нова стойност на ШИМ (силно препоръчително за следващия период).

При ниски скорости пък ЕДН на мотора е ниско, тока расте относително бързо и отново трябва светкавична реакция. Както споменах има и DTC контрол. Грубо казано се ползват софтуерни компаратори който определят кои транзистори да се включат. Ако при FOC се говори за преходен просес от 5-10ms (IQ съставящи) то при DTC става под 1ms.

Сега малко наизуст: при 3000rpm и 4 полюсен мотор, синуса който описва тока в намотка е с период 5 ms. При 10kHz имам 50 периода през който да променям стойността на шима за да мога да опиша новия ток. Добави и факта, че на регулатора му трябват около десетина периода за интегриране. Добре поне че FOC се грижи да преобразува образа на тока в две DC съставки (поле/ток). Позволявам си малко условно да опиша картината но горе долу е това. Трябва в рамките на всеки период да съм завършил сметките и да съм подготвил новите стойности на запълване.

Дори да изкарам кода извън прекъсването (нещо което ми се иска) пак трябва да гарантирам, че процеса ще протече в дадения времеви интервал с 100% приоритет.

Относно OS на високо ниво: не случайно по-горе споменах, че за тях се правят RT ядра който гарантират на процесите необходимите интервали (LinuxCNC / TwinCAT за Windows). Със сигурност качеството на кода и алгоритмите е на многооо по-високо ниво от моя но факта е, че има проблем. Сега предполагам си съгласен, че не върви да подкарвам LinuxCNC или подобна система на STM32F407 само за да спазя добрите практики. Иначе има адски много неща който да оправям по проекта и повярвай прекъсването е последното.

https://infosys.beckhoff.com/english.php?content=../content/1033/tcsystemover/html/tcsystemover_pcctrlrt.htm&id=
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RealTime


Как последното да стане максимално лесно и гарантирано без OS или друг засукан механизъм за синхронизация на задачи?

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

Миро, аз в тази тема не говорех за писане върху чужд код, а за създаване на малка система от нулата. Специфична, мислена, с ноу-хау събирано с години.
И аз като s.ivanov се чудя как ST и техните библиотеки за шир потреба се включиха в разговора. ST имат интерес да продават микроконтролерите си. Вероятно пишат и софтуер който не е за масовата публика, но май тук не става въпрос за такъв

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

Нищо специално, просто ползваш техен код доколкото разбрах.


Би било несериозно да ти кажа как бих имплементирал алгоритъм който не познавам в детайли. Освен това аз също не съм еталон. Както казах моята сила е в това че познавам и мога да коментирам много решения. Демек както не всеки футболен коментатор не е задължително добър футболист, така и аз не казвам че съм най-добрия програмист
Между другото (няма връзка с темата) STМ-четата има доста гъвкав хардуер. За сравнение ще опиша как правя управление на стъпкови двигателчета. Там обратни връзки почти няма, т.е. има по напрежение, но то е друга бира. Токът се задава/ограничава с DAC, така че да се получи колкото се може по-гладка синусоидата. Проблемът е силно променливата скорост, реално постоянно си в някакво ускорение и времената са много променливи. Една стъпка може да е много дълга а може и да е само 100-на uS. Съответно времената за смяна на фазите или пускане на DAC-ве е желателно меко казано да са прецизни. За щастие хардуерът е добър и си става напълно автоматично. И фазите се клатят по таймер и DAC се пускат по таймер. От софтуера се иска да смята времената, но винаги има няколко стъпки напред готови, така че се работи спокойно.
Така по хардуерен път се спестяват доста софтуерни главоболия, най-малко не се налага мазане по прекъсвания
По подобен начин са и измерванията, понеже се налага да се мерят доста неща и то по-важни от самия двигател. Но пак няма прекъсвания, няма дявол. Просто ADC са достатъчно бързи и с овърсамплинг и DMA. Пускаш и заебаваш. DMA-то пише по един и същи адреси, така че като ти трябва някаква стойност, просто си я вземаш от паметта. Прекъсване има само ако стане нещо фал.

Относно софтуерните решения, всеки си изработва техники за синхронизация и техники за многозадачност. Може ти сам да си ги изработиш. А може и да ползваш готови. Всъщност един RTOS е точно това - техники, които може (и трябва) да ползваш.
Ако ми кажеш какво точно ползваш като OS или друго можем да коментираме конкретика. Но при всички случаи ако трябва примерно да синхронизираш ADC измерване с някаква друга задачка ти трябва примитива за синхронизация. Ако не знаеш с какви примитиви разполагаш, то дет се вика накъде си тръгнал изобщо?

Относно големите OS, там номерът не е в RT разширенията повярвай ми. Идеята на големия OS е да работи с много софтуер, разбирай и с калпав софтуер. Затова в кърнела на NT-то дето цитираш се ползват неща като random boost, демек през случаен интервал се пуска случаен процес без значение на неговите приоритети и т.н. Така дори kernel mode драйвер може да увисне и да не получи управление със стотици милисекунди докато някакво абсолютно случайно лузерско приложение се мандахерца. Естествено това ебава мамата на всякакъв real time... Но така е като имаш и китки и фитки на едно място;-)

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

Миро,

не ползвам OS или някаква форма на многозадачност в проекта. Изкушавам се, да сложа но не виждам как конкретно ще ми помогне с тази задача. Тук е място да направя вметка, че в ученическите години съм писал супер малък и семпъл кернел за AVR (atmega) изцяло на Асемблер. Стигнах до работещ (със сериозен проблем) вариянт на malloc / free и реализирах списъка на задчи като свързан списък. Това го пиша за да разбереш, че нямам нищо против OS, напротив даже ги харесвам.

Относно RT и големите OS в горния пост съм дал линк. Все пак:

"Windows NT and Beckhoff Realtime Kernel Extension

As Windows NT is not real time-compatible, the operating system is extended for automation tasks: such a real time extension is the basis for TwinCAT. With a background of more than ten years of experience with PC software solutions for the PLC/NC and more than ten thousand installations under DOS, Beckhoff has developed a proven and independent real time extension for Windows NT as the basis of TwinCAT and has harmonised it with Microsoft as a system partner. In a cyclic mode of operation, 64 tasks are executed with priority control, preemptively and deterministically with a maximum of +/- 15 µs jitter."

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