warten auf das GIE Bit ???

[Siro]

Hallo,
seit Jahren beschäftige ich mich schon mit den PICs.
Beim Durchforsten des Datenblatts vom 12F617 sehe ich grad einen Programmcode der mich doch ins Erstaunen versetzt.

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

Dann wird auf die Application Note AN576 verwiesen.

Dort wird beschrieben:
Wenn während der Ausführung des Befehls bcf INTCON,GIE ein Interrupt auftritt, wird die Interrupt Funktion ausgeführt.
dann verzweigt das Programm normalerweise mit RETFIE zurück und setzt automatisch das GIE-Bit wieder.
Der RETFIE Befehl macht also unser Löschen des GIE-Bits zu nichte.
Dort steht jedoch, dass man sich auf die PIC16Cxx und 17C42 bezieht.

Kann das beim 12F617 auch passieren ?
Ich habe bisher mit den PICs 12F 16F und 18F niemals solch Code eingebaut.

Ich habe aber ein ähnliches Problem schon mit nem Cortex M3 Prozessor gehabt.
Dort war es bedingt durch die internen Schreibpuffer.

Vielleicht hat man aber auch beim Erstellen des Datenblatts den Code aus einem anderen Datenblatt kopiert und das Problem existiert
in diesem Chip (12F617) garnicht.

Hat evtl. jemand von Euch zusätzliche Info mich mich.
Ich danke schonmal im voraus
Siro

Verweis aufs Datenblatt PIC12F617 WRITING TO FLASH PROGRAM MEMORY Example 3-2 Seite 34

[Andre_S]

Hallo,

interessant...!
Ich habe in all meinen Programmen für die 16er und 18er PIC weder privat noch betrieblich so einen Code eingesetzt.
Da ich bisher bei weit über 2500 Geräten und unterschiedlichen Firmwareversionen sowie häufiger Nutzung des Befehls keine unvorhergesehenen Auswirkungen haben, wird es wohl nicht ganz so kritisch sein.
Allerdings schaue ich mir das nun auch mal genauer an, dafür erst einmal besten Dank auch wenn ich Deine eigentliche Frage nicht beantworten konnte...

Um sicher zu gehen eventuell mal über einen größeren Zeitraum simulieren mit Stop/Info bei auftretendem Fehler.


Gruß André

[Rico88]

Naja, manchmal kann man nicht in der Kopf eines jeden Programmierers sehen. Das ist ja eindeutig eine reine Sicherheitsabfrage. man kann ja oft seltsame Code-Schnipsel finden. Kenne selber auch eine Programmierer in der SPS-Technik, die an ein UND-Glied noch einen "high-Merker" ran setzen oder an ein ODER-Glied noch einen zusätzlichen "low-Merker".

Gruß Rico

[Siro]

Hallo,

interessant...!
Ich habe in all meinen Programmen für die 16er und 18er PIC weder privat noch betrieblich so einen Code eingesetzt.
Da ich bisher bei weit über 2500 Geräten und unterschiedlichen Firmwareversionen sowie häufiger Nutzung des Befehls keine unvorhergesehenen Auswirkungen haben, wird es wohl nicht ganz so kritisch sein.
Allerdings schaue ich mir das nun auch mal genauer an, dafür erst einmal besten Dank auch wenn ich Deine eigentliche Frage nicht beantworten konnte...

Um sicher zu gehen eventuell mal über einen größeren Zeitraum simulieren mit Stop/Info bei auftretendem Fehler.


Gruß André

Hallo Andre,
da geht es mir genauso wie Dir, ich habe auch etliche hundert Geräte in der Firma im Umlauf und auch noch nie solchen Code eingesetzt.
Ich kann das auch garnicht nachvollziehen. Das ist doch ein "atomarer" Code. Also nur ein einzelner Assembler Befehl. Wie kann denn da ein Interrupt Zwischenfunken ?
Das kann dann nur mit der 4 Stufigen Pipeline-Struktur zusammen hängen. Aber ich habe das in den letzten 13 Jahren PIC noch nie gesehen oder so programmiert.
Hab auch nie irgendein Zwischenfall erlebt, der auf einen solchen Fehler schliessen könnte. Ich werde mal direkt bei Microchip nachfragen. Weil das verunsichert mich jetzt doch,
da meine Geräte im OP-Saal am Patienten dran sind. Aber keine Angst, es gibt immer noch ne zweite Sicherheit (die gute alte Analogtechnik) die vor der CPU steht
Siro

[Andre_S]

Hallo Siro,

OK,... dann warte ich erst mal ab was Du in Erfahrung bringst und halte bis dahin die Füße still...
Wäre nett wenn Du hier nochmal Bescheid gibst.
Programmiere nur in Assembler, habe deshalb kein C drauf, aber in dem Falle sollten das die Compiler, zumindest von Microchip, doch eigentlich beachten. Deren Ergebnis (Code) könnte man sich ja mal anschauen...
Um den OP mache ich sowieso lieber einen Bogen, da wird sich ja hoffendlich erstmal nichts ändern


Gruß André

[RoboHolIC]

Gibt es zu diesen Typen bei Microchip Silicon Errata-Datasheets? In diesen Dokumenten würde man die verbindliche Information finden, ob und in welcher Silicon Revision es diesen Hardwarefehler gibt und - dann auch in aller Klarheit - _wie_ man ihn umschifft. Ein Bit löschen und dann nachsehen, ob es wirklich gelöscht ist - das ist paranoid oder aber Ausdruck von Spezialwissen: Ich würde das nicht auf die leichte Schulter nehmen sondern dringend prüfen und derweil zur Sicherheit den aufgezeigten Workaround implementieren!

[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é