Archiv verlassen und diese Seite im Standarddesign anzeigen : warten auf das GIE Bit ???
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
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é
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
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
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
06.10.2012, 23:43
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!
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
08.10.2012, 09:38
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.
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.
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é
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.
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é
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 .... ;)
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
Eben, ich kann nur aus eigener Erfahrung mit diversen PIC's sagen, dass durch Reset gelöschtes GIE Bit bisher in keinem meinem ASM Programm ohne Interrupts gesetzt wurde. ;)
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...
...und vor allen Dingen weiß ich auch genau wo was passiert und mit welchen Timings, damit bin ich frei von irgendwelchen nicht geplanten Überraschungen!
Da muss ich auch voll zustimmen, nur eine Option im Compiler umstellen reicht und das Timing ist völlig anders. In Assembler gibt es so etwas nicht und das ist auch gut so.....
Mit dem Testen wird schwierig, mann müste dafür sorgen in jeglicher Taktphase Q1..Q4 mal einen Interrupt auszulösen. Da kommt man aber meiner Meinung nach nicht ran um entsprechend zu triggern.
Ginge vielleicht über einen externen Interrupt mit einem freilaufenden bzw. asynchronen Takt zur CPU. Aber ich denke mal, wenn da ein Problem in unseren PICs wäre, hätten wir das schon bemerkt.
Aber testen schadet ja nix. Wobei wundern würde mich auch nix mehr, ich hab schon die tollsten Sachen erlebt mit den PICs und die Errata-Sheet wachsen ja auch ständig, man muss immer wieder mal
reinschauen, was im Laufe der Zeit an Fehler neu gefunden wurde für den PIC. Manchmal werden Fehler ja erst nach Jahren erkannt. Beim 18F252 wurde viel später mal festgestellt, dass er unter bestimmten
Umständen seinen Resetvector nicht trifft. Da kam aber richtig Freude auf.....Die Folgen kann man sich vorstellen, wenn die Initialisierung fehlt....
Siro
Hallo Siro,
ja ich glaube auch wir sollten uns die Mühe des Simulierens sparen. Die Wahrscheinlichkeit, dass da etwas passiert ist wohl geringer als irgend eine andere unvorhersehbare Situation.
Ich habe bisher null Ausfälle des PIC bei ca. 2500 Geräten über die letzten 9-10 Jahre trotz teilweise wiedriger Umfeldbedingungen.
Da ich aber relativ wenig verschiedene PIC Typen eigesetzt habe, bin ich bisher auch über recht wenig Probleme gestolpert und somit auch recht zufrieden mit dem PIC's welche ich vor Jahren gegenüber andern MC's favorisierte hatte. Und auch wenn ich manchmal zum C-Compiler für einen schnellen Test geschielt habe,... aber bei vielen Aufgaben überwiegen die Vorteile vom Assembler.
Gruß André
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.