Щом става дума за реактор, приемеме, че и системата е на ниво.
В прекъсването запомняме каквото трябва - примерно системно време, показания на нещо си и т.н. Ако трябва да има и история, това ще е някакво фифо или каквото и да е с подобно поведение, ако не - то може и в някои единични променливи. Навиваме будилника на треда, който знае какво да прави при тази ситуация ( предполагаме, че приоритета му е по-нисък от приоритета на прекъсването ) и излазяме от прекъсването.
Разсъненият тред чете какво са му написали на листчето ( ако трябва, докато изчете всичко може да позаключи това - онова ), свършва си работата ( примерно за 1-2 часа ) и ляга да спи.
Ако през това време получим ново прекъсване, данните вече ще са подменени с по-актуални, и будилникът ще е навит да звънне току след като Трендо реши да си легне. Той пак ще се разбуди, пак ще чете и т.н. Малко по-сложно ще е, ако по време на обработката се наложи да хвърли в коша каквото е направил до момента и да започне да го прави по друг начин. Ама пак става. Ако прекъсването дойде още докато Трендо държи заключени променливите от листчето, прекъсването ще се позабави малко, колкото е времето за едно копиране на данните на 'свое си' място. Надали това ще е фатално.
Сценарии много, няма описване ...

Максимално бързо се излиза. Все пак понякога се налага и да се помотаем докато минат сметките:

void ADC_IRQHandler( void )
https://github.com/SimeonSimeonovIvanov/FOC-Servo/blob/master/src/v0/foc.c

Има доста излишен кода но все пак:



Сметките са с float числа и минимална оптимизация. Изпълнява се за около 20uS е между 30% и 20% натоварване на процесора при PWM от 10/16 kHz (Fcpu: 168Mhz). Проблема е, че тока през мотора няма да чака да прочетем даден бит някога...

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

Колко малка въшка? 32 бита, FPU, 168МHz, STM32F4. Регулатор по позиция, скорост, I и Q 'ток'. В това време търкаля ModBUS RTU и му остава още ресурс. Ами това му е основната работа: да върти мотор. Изкарването на регулаторите извън основния такт на шима не е особено разумно. Разбира се може да се разбие на два такта но това пак ще влоши работата на регулаторите. За момента не изпитвам недостик на изчислителна мощ, проблем ще е ако искам да въртя ниско индуктивни мотори и/или достигане на високи обороти. Тогава ще се мисли за оптимизация. Стандартния подход е второ MCU или изнасяне на бързата логика в FPGA.

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

Е за това пък направо е ужас, при 168 мхц да стоиш 20 -30 us в прекъсване,... и ако семплираш на 10-на. Khz и той направо не излиза от прекъсване, това са хиляди инструкции, аз лично не бих приел такъв код нито от служител, още по-малко от подизпълнител.
Самият факт че казваш 20-30 us означава че тая сметка е доата волатилна като времв за изпълнение, от там презарвждаш pwm-а едно към гьотере, искаммда кажа че нямаш никаква переодичност. той може да си цъка на фиксирана честота, но моментите на презареждане са абсолютно случайни.

А между другото, токът ти през мотора чака цяла вечност ако си на 168 Mhz няма изобщо никакво значение дали тая сметка ще е в прекъсването или извън. Влизане излизане би следвало да става за нано секунди, срещу сметка от 20 us.

Това какво ще приемете не е от значение. Има достатъчно информация по въпроса в мрежата. Вярно е, че вероятно мога да правя сметките двойно по бързо ( 10us - половин 'вечност' ). Идеята ми беше, че правило от сорта 'никакъв код в прекъсване' е меко казано далеч от реалността.

При 10 kHz има 10 прекъсвания докато се достигне 1ms. Или 10 такта на PID-а ( с обновена стойност на шима). Или около 1-5 ms. преди тока да е пратил транзисторите във вечните силициеви полета.

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

Ами първо може да прочетете какво съм писал. Не 20-30 uS a % 'заетост'. Продължителността на прекъсването е напрактика постояна (~20 uS) с период 60/100 uS. A какъв е проблема с милисекундите ? Това са параметри на процеса който се управлява а не време което процесора стои зает. Отново - няма никакво значение какво ще приемете. Просто не съм го измислил аз: STM32F PMSM single/dual FOC SDK v4.3 - STMicroelectronics - комерсиалния аналог. Старата версия със сигурност работи на същия принцип. За новат (4+) не знам.

Дали кода ще е извън или вътре в прекъсването винаги ще трае определно време и винаги трябва да се изпълни през точно определено време (период на PWM). Точно това е уловката: ако може да е в прекъсването човек си спестява сумати главоболия. Не, че е хубаво. Реалност.

Би могло ADC (синфронизирано с PWM) през DMA да подава актуалните стойности към буфер. И извън прекъсването да се прави сметката. И отново ще имам заетост от 20% за сметка на по-трудно синфронизиране с периода на таймера. Просто сметките по мотора са по важни от спора вътре/извън прекъсването. Има проекти с OS и смектите са правят в task. Но това е допълнително натоварване и на без това заетия процесор.

уф намери откъде да черпиш идеи. Много от библиотеките на ST са еталон за това как не трябва да се правят нещата



Мда класически пример за мазало

Има чисто практични и чисто теоретични правила, но по всички правила прекъсванията трябва да са максимално прости.
Практичните правила се разбират след като почнеш да поддържаш различни проекти, да ги усъвършенстваш и т.н. Особено в по-съвременните контролери, където за едно прекъсване на една периферия може да има 1000 причини. И никак, ама никак не е добра идея в такова едно прекъсване да се бъзикаш с друга периферия, която също да работи с прекъсване и то също да има 1000+ причини. Просто това е рецепта за бедствие, кодът се оплита като свински черва и не се знае ако бутнеш някъде къде ще избие. ТАКА НЕ СЕ ПРАВИ!

Относно теорията... Има различни алгоритми/модели за организация. Но най-простият и най-често използваният е RMA (rate-monotonic algorithm). При него нещата, които се случват или могат да се случват най-често трябва да се обработват с приоритет. Няма нужда да е ОС, може bare metal и обикновени прекъсвания с приоритет. Трябва да се запомни само, че приоритета на прекъсването трябва да се задава според честотата му, а не според това колко ти е важно.
Лесно е за разбиране, примерно нека има две задачи - едната може да трябва да се изпълнява всяка милисекунда, другата всяка секунда. Очевидно тая, която е с честота 1ms трябва да е с по-висок приоритет, щото ако се застъпят по добре да се забави задача за 1 секунда с 1 ms, отколкото обратното. В интернет има много добри обяснения... пак казвам няма нищо сложно, няколко страници с обяснения и сметки са и няколко простички правила като примерно защо cpu usage при тая организация не бива да е >69% (освен ако не искаш гърмящи реактори...)

Та от гледна точка на теорията, да може да се ползват прекъсвания за черна работа. Това е един вид хардуерен кърнел. Стига приоритетите да се сетнат правилно има шанс да работи. Но има един генерален проблем и това е че *всички* задачи трябва да са в прекъсвания. Ако се наложи обработка на някаква задача, за която няма хардуерно прекъсване целият модел отива в киреча... (реакторът ще думне, мога да ви го обясня по-подробно защо).
И за да може да се обработват всякакви задачи (не само такива с периферии) решението е всичко да се измести на по-долно ниво в евентуален кърнел. Кърнелът гарантира изпълнението и/или лимитите т.е. предварително можем да кажем проца става или не става (та да не думне реактора).
И като казвам изместване, то при много от OS-те изместването е доста сериозно, включително същинското прекъсване. Някои разбиват на ISR и DSR (interrupt service routine и delayed service routine). В ISR само се изчитат и/или чистят флаговете и се излиза. Същинската обработка се прави в DSR-a, който обаче кърнела решава кога да пусне. Иначе казано DSR-те са един вид хардуерни нишки, а пък кърнела има тотален контрол и върху софтуерни и върху хардуерните задачи.

Та така, ако се гони практичност, ако се гони надеждност, ако се гони универсалност то върха на сладоледа е супер прости ISR-и. Това работи на всякакви платформи и с всякакви задачи/приложения. Всичко останало е някакъв компромис

Това което е написал @s.ivanov, е точно това което трябва да се прави в неговия случай.

И аз имам мои у-ния на мотори с далеч по слабо dsp 16bit/30MHz и 95% от сметките (int) Clark,Park, ... са в прекъсване (28кHz), като натоварването е <60% (имам запас за още сметки).
Другите: комуникации, индикации .. са с нисък приоритет прекъсвания.

За всяка задача може да има различни решения - важното е резултата да е добър.

Трябва да се прави така защото?

Защото няма друг начин - ясно ?

За всяка стъпка на pwm-а трябва да измериш тоците (и тука си има особенности) и да сметнеш вектора на тока и след което да коригираш вектора на- напрежението!

В мое случай имам и sensorless у-е, т.е разчитам изцяло на вектора на тока за да знам позицията на ротора.

За печатане на етикетчета - си пиши софтуера както искаш (ОС-ове и т.н концепции)!

Има, ама някой трябва да чете и да мисли...



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



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

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