Zdrav, май не разбирам съвсем какво ме питаш.
Вложените прекъсвания (в смисъл като в 68к) са си прекъсвания като всички
други.
Нормалният подход е обработвайки прекъсването примерно да вземеш байт,
дето влиза, да го сложиш на опашката и айде обратно. Може и да предизвикаш
(да си пожелаеш или както става в съответната среда) и превключване към
даден таск - и това е, rte (rfi, rti... А прекъсваемият код си яде байтовете от опашката,
цеди ги по протоколи и т.н. Нищо ново и революционно, тия неща се практикуват
повече десетилетия, отколкото някой от нас се е занимавал с тая работа.
Ей сега, в последното нещо, дето пуснах за своя употреба, има примерно два
PS2 интерфейса. И двата предизвикват прекъсване на всеки clock, и IRQ
handler-ите sи сглобяват байтовете и ги слагат на опашка (или изкарват навън,
според моментната посока, която и при мишката, и при клавиатурата си е
повечето време навътре, естествено). И никой в система със сума ти прозорци,
дискове (мрежата предстои да я пусна тия дни ) и т.н. не забелязва и
не пречи.

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

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

Цецо, това с празния main loop и всичко в прекъсванията току го прави
някой и му се разминава, защото хардуерът му 10+ пъти overkill, ама
не е работа.
В прекъсванията се върши само неотложното - другото в прекъсваем
код. Може би има много прости системи, които почти нямат друга работа,
освен да реагират на прекъсване и толкова - но обиковено има повечко
работа.
За колко микросекунди обработка на прекъсването става дума? От някъде
нагоре - 10-ина, за много малки и бавни системи до към 100 микросекунди - процесорът
няма работа маскиран да обработва прекъсване, не е ли очевидно?

Не познавам прекъсванията на 68К. Под вложени прекъсвания имах впредвид ситуацията, когато влизайки в прекъсването след като свършиш някаква кратка неотложна работа по обработката или пък веднага при влизането разрешаваш прекъсванията отново без да се връщаш веднага от процедурата. И продължаваш с обработката на събитието. Така просто прекъсваш по-ниско приоритетните задачи и пренасочваш процесора към друга по-високо приоритетна. Тъй като прекъсванията са разрешени, по-високо приоритетните могат да те прекъсват и така латентността им не се увеличава драматично. Това както го описвам се отнася за ARM7. Там веднъж имаш основна нишка в основната врътка. Втори път имаш IRQ и трети път имаш FIQ(Fast IRQ). Освен това когато разрешаваш прекъсванията в IRQ хардуерния контролер на прекъсванията приоритизира заявките като до завършване на текущата процедура забранява всички прекъсвания със същия или по-нисък приоритет. Това беше конкретно което имах впредвид. В момента калъпя една такава многозадачна организация.
Но по-принцип бях учуден, че генерализираш нещата така - при прекъсване само взимаш байт/ове, вдигаш/сваляш флаг и излизаш. Има и други ситуации и други възможни организации.
А пък ако някой се размотава във прекъсване, когато има изискване за ниска латентност неволята няма да закъснее да го научи. Но и такива хора има. Ето сега при нас пресен случай - дадохме на един боец да ни напише фърмуеър за една проста джаджа - PIC16, два бутона, дисплейче и серийна комуникация на 9600 бода. И каквото и да прави не го докара до там че времезакъсненията на клавиатурата и дисплея да не му се намесват в серийната комуникация. Надникнах в дизасемблирания код и кво да видиш в процедурата за прекъсване на UART-a просто влиза взима байт и излиза при това дори няма кръгов буфер ами взима байта в една и съща променлива?!?

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

Това е най-кривият вариант на многозадачност, който може да бъде измислен.
В момента, в който разрешиш прекъсванията, обработката на прекъсването е
приключила, все едно дали си минал през инструкция за връщане или не.
Сменил си контекста - по най-кьопавия възможен начин. Няма никаква причина
да се прави така, освен незнанието как да се направи свястно. Освен
всичко друго при тоя вариан нямаш контрол над дълбочината на стека (т.е. колкото
и дълбок да е, при достатъчно натоварване ще се препълни).

При 68к вложените прекъсвания са вложени - 7 нива. При някои други процесори
има по 2 и т.н. Общото е,че по-високото ниво може да прекъсне обработката на
прекъсване от по-ниско (не и обратното, и не и при равни нива).

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

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

Ами превключването на контекст си е превключване от една задача към друга,
разни системи, разни варианти, но в крайна сметка има поне по един стек на таск
(в DPS са два - user и system), в по-големите системи (от 68020 нататък във времето
за мене) има и отделен стек за обработка на прекъсвания - това е така в DPS и
за PPC.
Как от прекъсване от даден хардуер да превключиш към даден таск - варианти
много и различни. Обикновено стига и сигнализиране с флаг (т.е. асинхронно, ако
синхронизирането може да бъде такова де ), но ако трябва да е "бързо", самият
IRQ handler може да заяви (на глобално място) кой таск иска да е следващ и може
да предизвика прекъсване,което да превключи таска (в PPC decrementer е подходящ
за целта).
Но тук вариантите са безбройни.
Дори и този, който ти описваш, е използваем при определени входни условия; но от
това не става по-добър де. Не само липсата на контрол върху дълбочината на
стека, ами и самата посока на мислене отива в забатачена посока - например отде
контекст за тоя код, дето не е свързан с нито едно от прекъсванията и т.н.
Не познавам в детайли чуждите RTOS-ове, та да мога да разкажа за
тях, но сигурно други тук ги познават. Аз съм написал няколко такива (3 ли, 4 ли бяха - за 6809
преди 20+ години - това ми беше първото, за 68020, за 68HC11)
за свои цели, и разбира се DPS (за CPU32 и PPC), което е пълна ОС, и подходът ми
е бил горе-долу все такъв.

Това, което в крайна сметка е важно, е ниската латентност на прекъсванията - което
изисква да стоим там по-кратко (пак, обработка на прекъсване има докато
е маскирано, след това каквото и да следва в сорса процесорът може да е където си
иска обслужвайки ново прекъсване, така че за бърза/предсказуема реакция след демаскирането
не може да се говори).

Контекст ще се намери. Това го компенсирам с подходящо написана процедура на таска. Всъщност цялата процедура я правя като при влизане в нея проверявам една глобална променлива g_ulTaskState. Тази променлива определя входната точка за процедурата. Най-често там се полира някой флаг или таймер и ако още не е настъпило събитието се излиза веднага. Примитивно, но все пак аз не пиша пълноценна ОС просто многозадачност върху "bare metal". Този тип таскове не са критични откъм латентност и разрешаването на прекъсванията не ги бърка. За задачите с високи изисквания към латентност имам FIQ. Хардуерно при ARM той е с най висок приоритет и FIQ не се маскира при влизане в IRQ. Тоест няма нужда да го разрешавам ръчно. Отделно имам още едно ниво(под FIQ) където използвам IRQ вектори, но не разрешавам прекъсванията. Тези процедури както и при FIQ естествено гледам да са максимално кратки. За това спор няма и никога не е имало. Но въпроса е и колко кратки. Дали параноично бързо да излизаме от прекъсване или да си направим елементарна обработка на кръгов буфер. Високо приоритетните прекъсвания ги слагам да не са спорадични, а винаги са на някакъв определен интервал от време. Определен или от таймер или от външно периодично събитие с което трябва да се синхронизира някоя задача.
Не виждам чак кой знае какво забатачване при такава организация. Особено когато имам що годе определени ситуации, както предполагам е при повечето малки системи. Предварително са преценени приоритетите и дълбочините на стековете и няма динамично преразпределение. По-ниско приоритетен таск никога не прекъсва по-високо приоритетен. И високо приоритетните никога не заемат цялото процесорно време. Ако това се случи. Ще изгърми watchdog-a, който се сритва единствено и само в най-ниско приоритетната задача, която съм сложил в main.

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

PS:Надявам се не звуча заядливо или самовлюбено.

> Дали параноично бързо да излизаме от прекъсване или да си направим елементарна обработка на кръгов буфер.

Ами ако под обработка имаш предвид да сложиш нов байт в кръговия
буфер и да бутнеш веднъж напред write pointer-а, не виждам нищо лошо.
Няма къде другаде да го направи човек. Както и да инициираш примерно
пращане на XOFF, ако премине някакво ниво на напълване. Оттам нататък
вече би ми се видяло в повече, преполагам - но то нали винаги става дума
за различни конкретни случаи.

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

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

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

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

Между другото най-добрата синхронизация между прекъсвания и други части са софтуерните прекъсвания със заявки и приоритети. Жалко че вече не остнаха архитектури дето да ги имплементират. Иначе е супер удобно. В прекъсването се получават данните и се вдига бит за заявка на софтуерно прекъсване, което по-принцип е с нисък приоритет. По принцип всички софтуерни прекъсвания са с по-нисък приоритет от всички хардуерни. Така че след излизане от истинското прекъсване, обработката на данните става след като падне приоритета достатъчно за да може да се изпълни съответното софтуерно прекъсване. По мое скромно мнение тая система напрактика прави RTOS-вете почти ненужни. Жалко, че тая концепция умря с 16-бит контролерите.

Малко различна като имплементация, но сходни резултати позволява да се стигне и концепцията на АРМ7/9. Според мен е също много сполучлива, но нещо операционните системки не се възползваха и сега с Кортекса има крачка назад. Иначе идеята за общ вектор на прекъсванията позволява от едно място да се прихванат всички прекъсвания и само на едно място да се оправят контекстите. На пръв поглед изглежда като овърхед, да се изпълнява някакъв преди или след прекъсването, но нещата които той прави така или иначе трябва да се направят и се правят.

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

Разпространено може и да е, но не е "нормално". Голямо мислене има да пада как да
се свържат IRQ handler-а и прекъсваемата част, няма що. Сложнотии като флагове и
кръгови буфери....

В система с 512 байта RAM (HC11, преди 15 години) най-нормалното нещо за мене
беше да си наглася някакъв scheduler за 4-те или петте таска, които щяха да свършат
работа, и да подкарам нататък- на втория или третия ден работа.

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

Флагове и буфери се налагат само ако имаш нещо за прекъсване. В момента в който всичко влезе в самите прекъсвания нещата се опростяват.
Разбира се, не винаги е възможно това, само при относително "прости" системи. Примерно разни slave автоматчета дето ги командваш през някакъв сериен. В прекъсването на серийния се буферира байт по байт и се проверява дали вече има цял пакет. Ако да - пакетът се анализира и изпълнява. Ако ще е лампа, да включи ламбата

Това е най-добрата алтернатива - една функция (прекъсване) и всяко необходимо действие се изпълнява възможно най-бързо, като няма излишни действия.

За сравнение другите алтернативи:
* Без да ползваш прекъсвания - кодът ще е същия само че зациклен с проверка в началото. Недостатъци - излишна дейност (полиране) поради което не може да бъде използван sleep режим.
* Прекъсване + таскове. Недостатъци - трябват си сигнализации (буфери, флагове и т.н.) това означава допълнителен код + памет.. Разбира се тези "недостатъци" могат да се обърнат в предимства ако системата се усложни, или пък се правят много сходни пректи.

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

@tgi Аз така и не разбрах каква е тази толкова опростена хватка пред която дори и флагове и буфери изглеждат сложни. И която пасва хем на PPC хем на HC11 хем не се налага много да се мисли?
Сигурен съм че или се бъзикаш или най-много да не съм те разбрал.

Мислех, че иронията е очевидна . Поне такова беше намерението.