warten auf das GIE Bit ???

[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

[PICture]

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.

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

[Siro]

...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

[Andre_S]

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é