Това написах аз на техническата подръжка:

Area: PICmicro Products
Product Group: PIC18FXX2
Product: PIC18F452 Date Created: 4/19/2005 1:19
Issue: Interrupts Date Resolved: 4/20/2005 2:29
Description: On PIC16 devices there is a "problem" with disabling of the global interrupts. It is noted in the AN576 - http://ww1.microchip.com/downloads/en/A ... 00576b.pdf

Is there a same "problem" in the 18F cores? Does I need the same clear/check sequence when I want to disable all interrupts? Is it related to all interrupts, or it is valid for the external ones?
I know that this is a core specific issue. Maybe it's not a BUG. But why I cannot find any info about it in the microcontroller data sheets, or erratas. It is written in one application note, hidden somewhere in the deep forest.

Това получих от тях:
Resolution: The workarounds are a safeguard for the possibility that this might occur and can be applied to any device.

Велико а. Много лаконично. Всичко ми стана ясно, що ли ми трябваше да питам. Напсувах ги учтиво. Както и да е проблема явно съществува при всички ядра и do while цикъла е решението.
Да ме извиняват всички колеги, ама аз докато не пипна не вервам.

...

Последния постинг под име Гост е мой, бях пропуснал входа . Написал съм може да пробваш. Но ако се погледне диаграмата на логиката на прекъсване и като се знае че GIE се установява в 0 при прекъсване и в 1 при RETFIE всичко става ясно без опити.
От диаграмата на логиката на прекъсване се вижда,че заявката за прекъсване и GIE са в схема 'И' т.е GIE може да блокира прекъсване само след като се установи в 0. Но преди да се изпълни инструкциатя bcf INCON,GIE има FETCH НА ИНСТРУКЦИАТА този процес е описан във всяко ръководство. По време на FETCH прекъсването е разрешено ,защото GIE още не е станал 0 и ако тръгне тогава прекъсване, спиране няма... и на края RETFIE .

...

Има и продължение. Тоя път бяха бързи - само 30 мин.

Това от мен:

4 questions - 1 answer. The perfect technical support. Maybe this is the way to keep developers to work with Microchip. No way.

"But why, I cannot find any info about it in the microcontroller data sheets, or erratas?" - this is the main question

И отговора:

"But why, I cannot find any info about it in the microcontroller data sheets, or erratas?"

I will pass on this information to the documentation team. Thank you for your interest.

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

Lino, механизма на забраната на прекъсванията е ясен. Както писах всеки процесор който има отделни стадии на изпълнение на инструкциите (всеки процесор значи), е уязвим от заявка за прекъсване по време на инструкция за забрана на прекъсванията. Това само по себе си не е страшно. Страшното е че пика ще изпълни инструкцията за забрана и след това ще влезе в прекъсването. Всъщност и това не е страшно. Страшното е че после ще вдигне бита в 1. А решението е просто да не го пипа. Просто механизма за забрана на прекъсванията по време на прекъсване не е трябвало да работи с "оригиналния бит". Ама и това не толкоз страшно. А всъщност най страшното е че това е документирано на баба им на задника. А не където се документират такива неща. Е тва е страшното.

Чудесно....аз преди време като разбрах за тва тъпото прекъсване....абе почнах да се чудя как въобще ми работят някой устройства - на късмет ???

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

Цецо
"А всъщност най страшното е че това е документирано на баба им на задника. А не където се документират такива неща. Е тва е страшното"

Потърсих най-старите PDF файлове на Мicrochip с които разполагам. За съжаление не можах да намеря по стари от 1998г. Но и това е достатъчно. В документа DS30445C.pdf (PIC16C84) на
старница 44 раздел 8.9 Interrupts е написано и подчертано:

Note 2: If an interrupt occurs while the Global
Interrupt Enable (GIE) bit is being cleared,
the GIE bit may unintentionally be
re-enabled by the user’s Interrupt Service
Routine (the RETFIE instruction). The
events that would cause this to occur are:
1. An instruction clears the GIE bit while
an interrupt is acknowledged
2. The program branches to the
Interrupt vector and executes the
Interrupt Service Routine.
3. The Interrupt Service Routine
completes with the execution of the
RETFIE instruction. This causes the
GIE bit to be set (enables interrupts),
and the program returns to the
instruction after the one which was
meant to disable interrupts.
The method to ensure that interrupts are
globally disabled is:
1. Ensure that the GIE bit is cleared by
the instruction, as shown in the
following code:
LOOP BCF INTCON,GIE ;Disable All
; Interrupts
BTFSC INTCON,GIE ;All Interrupts
; Disabled?
GOTO LOOP ;NO, try again
; Yes, continue
; with program
; flow

Има диаграми и всичко е ясно обяснено.
Има го написано по същия начин и в документ DS30605B
PIC16C63/73B/65B/74B и вероятно в многи други .

Сигурен се, че това е отразено и в документи преди 1998г. защото съм работил с тях.
В случая, не трябва да виним MICROCHIP.

За да бъдем точни още малко информация:

Документите 30430B.PDF ( 16f84) , 30605B.pdf (16C63/73) и др. в които е описан проблема с прекъсванията са от 1996г.
Погледнах описанието на друг процесор, който съм ползвал от това време 12ce673.pdf. В него проблема не е описан.

Проверих описанието на 18F252. В него проблема също не е описан.
Вероятно MICROCHIP са преценили ,че тази особеност в прекъсванията при техните процесори е достатъчно известна.

Пич ти направо ме уби. Ти като седнеш да работиш с даден процесор какво точно правиш? Хващташ и изчиташ всички даташеетове на всички процесори пройзведени от въпросния пройзводител през последните 7 години. Това е меко казано - адски тъпо. Не ми се обиждай, ама аз като седна да работя с 18F452 очаквам да намеря информация за него там където пише 18F452. Не съм врачка. Работя с Микрочип от много години. Но вече почва да ми писва. Ядрото е много добро като замисъл, но изпълнението му е направо аматьорско. Всеки процесор има по 10 ерати, бъговете им излизат с години. А когато се опитват да си крият проблеми, които се оказва че са добре известни - е тогава ми бъркат в задника с извинение. Майната им. Няма смисъл да се караме, заради тъпата им фирмена политика да обръщат потребителите на бета тестери. Поне да си документираха бакиите.

...

AVR rulez. Присъединете се към тъмната страна

...

Нема такова нещо. www.futurel.bg - последния път си поръчах точно 2 (два) броя mega16. Пратиха ми ги в къщи с куриер.

Абе кой знае колко такива проблема има AVR ама още не си ги открил, а и може никога да не ги откриеш.