Ми ето къде се срещат такива работи

...

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

Пирев, продължавам да не схващам. Днес явно ми ден в който съм тъп. Напоследък ми се случва често.

Добре де как едно прекъсване може да затрупа друго? При положение че веднъж напъхал се в първото, прекъсванията са забранени - не от теб, а от ядрото, как така ще се активира второ та да затрупа първото?

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

А иначе пикльовците (особенно 16) - спор няма, имат слаба ситема за прекъсвания. Което е и нормално, това не е процесор за компютър, това е процесор за автоаларма.

Сега не съм на вълна PIC-ве и не съм гледал как е при най-новите чипове , но при 16 серия не може да стане прекъсване в прекъсване, ако не вземеш принудителни мерки . При самото прекъсване апаратно GIE става 0 и не позволява повтроно прекъсване . Ако в подпрограмата на прекъсването вдигнеш GIE в 1
трябва да се погрижиш да избегнеш конфликтите(най-малкото да нулираш преди това флага който ти е предизвикал прекъсването).

Като не Ви харесва do { GIE = 0; } while (GIE ); можете да забраните
директно IE флаговете в INTCON и тогава няма да имате такива проблеми:
MOVLW 0x7 // или 0x87
ANDWF INTCON,F ; DISABLE PEIE,T0IE,INTE,RBIE


Wise
Може да изглежда тъпичко, но аз си слагах винаги една след друга 2 инструкции bcf INTCON,GIE Ако възникне IRQ на първата...

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

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

...

...

Абе за забрана от програмата съм по съгласен, ама това самия той да не ги забранява .. мммммммм не ми се вярва, досега съм нямал проблем с това ..... то всъщност аз много рядко прибягвам до глобална забрана на прекъсвания, обикновенно забранявам едно или група ... та тоя проблем не ми се е появил .. ще го експериментирам. Ноиначе в момент имам пред мен у-во което получава прекъсване от таймер 0, таймер 1, UART, PortbB change, ext_in .. верно че последните две са с ниска честота, да не каза че ext е бутон ... ама съм нямал проблеми, но и никъде нямам забрана на глобално.

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

Wise
Ако първата не сработи поради ненавременно прекъсване, то не виждам как следващата няма да свали флага.

Напълно е възможно GIE да остане 1 и след две инструкции BCF INTCON,GIE.
Ако имаш например две прекъсвания от таймер и от USART със сигурност в определен момент ще се получи конфликт . В общия случаий тези прекъсвания са асинхронни едно спрямо друго и е
напълно възможно заявкaта за прекъсване от таймера да постъпи след завършване на прекъсването от USARТ и обратно. Ако заявката от USART е постъпила при изпълнението на първата инструкция BCF INTCON,GIE тя няма да бъде блокирана и резултата след RETFIE (вече стана ясно) е GIE=1 . След връщане започва изпълнение на следващата BCF INTCON,GIE , но в този момент постъпва прекъсва от
другия източник. Ситуацията се повтаря: прекъсването не може да се блокира и резултата GIE=1. Ако имаш по вече прекъсвания вероятноста от последователно постъпващи заявки нараства.
С няколко последователни инструкции може би се намалява вероятноста конфликта да се появи но и това не е сигурно. 100 % има само с цикъл или директно маскиране на IE.
Като погледнах стари програми, ползавал съм предимно директно маскиране и не съм имал проблеми.

...

Да, конфликтите с вероятностен характер могат да доведат доста
неприятности и загуба на време.

Т.е. искате да кажете че той дори не може да си забрани прекъсването когато е в самото прекъсване влязъл така ли , а не смао когато аз му правя GIE=0? Това вече не ми се вярва много .....а и това лесно може да се провери ... ако е така, това си е бъг, но аз не съм виждал досега случай в който да обслужвам едно прекъсване по време на друго, това при потребителска забрана по мога да го приема,и сигурно е така.

Абе говорим си за неща които наистина са трудно доказуеми. Как пък да предизвикам асинхронно прекъсване, баш кога влизам в прекъсване, та да го проверим. По принцип е възможно и тая дивотия да я има, ама .... Шанса да се получи, та да изкочи бъга е малък. Точно такъв че да изгърми при клиента, а не на масата.
Дивотия.
Както и да е, не пречи да се забраняват прекъсванията с bcf, btfsc.

Но виж в прекъсване да го правя не ми харесва.
Още повече че ако тоя втория проблем съществува, по цялата логика do,while цикъла няма да помогне. Той по същество не блокира "лошото" прекъсване, а просто се грижи флага да остане нулиран след неговото вмешателство. Което значи че бидейки в първото прекъсване, активирането на второто ще го сгащи, ще му утепа стека (ако е на ръба на преливането), и после и да му връщаш бита в 0 е безмислено, умрял си. Ако всичко това с прекъсването в прекъсване е вярно.

Áëîêà çà ïðåêúñâàíå, êîãàòî çàïî÷íå ïðåêúñâàíå íóëèðà
GIE=0 , ïðîãðàìàòà çà îáñëóæâàíå çàâúðøâà ñ êîìàíäà RETFIE
êîÿòî ïðàâè GIE=1.

Ïðîâåðêàòà å ìíîãî ëåñíî:
Ïóñíåòå åäèí òàéìåð è ðàçðåøåòå ïðåêúñâàíå-> GIE=1, Ò0IE=1.
 ïðîãðàìàòà íèêúäå íå íóëèðàéòå GIE.
Ñëîæåòå åäèí ñòîï â ïîäïðîãðàìàòà çà îáñëóæâàíå íà ïðåêúñâàíåòî
è êîãàòî ñïðåòå ùå âèäèòå GIE=0 ñëåä òîâà ïðåìèíåòå ïðåç RETFIE è ùå âèäèòå GIE=1. Àêî èñêàòå â ïîäïðîãðàìàòà çà îáñëóæâàíå íà ïðåêúñâàíåòî ñëîæåòå êîìàíäè bcf INCON,GIE , ðåçóëòàòà ùå áúäå
ñúùèÿ (GIE àïàðàòíî e ñòàíàë âå÷å 0 îùå â íà÷àëîòî íà ïðåêúñâàíåòî, ìîæå ñàìî çà îïèò äà ãî íàïðàâèòå 1 íî ùå ðàçðåøèòå ïðåêúñâàíå â ïðåêúñâàíå ).

Èñêàòå äà õâàíåòå ïðåêúñâàíå ïîñòúïâàùî åäíîâðåìåííî ñ èçïúëíåíèåòî íà bcf INCON,GIE , êîåòî íå ìîæå äà áúäå áëîêèðàíî è ïðåâêëþ÷âà GIE=1 ïðè âðúùàíå.

Ïóñíåòå êîëêîòî ìîæå ïîâå÷å ïðåêúñâàíèÿ è
ñ òîçè öèëúë â ïðîãðàìàòà òðÿáâà äà óñïååòå ãî çàñå÷åòå:

loop: bsf INCON,GIE //enable INT
nop
nop
nop

bcf INCON,GIE // try disable INT
nop //
btfss INCON,GIE // DISABLE INT ???
goto loop1 //success GIE=0

ERROR: LED_0N // INTERRUPT NOT DISABLE

Òàçè îñîáåíîñò å ñàìî çà GIE íå âàæè çà äðóãèòå IE ôëàãîâå. Ïðîñòî RETFIE íÿìà âúçäåéñòâèå âúðõó òÿõ.