@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

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

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

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

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