Weil an so vielen Stellschrauben auf einmal gedreht wurde, ist es im Nachhinein nicht seriös, sich auf einen einzigen Punkt zum Festmachen der Schuld zu kaprizieren. Aber sicher ist, dass das Win-System ,,in den Wicken" war, wie man an der teils elend langen Verarbeitung einzelner Funktionen sehen konnte, so z.B. auch das ewig dauernde Runterfahren. Verwunderlich ist das aber irgendwie schon, denn auf dieser Hd wurde über Jahre quasi nur das MPLAB genutzt. Andere Programme waren erst gar nicht installiert oder wurden schon vor Langem deinstalliert. Ich gehe davon aus, dass die SSD – eine preiswerte Version – auch Speicherverluste hatte. Muss mal versuchen, ein spezielles Testprog auf die los zu lassen. Und – ach ja – nun rasch noch eine Sicherung in Form eines Images vorzunehmen.

Zum eigentlichen Fred-Thema – dem Interrupt – gibt es aber auch noch was, nachzutragen. Weiß nicht, wie ihr für ein neues Projekt eure Programm-Arbeit angeht. Ich neige dazu, mir ein Vorhandenes auszusuchen, bei dem schon allerlei passt oder ähnlich ist. Das wird dann umgestrickt, also angepasst und erweitert. Beim Thema Interrupt gehts genau so. Da hatte ich zunächst die ,,echten" Interrupt-Routinen bearbeitet, also die mit abrupter Unterbrechung des Progs, Sprung zum IRQ-Vektor, von dort zur IRQ-Bearbeitungs-Routine, von dort mit ,,return" wieder ins Prog zurück. Alles prima, nur hatte ich heuer nicht mehr auf dem Schirm, dass ein einfaches ,,wake-on-change" (WoC) schon ein wenig anders ist als die beiden normalen IRQ's. So hatte ich nicht beachtet, dass beim WoC im Gegensatz zum ,,Echten" bei jedem Status-Wechsel des avisierten Port-Pins eine Aufwach-Reaktion erfolgt. Beim "Echten" stellt man sehr genau ein, ob fallende oder ansteigende Flanke, beim ,,Falschen" gibt es solche Unterscheidung gar nicht.
Und – Tusch – hat man die aus der IRQ-Bearbeitungs-Routine sinnvolle und notwendige Abfrage, welcher Pin sich denn nun verändert hatte, mit in das neue Prog übernommen und wundert sich, dass es auf einmal völlig deplazierte Sprünge gibt. Naja, halt mangelnde Übung...., da vergisst der Mann schon mal was.... Seufz !
Grüße, picass

Verrückt was da alles zusammen spielen kann.

Drei gordische Knoten auf einen Streich !

ALLE meine Probleme der letzten Zeit mit Assembler-Programmieren sind gelöst und das in unerwarteter Weise. Vor 2 Tagen schwante es mir, dass die SSD einen Defekt haben könnte: häufiger wollte der Compi nach dem Einschalten nicht drauf zu greifen, beim Win-Runterfahren lief der PC minutenlang weiter, statt nach ca. 10 sec spätestens aus zu sein. Eine testweise andere, ähnliche SSD verhielt sich nicht so. Gestern dann der Gedanke, es vielleicht doch erst mal nur mit einer Win-Reparatur-Installation zu versuchen, bevor die HD im Müll landet. Also gleich die MPLAB X Version vorweg deinstalliert, damit alle evtl. Leichen weg waren, dann WIN neu und genervt die 5 Stunden dauernde Aktion abgewartet, der PC kroch mühsamst vor sich hin. Dann heute Mittag die alte MPLAB X v5.20 neu installiert. Aber.....
....aber vorher noch hatte ich mir heute morgen meinen guten, aber alten PC gekrallt und den durch gewurstet:
- den CPU-Lüfter demontiert und gucke da: trotz meiner Empfindung, dass die CPU-Kühlerpaste noch nicht so alt sein dürfte, war diese doch kurz davor, hart zu sein. Also die CPU neu beschmiert. Dann den Lüfter drüber endlich so montiert, dass er in die ,,richtige" Richtung blies. Der saß vorher anders rum. Was in dem Fall nahezu egal war, einmal, weil er so riesig ist, dass er auch alleine die Lufthoheit im Gehäuse hatte, dann aber auch, weil ich am großen Towergehäuse eh' die Seitenwand ab hatte, um immer Zugriff auf die Innereien zu haben. An Kühlung durch Luft war definitiv kein Mangel, aber die harte Paste verhinderte mit Sicherheit eine ausreichende Hitzeabfuhr.
- die Bios-Batterie war schlapp. ,,Eigentlich" soll ein PC auch ohne das starten können, aber die Häufung der Hänger gleich nach dem Einschalten, also noch vor dem Winstart, war wohl kein Zufall.
- die RAMs wurden kurz entnommen und gleich wieder in ihre Sockel gesteckt: Korrision an Kontakten ist eine böse, böse und fast nicht zu entdeckende Sache !
- alle Anschlüsse der HD-Datenkabel wurde zusätzlich nochmal mit Heißkleber gegen evtl. Wackeln gesichert;
- einzelne, noch irgendwie lose Kabel oder Käbelchen wurden auch noch mit Heißkleber fixiert, jetzt rührt sich selbst bei leichtem Erdbeben nichts mehr.
- der hintere Gehäuselüfter wurde entstaubt;
- der vordere GL schien bei genauer Betrachtung sauber zu sein. Aber man kann nie wissen, also doch die Arbeit der Abnahme der Vorderfront ausgeführt und Tusch: guckst du Bild !

Also den alten PC komplett auf Vordermann gebracht, dann die mit dem frischen Win10 versehene SSD installiert, die neue alte MPLAB Version von Microchip geladen, dann mutig die beiden Nagelproben gemacht:
- das Win läuft deutlich schneller und vor allem das Ausschalten ist wieder so fix wie üblich.
- das Elend mit dem Interrupt bei Wechsel vom PIC18F14K22 auf den PIC18F25K22 ist wie weg geblasen. Als hätte es das nie gegeben! Der PIC pennt ein, wie er soll, wacht auf, wenn die passende Taste gedrückt wird, tut, was er soll – was soll er? Doofe Frage: eine LED anzünden ! – und der Simulator wie auch der Hardware-Debugger waschen ihre Hände in jungfräulicher Unschuld: endlich reagiert der Sim/Debug nicht erst nach zwei Schritten auf die Anweisungen, sondern wie üblich sofort. Dann lassen sich die INTCON Flags löschen......... das hatte vorher Verzweiflung bis zur Gehirnwäsche hervor gerufen !

NEUER alter Compi, neues Win10, neues MPLAB und die PIC-Welt ist wieder in Ordnung. HEUREKA !
Grüße, picass

Mein Lieblingskampf, der gegen Interrupts....    

Aktuell führt das Prob auf wohl eine Eigenart des PIC18F25K22. Da versuche ich das Aufwachen aus der Sleep-Routine OHNE Interrupt. Und da gibts reichlich Probleme: mit dem Programm - siehe unten - will der PIC erst gar nicht einschlafen. Was erklärlich wäre, weil immer dasjenige INTCON Flag gesetzt ist, welches einen Port-on-Change-IRQ anzeigt, das Bit 1 mit dem Beinamen " RBIF". Das lässt sich auch im Simulator nicht löschen! Überhaupt spinnt der Simulator, wenn - aber auch nur dann - diese Wake-up-Routine implementiert ist. Wenn man dann im Sim den Einzelschrittmodus wählt, um den Zustand der Variablen (ZdV) zu verfolgen, dann reagiert dieses Teil-Prog für den ZdV immer erst nach zwei Schritten. Normal aktualisiert sich das immer sofort dann, wenn ein Schritt ausgeführt wurde und nicht erst nach zwei Schritten.

Ein und dasselbe Prog - natürlich am Anfang mit angepasster Initialisierung - funktioniert auf einem PIC18F14K22 prima. "Eigentlich" sollte zwischen den beiden PIC-Typen kein nennenswerter Unterschied sein. Es gibt zwar marginale, z.B. bei den Namen der INTCON Register, aber sonst....
Unangenehm könnten diverse Mehrfachbelegungen mit mehreren Funktionen auf ein und demselben Port beim 25-er sein. So ist der Port B5 mit Funktionen derart überfrachtet..., man sieht es, wenn man sich vom MPLAB die Initialisierung mit ihren Auswahlmöglichkeiten anschaut.

Was klemmt beim PIC18F25K22 da so, wenn das Prog bei seinem namentlich fast gleichen Bruder so prima funktioniert?!?
Grüße, picass
4x7anzeige.txt

Habe die Progs nochmal überarbeitet und Überflüssiges eliminiert. Nunmehr sind es nur noch drei Progs. Für jedes von ihnen ist im Anhang das Listening vorhanden  und einmal ein Hex-File mit einem Muster-Prog.
Grüße, picass

Da hat der Fehlerteufel wieder zugeschlagen:
In meinem obigen Kompendium muss es für das Prog "IRQ15" - also dasjenige des Aufwachens ohne jedweden IRQ - unter Position 2) heißen:
"Im INTCON-Reg muss das Bit RABIE freigegeben werden, am besten direkt vor dem sleep-Befehl."
Also nicht: RABIF, was ja ein Anzeigeflag ist, sondern richtig: RABIE, das enable-bit.

Ne, pic18, bin ja selbst ein Alter..... oder so ähnlich , um das Banking kümmere ich mich schon seit Langem nicht mehr. Einzige Ausnahme war - falls meine Erinnerung da stimmt - beim Beschreiben und Lesen des EEproms. Ansonsten mache ich nichts mit Banking und die Programme laufen dennoch. Ist wohl mit der Einführung der Midrange-PICs so wie z.B. meines geliebten PIC18F14K22 nicht mehr nötig. War ja voll der Horror vorher. Gut, meine Progs sind in der Regel kurze, das spielt sicher auch eine Rolle. Die passen wohl alle noch in eine Bank rein. Aber die sind wohl auch größer geworden. Wie auch immer....

Zum zweifachen RABIF-Löschen (2RL): da ist was Putziges passiert und das bedarf in der Tat einer Klärung. Zum Einen stammt dieses 2RL noch aus der Experimentierphase, als ich noch nicht "der Checker" war! Da hatte ich das doppel-gemoppelt...., "zur Sicherheit". Zum Anderen hatte ich das irgendwann schon selbst bemerkt und korrigiert, als ein Doppel gekillt. Aber in den Programmen ist es wieder aufgetaucht, was ich nicht verstehen kann. Da läuft was schief, und was genau, ist noch ungeklärt.

Auf der Festplatte meines Arbeits-PCs - damit ist nicht derjenige gemeint, von welchem ich gerade schreibe - ist die neueste Version des "Libre Office" installiert. Diese neuesten Versionen sind von den Herausgebern als "eventuell noch nicht stabil" bezeichnet. Bislang hatte ich da nie Probleme, aber jetzt schon. Da ist gestern sowas Seltsames passiert, dass dieses auch hier veröffentlichte Prog "IRQ13" in der MPLAB X IDE v5.20 sehr  sauber und gut zu sehen ist, aber vom Libre Office nur in einer "verkürzten Version" dargestellt wird. Auch im Ausdruck durch LO wird das verfälscht. Wenn ich danach das gleiche Prog-Listening - ein asm.File - mit z.B. "Wordpad" öffne, passt wieder alles.
Da ist irgendwas mit dem Speichern und der Darstellung dieser Progs durcheinander geraten. Daher sind wohl auch noch ältere Versionen übermittelt worden. Das Alles muss ich heute mal versuchen, zu ordnen und zu klären. Wahrscheinlich werden die 4 Programme nochmal neu eingestellt werden müssen. Watt'n Mist, dabei hatte ich mit deren Überarbeitung - damit es hier im Forum einigermaßen vernünftig aussieht - recht viel Aufwand getrieben.
Grüße, picass

Hallo, ich bin noch von der alten Schule . Muss man bei den neuen Controllern nicht mehr die Bank umschalten? Was mir auch aufgefallen ist, das Du beim Verlassen vom HI Interrupt nicht RETFIE,FAST schreibst, dann werden die geretteten Register sofort zurückgeschrieben. Im LO Interrupt (welchen ich nie benutze) müssen die Register von Hand gesichert und zurückgeschrieben werden. Hat es eigentlich einen Grund warum du im Interrupt zweimal RABIF löscht? Dann schaltest Du auch oft den Interrupt aus, warum?

Bei meinen Programmen, welche etwas größer sind, frage ich im Interrupt ab wer ihn ausgelöst hat und ob dieser auch eingeschaltet war (RABIE,  RABIF) und setze nur hier im Interrupt das IF Bit zurück.

Viele Grüße
Pic18

Mein angekündigtes kleines Kompendium über Interrupts beim PIC18F14K22

Am besten Beginnen mit dem Prog ,,IRQ13". Das enthält alles, um den PIC via Tastendruck an Port-Pin RA2 via IRQ aus dem Schlummer zu holen. Eine grüne und eine blaue LED dokumentieren, dass sowohl die IRQ-Routine ,,besucht" wurde, als auch der spätere Arbeits-Teil des Progs. Dies war dann der IRQ-High.

Für eine IRQ-Low Routine – im Prog ,,IRQ14" – wird dasselbe Prog wie vor genommen, zusätzlich zum ,,GIE"-Bit im INTCON Register noch das ,,GIEL"-Bit gesetzt. Räusper..... das ,,GIE"-Bit wird dann richtigerweise als ,,GIEH"-Bit bezeichnet. Ist aber noch dasselbe. Zusätzlich gibts noch eine Änderung: Das Bit Numero ,,0" im INTCON2-Reg, genannt ,,RABIP", wird auf ,,0" gesetzt. Das bringt dann zusammen mit dem ,,GIEL"-Bit gemeinsam den Unterschied zwischen High- und Low-IRQ.

Gar keinen Interrupt braucht man, wenn man – wie in Prog ,,IRQ15" – nur das Aufwachen aus dem Schlummerzustand benötigt und zudem nur ein oder zwei Ereignisse für das Aufwecken in Frage kommen. Dann braucht man  nur gesamt zwei Einstellungen:
1.) wie üblich muss auch hier der fragliche Port-Pin für IRQ freigegeben werden, was für den genannten RA2-Pin mit dem Befehl ,,bsf IOCA,2" geschieht.
2.) Im INTCON-Reg muss das Bit RABIF freigegeben werden, am besten direkt vor dem sleep-Befehl. Das wars.

Das Prog ,,IRQ16" ist fürs Experimentieren gedacht. Da sind sämtliche evtl. benötigten Elemente, rsp. Befehle vorhanden und müssen nur jeweils aktiviert oder durch Semikolon ausgebremst werden. Das soll nur Tippen einsparen.

Bitte beachten: in diesem Programmen wurde ausschließlich der Aspekt des Interrupts, rsp. Aufwachen ohne IRQ bedient. Zu beachten ist, dass es Erweiterungen gibt, z.B. die Berücksichtigung der Flanken-Richtung beim INT0, INT1 und INT2 an PortA. In meinem Beispiel reagiert der PIC auf jede Flanken-Änderung.
Ach ja: Vorsicht vor ,,vereinfachten" Schreibweisen. So kann es zu wenig gewünschten Überraschungen kommen, wenn man anstelle des Doppelbefehls – movlw b'00001000' und – movwf INTCON dann lieber abkürzen möchte und schreibt: - bsf INTCON,RABIF. Das kann lustig werden, wenn vor diesem Befehl schon ein Bit-Änderungs-Befehlt stand, also Obacht.

Im Anhang sind alle Hex-Files sowie die ASM-Files, erstellt mit MPLAB x IDE v5.20
Grüße, picass

@ITSME
Ein Gast!
Sehr erbaulich, dass es ,,da draußen" jemanden gibt, welcher meine Nöte nachvollziehen kann. Übrigens: etwas Spott wäre durchaus angebracht und tolerierbar gewesen.

@pic18
Sehr herzlichen Dank für deine Bemühungen. Die knöpfe ich mir Anfang der Woche im Einzelnen vor. Für heute nur in Kürze: Das Gestrampel mit dem ,,Banking" ist heuer nicht, rsp. nur noch selten notwendig. Aber dazu später. Und zum Simulieren möchte ich dir gerne noch verhelfen. Auch später....

Heureka! Oder auch: das Licht ist auf mich gekommen!
Nein, ganz sicher nichts Heiliges, obgleich noch Ostern herrscht. Hat eher mit höchst irdischer Anstrengung zu tun, z.B. dem vierzigsten Male des Studierens des IRQ-Kapitels im Datenblatt: Gerade eben vor 30 Minuten ist es mir erstmals gelungen, den gordischen Knoten des Interrupts zu zerschlagen. Nunmehr sind mir 4 Programme gelungen, alle sehr kurz, alle komplett identisch – also fast – und sie unterscheiden sich nur in Interrupt high, Irq low, Aufwachen portchange ohne irq und ein Vorlagen-Prog zum Experimentieren mit all dem. Die stelle ich in den nächsten Tagen hier ein. BIS HEUTE war mir das Alles nicht klar! Aber nu' strahle ich im Glanze der Erleuchtung. Ich weiß, ist nur reine Grundlagentechnik , aber die hat mich verdammt viel Zeit und Ärger gekostet. Das Licht hat die schier endlose Dunkelheit  verdrängt......
Grüße, picass

Zitatimmer das ,,RABIF" gesetzt

Meinst Du RBIF? Das setzt Du mit:

BCF INTCON,RBIF,ACCESS

zurück.
Du kannst auch den Interrupt ausschalten, in dem Du das Bit RBIE löscht.

alle Interrupts schaltest Du mit

BCF INTCON,GIE,ACCESS

ab. Damit werden alle Interrupt abgeschaltet, auch der low-priority-Interrupt abgeschaltet, da war früher im Datenblatt immer ein Fehler. Ich habe das in C auch schon in einer While Schleife gesehen, glaube aber nicht, das das nötig ist.

Zitatclr INTCON eingeben

evtl. musst du hier noch die BANKED bzw. ACCESS (1..0) eingeben. So etwa:

CLRF INTCON,ACCESS

ich meine wenn du das ACCESS (0) weglässt, dann wird immer BANKED (1) als default angenommen. Dann musst Du BSR mit MOVLB auf 0 setzen.

deswegen kannst Du wahrscheinlich auch den Ausgang nicht setzen. Das TRIS-Bit muss natürlich auch auf Ausgang (0) gesetzt sein. Kennst Du den Befehl BTG? (BTG f,b[,a]) dieser lässt den Ausgang immer drehen (toogle). Damit kannst Du leicht eine LED aufblinken lassen.

Zitatmit dem Befehl: movf PORTA,0 (Speichern in W)

MOVF  f,d,a
d= destination W(0) F(1) hier ist default wahrscheinlich auch F, was bedeutet das der Wert nicht nach W sondern nach F (wo dieser schon steht) geschrieben wird.
a= wieder ACCESS (1) oder Banked hier wird wieder bei default wahrscheinlich Banked angenommen

der ganze Befehlssatz gilt natürlich beim PIC 18F....

Mit dem Simulator bin ich noch nie klar gekommen. Ich benutze einen Bootloader und dann verirrt sich der Simulator. Ich müsste dann jedes mal die Zeiger ändern.