А какво се пише в прекъсването?

то на мене ми е трудно да накарам проца да пише код в прекъсване - виж да изпълнява код в прекъсване постоянно го правя

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

Хубаво е когато четеш входове, особено ако на тях има свързан бутон, да направиш някаква обработка на сигнала, за да избегнеш разтрептяването на контактите - тъй наречения дебоунс.
Съвсем примерно - следиш състоянието на входа през 1 - 5ms. Ако при ХХ броя последователни проверки, състоянието е било устойчиво в 1, приемаш че е 1. Ако по време на тия ХХ проверки се е променяло, ресетираш брояча за ХХ и започваш отначало.

А ако дойде пак прекъсвене докато си правиш там нещо си, ко праим?

Ако докато изпълняваш тоя код дойде ново прекъсване:
1 - коригираш времената на таймера
2 - ако 1 е неприложимо, вземаш по-бърз контролер

pending interrupt

Интересно тогава защо са измислили приоритетни прекъсвания. То ако всички се отбележат като пендинг няма да има смисъл. Хептен без код в прекъсване няма как да се мине. Там обикновено пада голямо оптимизиране.

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

В прекъсването: нищо не сетваш на TRUE, а увеличваш някой особено важен байт с 1. Толкоз.

В основния луп: СТЪПКА с левия крак: Четеш байта с особената важност. Ако не е 0, правиш, каквото по устав пише да се прави след прекъсване.
Забраняваш прекъсванията. Намаляваш 'оня' байт с 1. Разрешаваш прекъсванията. Отиваш на СТЪПКА с левия крак.

Измиваш си И десния крак.
Ако по някое време 'оня' байт превърти ( то хора превъртат, че байтове ли няма да могат ), смени конценцията, че явно има проблем с контрацепцията.

Сакън! Ако те види relsys ще те набие

Прекъсванията НЕ се забраняват току-така... В случая няма и нужда, прекъсването може да си увеличава един байт колкото си иска. А пък основният цикъл си увеличава друг байт всеки път когато байтовете са различни.... Желателно е байта на прекъсването да е volatile и да не се кешира

Вярно, и така става. С един байт РАМ в повече, но не е болка за умиргане.
ЕДИТ: ако процесорът ( и компилаторът ) поддържа атомарен декремент, дори и без забраняване на прекъсванията и без втори байт ще стане.

Класически пример - в прекъсването трябва да прочетеш стойност от АЦП-то и да действаш спрямо нея (примерно 10 много сложни сценария).
Ко праим?

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

Окей, прецезираме задачата - имаме някво странно явление, примерно радиация, което е пълен хаос като закономерност, но трябва да се мери и да се прави нещо си там в зависимост от квото е измерено. Не се хващайте да го нищите това, формализирано представлява следната задача:
Събитията настъпват изцяло случайно, може примерно 3 много бързо едно след друго след това да няма нищо 2 дена. На всяко регистрирано събитие трябва да се прави нещо много бавно. Проца няма проблем да се справи с 3 събития на 2 дена, но 3 събития много бързо едно след друго - не. Ако пропуснеш събитие, реактора гърми (не съвсем веднага) и всички умират.

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

Няма значениекога настъпват събитията. Ако е обработка от сорта на 2+ 3,т.е. проста сметка, прост инкремент може да го направиш в прекъсване, ако не просто си четеш АЦП, вдигаш един флаг и вече в основния цикъл си ги проверяваш флаговте по прекъсваният и изпълняваш каквото има да се изпълни. Всичко зависи от времената, то при микроконтролерите, не разбирам тук арм-9 с повече мозък от мен, е много важно да си структурираш целия алгоритъм на работа съобразно задачата която изпълняваш, и сигурно Миро ще ме разпне, ама не мисля че при подобен тип задачи е добра идея да спазваш добрите практики, освне ако не си презапасен във всичко, и в изчислителен ресурс, и в бързодействие по I/O и всичко останало.
Аз подобен род задачи ги виждам повече като хардуерни задачи, и за мен кода трябва да е има мнооого "храдуерна логика".
Ако въпроса е какво правим със задача при която трябва да се реагира толкова бързо че не позволява излизане от прекъсване и завъртане на цикъл логично ако не може да направиш нищо по тия две условия , е да я обработиш в прекъсването. Обаче те нещата малко се самоизключват, ако е задачата е да промениш състояние на порт, да сетнеш някаква променлива и д.р от сорта, то тя по подразбиране е подходяща за изпълнени в прекъсване и обикновено там се и изпълнява, обраното увеличава кода и те държи повече време в безсмислен код.
Ако е задача която изисква смекти, като изчисляване на Пи до 365-тия знак, самата задача отнема много повече време от нужното да излезеш от прекъсване и да полираш флага, т.е. това, че ще я изнесеш извън прекъсването няма никакво значение тъй като няма да рефлектира на времето за нейното изпълнение.
Забраната на прекъсване при влизане в прекъсване не е добра идея.
Но while в прекъсване, това за мен е недопустимо, изобщо използването на while ми се вижда доста неразумно, ако се използва, задължително трябва да имаш някакъв гарантиран изход от този while. Аз рядк имам друг while освен тоя на основния цикъл. Ако имаш някакъв OS или диспечър на задачи, това вече е по-друго,но и тогава според мен while трябва да се избягва. Сега ако го използваш за цикъл е друго нещо, т.е. манипулираш променливата в самия while и няма начин да не излезеш от него.