warten auf das GIE Bit ???

[theborg]

Hi, Irgendein Programmierer von Microchip macht das ganz gerne so, wen es ein Interuptlloses Programm ist, bin vor 2 Wochen drüber gestolpert in der AN zu I²C ist das auch so, spricht ja eigentlich auch nichts gegen ist halt ein typisches Programm ohne Interrups und ähnlichen da kann man das so recht gut machen.

[RoboHolIC]

bcf INTCON,GIE ??? btfsc INTCON,GIE ??? goto $-2 ???

... ist halt ein typisches Programm ohne Interrups und ähnlichen da kann man das so recht gut machen.

Da verstehe ich jetzt irgendwas nicht. Ja, es kann sinnvoll sein, durch pollen auf das Interruptflag eines Peripheriemoduls (insbesondere Timer) die Interruptlatenzzeit einschließlich der notwendigen ISR-Präliminarien zu umgehen. Aber wozu die Manipulation des GIE-Bits in einem Interrupt-freien Programm? Es würde m.E. nur Sinn machen, wenn in einem Programm _mit_ ISR vorübergehend alle Interruptquellen deaktiviert werden sollen, um z.B. eine sehr genaue Zeitmessung durchzuführen. Aber genau dann kommt wieder die am Anfang gestellte Frage nach der Notwendigkeit der scheinbar überflüssigen Abfrage.

[Siro]

Neue Erkenntnisse:

Ich habe eben mal mit dem C-Compiler XC8 geprüft was der für einen Assembler Code draus macht.
Um die Globalen Interrupts zu sperren mus man in "C" die funktion di() aufrufen.
Dies ist jedoch keine Funktion sondern ein macro definiert in der Datei PIC.H
Und nun, man staune, je nach verwendetem PIC gibt es da tatsächlich Unterschiede.
Dort wird tatsächlich ein Code erzeugt, der darauf wartet, bis das gelöschte Bit auch wirklich gelöscht ist.
Ich hab dann im Compiler mal verschiedene PICs ausgewählt und neu Compiliert um mir den Assembler Code anzusehen.
Die Bestätigung war eindeutig.
Die PICs 16C61,16C62,16C63,16C63A,16C64,16C65,16C65B,16C71, 16C73,16C73B,16C74,16C74B,16C84,16C745,16C765,16LC 74B
brauchen anscheinend diesen Code um richtig zu funktionieren.
Der PIC12F617 braucht diesen Code anscheinend nicht. Das wird wohl ein Fehler im Datenblatt sein.
Eine Information von Microchip steht aber noch aus.

Auszug aus der originalen Datei PIC.H von Microchip:
#define di() { do { GIE = 0; } while ( GIE == 1 ); } // disable interrupt bit

Die Errata Sheets werde ich auch gleich mal durchforsten.

[Andre_S]

Hallo Siro,

Danke für die Info! Also doch bei einigen notwendig...

Hat ich es mir doch gedacht, wenn es wichtig ist, müssen die Mikrochip Compiler das Thema ja kennen...

Ich hatte zwar damals nichts kritisch in den Errata Sheets gesehen, müsste aktuell aber auch nochmal nachschauen, aber da Du den XC8 einmal drauf hast,... schaust Du bitte mal beim 18F442 nach, die anderen von mir wären unkritisch, aber bei dem würde ich mich nicht so wohl fühlen...

Gruß André

[Siro]

Hallo Andre,
habe ich eben ausprobiert mit deinem PIC. Brauchst Du Dir anscheinend keinen Kopf machen. Das sieht völlig okay aus, ohne den Schnickschnack.
Der braucht diese Abfrage nicht.....
aus "C" Code
di();
wird Assembler Code
BCF 0xff2, 0x7, ACCESS


Aber diesen Spassigen Code wollte ich Euch nicht vorenthalten, was der C-Copiler daraus macht beim 16C63:
Der "C" Code:


di();

Der erzeugt Assembler Code:

   7F8    138B     BCF 0xb, 0x7     ; INTCON,GIE löschen
   7F9    1B8B     BTFSC 0xb, 0x7   ; überspringe nächtse Zeile wenn Bit gelöscht ist
   7FA    2FFC     GOTO 0x7fc       ; Bit war gesetzt gehe zu Adresse 7FC
   7FB    2FFD     GOTO 0x7fd       ; Bit war gelöscht, gehe zu 7FD
   7FC    2FF8     GOTO 0x7f8       ; Bit war gesetzt, wie wir schon in 7FA festgestellt hatten, nun  zurück und Bit nochmal löschen
   7FD    2FFE     GOTO 0x7fe       ; Bit war gelöscht, wie wir schon in 7FB festgestellt hatten, weiter gehts nun in der nächsten Zeile, die man auch ohne Goto erreicht hätte
   7FE    118A

Jetzt weis ich wieder warum ich in Assembler programmiere.......

PS: (ich weis, der Code wird etwas grösser, weil ich keine offizielle Version gekauft habe)
Running this compiler in PRO mode, with Omniscient Code Generation enabled,
often produces code which is 60% smaller and at least 400% faster than in
Free mode. The MPLAB XC8 PRO compiler output for this code could be
3 bytes smaller and run 4 times faster.
See http://www.microchip.com for more information.

[Andre_S]

Hallo Siro,

besten Dank für den Test!!!
Da bin ich erst mal beruhigt.

Tja, bei Compilern kann man immer wieder etwas lustiges finden, dies ist allerdings sehr „gekonnt“, ob das wirklich nur die Optimierung ist…


Gruß André

[PICture]

Hallo!

Jetzt weis ich wieder warum ich in Assembler programmiere.......

Ich auch, weil es einen minimalsten und schnellsten Programm erzeugen lässt, das nur Nötige ohne Schnickschnacks macht ....

[Siro]

Die Rückmeldung von Microchip ist da:

This was an issue that was fixed and is not applicable to the enhanced core  devices,
for instance PIC16F1939 or PIC12F1501 .
To be on the safe side, I would recommend to use the alternative methods as described in Application Note AN576 for the PIC12F617

Um auf der sicheren Seite zu sein sollte man doch die alternative Methode benutzen klingt jetzt nicht grad vertrauenserweckend.....
Siro

[Andre_S]

Hallo!
Ich auch, weil es einen minimalsten und schnellsten Programm erzeugen lässt, das nur Nötige ohne Schnickschnacks macht ....

...und vor allen Dingen weiß ich auch genau wo was passiert und mit welchen Timings, damit bin ich frei von irgendwelchen nicht geplanten Überraschungen!

Die Rückmeldung von Microchip ist da:

This was an issue that was fixed and is not applicable to the enhanced core  devices,
for instance PIC16F1939 or PIC12F1501 .
To be on the safe side, I would recommend to use the alternative methods  as described in Application Note AN576 for the PIC12F617

Um auf der sicheren Seite zu sein sollte man doch die alternative Methode benutzen klingt jetzt nicht grad vertrauenserweckend.....
Siro

Hallo Siro,

wer weiß wer geantwortet hat,...eventuell auch nach dem Motto sicher ist sicher...

Wenn es Ihr C-Compiler nicht macht, mache ich es auch nicht!


Gruß André
ps. doch mal zum Spaß über eine längere Zeiteinheit simulieren lassen um den Effekt zu testen...