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



Не се очаква от кого? Клиентите винаги искат повече и по-евтино и по-качествено...
Разпръскването на функции в отделни модули понякога е решение, а понякога толкова голям уй колкото не може да си представиш. Често давам примера за синхронизация на два обекта по несигурен канал. Уви, нерешима задача... Дори да не се натресеш на фатален проблем, то синхронизацията и изграждането на мултипроцесорни системи винаги е по-сложно, отколкото синхронизацията на отделни нишки.


Не виждам каква е връзката... Това което се "заобикаля" са неща като random boost и други техники за системи без real time. Нормално е тези техники да не са подходящи за real time приложения... Но ако си мислиш, че писането на код в прекъсване ти прави с нещо системата по-подходяща за real time то явно говорим на различни езици...

Така, начи пичове, яко ви липсва способността да формализирате задачите. ОК, ще го направя вместо вас: как да направим така, че хем да хванем всички събития (прекъсвания), хем да направим необходимите тежки сметки за всяко от тях? Един вид, да "разтегнем времето" в прекъсването.

miro_atc,

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

Имам PLC контролер изпълняващ ladder diagram. Писан е първо за ДОС но едновременно с това да работи и на ATmega. В началото вместо LCD пoлзвах аналогов телевизор. Смених поне няколко корено различни процесора и платки. Не виждам проблем (8/16 бита). Самия редактор на ladder има версия за DOS и Windows (win32api). Win версията има два различни подхода в редактирането графиката и самия кернел. Изобщо не се притеснявам да портвам код или дори да го пренапиша. Даже редактора може да работи директно на контролера без PC. Това стига ли? Само да вметна, че електрониката/програмирането са ми хоби. Работя в областта на автоматизацията и ползвам 'купешки' модули. Така, че нямам твоята драма с 'добрите' практики. Радва ме чужд 'красив' кода но съм готов личния да е не оптимален.

https://github.com/SimeonSimeonovIvanov/RS485-Channel - има линк със снимки на модулите. Давам си ясна представа, че в форума има много по-добри неща/хора но това е което мога. Обръщам внимание само на полезната информация, другата не ме засяга.

На прекъсването може да гледаш като на информация. Информация, че е настъпило някакво събитие и в резултат на това може да трябва да се свърши нещо. Да "разтегнеш" както му казваш или по-добре казано да се изпълни някаква "задачка".
Софтуерът като цяло е сбор от "задачки", които трябва да се изпълнят. Съответно ти като програмист ползваш един или друг модел за "многозадачност". Дали ще е RTOS дали main loop дали нещо друго няма значение. Просто проца в даден момент може да изпълнява само по една задачка, затова ти трябва да си изградиш някакъв тертип на работа (или да вземеш готов) така че задачките да се сменят/редуват и нито една да не остане неизпълнена.

По друг начин казано - имаме многозадачност, демек набор от процеси/нишки. Прекъсванията са събития по които дадени нишки могат да искат да се синхронизират.
Прекъсванията не са единствен източник на събития, т.е. на синхронизация подлежат много неща. За реализация на синхронизация може да имаш на разположение най-различни синхронизационни примитиви. Това са евънти, семафори, мютекси, опашки и т.н. и т.н. докато стигнеш до най-обикновен бит от паметта.
Предполагам искаш по-голяма конкретика но за целта трябва да конкретизираме какъв модел на многозадачност ползваш и с какви синхронизационни примитиви разполагаш
В общия случай прекъсването е свързано с някаква периферия, която се ползва от някой. Този някой по някаква причина трябва да изчака джелязото. И за да не чака във while(){} и да блокира всичко чака за евент, а пък ISR-a има грижата да генерира този евент когато му дойде времето..


По снимки не мога да се ориентирам за софтуера, от кода който си качил виждам няколко сорса по 100-200 реда. Предполагам е повече, но аз говоря за много, много повече. Да кажем проект с поне 1млн. реда код да видим как ще мажеш из прекъсвания и по който работят няколко човека и как после ще го портваш на различни платформи. Не става, повярвай ми! За мен тези неща са ми професията, може и да не съм голям професионалист ама не ми е и хоби

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

miro_atc,

явно стигнахме до мерене на код. Жалко...

Отностно PLC-то (което правилно си забелязал не е качено, в github има 200 реда free...)

PLC (MCU): 302 KB | 9.532.0 реда
WIN IDE: 605 KB | 19.000.0 реда
DOS IDE: 194 KB | 7.780.0 реда

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

Съгласен съм по принцип с тебе и Тони но не и относно конкретния пример който дадох с мотора. Въпроса не е дали кода е вътре или вън от прекъсването. Длъжен съм на 101% да гарантирам изпълнението му на време, синхронизирано с измерването. Нямам причина да се мотая другаде. Каквото и друго да прави процесора мотора е най-важен. Няма анализи от сорта ако кода станел 1М реда... Ако мога и не жертвам някой друг параметър бих го правил извън прекъсването. Целта ми беше да вметна, че правилата не са само бели и черни, има и сиво. Но явно почнахме да се засягаме на тема умения... Това е тъжно.

Както казах трудно може да се убеди някой в нещо коети не вярва, няма никакъв проблем да го изпълниш със същите 101% сигурност и извън прекъсването, а моткането е в твоитв ръце, ако не го позволиш няма как да се случи. Ако имашни други подобно прекъсвания, и код while (jesus come)... да има риск кода ти да не де изпълни навреме, но както казах това е в твоите ръце.
Не мисля че става въптос за мерене на нещо, Миро казваше чв ако имаш 1 млн реда код и ти се налага и да мигрираш, пофобни решения носят много негатив.

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

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

stefan63,

разбира се, че може извън прекъсването. Даже както споменах по горе има проекти които го правят. Има и хардуерни начини да ускориш това. Но накрая има ~20uS работа с период от 100 uS (80us свободни) синхрони със сметки и измерване обновяване на ШИМ, процес трябва да гарантираш. Вън или вътре - трябва да си навреме. Даже колкото си по бърз (DTC контрол) по-добре. А бърз значи да намалиш допълнителните механизми за синфронизация при условие, че работиш извън ISR. Все още мога да си позволя да е вътре в прекъсване при което процесора може да обработва спокойно и други задачи извън критичния код/прекъсване.

А float беше само намек колко много може да се ускори процеса така, че да няма драма с вечността от 20 uS.

В проектите който ползват FPGA за FOC работят супер бързо. Налага се синхронизация, нс отделните логики при което временат са от порядък на 2uS. Понеже не съм правил подобно управление не смея да навлизам в детайли който ми се губят.

Тоест работиш с период 100 мкс и всичко трябва да се преизчисли и опресни в тоя период. При тая постановка дали се смята в прекъсването или извън - май няма голямо знчение. Има разлики в дебъгването, вероятпо.

Точно така е. Лошо става когато искам по висока честота на ШИМ-а (обвързано е с 'резолюцията' и реакцията на тока през мотора).

Ща щастие в режим на дебъг таймера може да се стопира автоматично така, че да няма пушеци. За тестове с мотор много помага сериен порт и аналоговите изходи на контролера. Когато имам съмнения стигам до 200W лампа (мотора е 60W) която разделя кондезаторите от моста. Също кода се тества отделно с PC програма която чертае графика на отделните модули (Clark, Park, SVPWM).

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

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

На прекъсването може да се гледа като на хардуерен механизъм за control flow. Прекъсването може да гарантира времена за реакция по-малки от тези на RTOS качена на същия хардуер.

RTOS гарантира времена за реакция без да е необходимо да познаваш прецизно времедиаграмите на процеса или обекта, който мериш, или който контролираш. Или ако процеса няма ясно изявени периодични събития(юзър интерфейс, клавиатура, GUI, TCP/IP stack и пр.) Достатъчно е да имаш статистическа информация за максимално допустимото време за реакция.
Но ако пък предварително при калъпенето на системата, нейното поведение е известно и определено. Ако приоритетите на задачите са твърдо зададени и няма конфликти. Не виждам защо да не решиш задачата така както го е направил s.ivanov. Какво като при 200 MHz клок, 20% от времето процесора е в прекъсване. Кое си требе оно си сака.

Няма добри практики, които да са валидни за всеки при всякакви ситуации. Ако има такива то първо попитайте на каква цена идват.

Така, така...

Аз в прекъсване пиша нещо което трябва да се изпълни в точно определено време.