Immer wieder beliebt: wie gehe ich mit den IRQ-Registern und Befehlssätzen um?
Meine Frage: Kann ich das Gefummel in dem von mir beabsichtigten Fall weitestgehend ignorieren, rsp. ganz einfach halten?
Die Lage: In dem "Zentral-Steuer"-PIC befindet sich der µC nahezu immer im Sleepmodus und soll aufgeweckt werden durch einen von vier externen Ereignissen, die allesamt je eine Änderung eines Port-Eingangs bewirken. Nach dem Aufwecken soll er die 4 Port-Pinne abfragen und dann entsprechend was tun, aber nur kurz, danach ist wieder Tiefschlaf angesagt.
Wenn ich mir nun das Microchip Datenblatt für den PIC18F14xx anschaue (S.61), dann ist der Zweig der Weiterleitung einer Portänderung ein erfrischend kurzer und führt ausschließlich über 3 OR-Gatter zum Erfolg: dem Aufwachen. Das nehme ich nun mal wieder ganz wörtlich und interpretiere das so, dass es völlig unnötig ist, wenn man lediglich das Aufwachen - und damit verbunden natürlich das Weiter-Abarbeiten der folgenden Programmschritte - bewirken will, das ganz Gefummel mit dem Setzen diverser IRQ-"Vorraussetzungen" vorzunehmen? Nach meinem ersten Verständnis wäre nicht mal das Setzen des Haupt-IRQ-Bits - des GIE, also bit 6 oder 7 im INTCON - nötig. Für den jeweiligen Port und auch individuell für jeden der 4 Pinne muss natürlich der IRQ freigegeben werden, aber sonst nichts?!
Grüße, picass
Ja, sieht so aus, als müsste man nur IE, IP am ersten AND, sowie das was unter (1) noch steht entsprechend einstellen.
IF wird man aber wohl löschen müssen.
Probier es doch einfach aus ;-)
Ich kämpfe zum wiederholten Male meinen Lieblings-Horror-Kampf, den gegen Interrupts.
Wieder Grundlagenforschung am lebenden Objekt, hier dem "PICkit low pin count demo" Board! Da ist ein Schalter drauf, dessen Ausgangssignal im Ruhefall via einem R auf 5 V liegt und an Port A2 führt. Dann noch 4 LEDs an Port C und das wars.
Im Programm existieren quasi nur zwei Schleifen. Die zuerst Angetroffene lässt eine LED blinken und soll den Zustand ohne IRQ anzeigen. Die andere, die zweite Schleife ist dann natürlich für den IRQ-Fall vorgesehen und wird - wie üblich - von der Speicherstelle 0008h des PICa8F14K22 angesprungen und lässt eine andere LED blinken.
Is klar, das war die Theorie: in der Praxis wird die erste Schleife einmal durchlaufen und dann gehts ohne Tastenberührung sofort in die IRQ-Routine! Es hilft auch nichts, gleich am Anfang des Progs eine Sekundenpause einzulegen, damit sich die Hardware ggf. "aneinander gewöhnen" kann und danach erst den IRQ frei zugeben. Kaum ist er das: schwupps und ruptus, alles ohne T-Druck.
Mittlerweile habe ich nach der ersten IRQ-Routine das den Interrupt anzeigende Flag-Bit zurück gesetzt, bzw. das im Prog installiert, dann funktioniert auch bis auf den ersten Durchlauf alles, wie gewünscht: nur bei T-Druck wird in die IRQ-Routine verzweigt, ansonsten läuft die andere.
Aber dennoch dürfte der PIC nicht ohne Tasten-Druck einfach interrupten, das gehört sich nicht! Dass auch hier der Portpin irgendwelchen Störimpulsen unterliegen könnte und wieder erst ein 1 µF Tantal - wie bei meiner Garagentor-Schaltung - den still legen muss, mag ich mir nicht vorstellen. Klar, probiere ich aus, dürfte aber nicht sein. Ach ja: bei diesem PIC-Typ löst nicht eine bestimmte Port-Änderung den IRQ aus, das lässt sich nur für andere Peripherie einstellen, bei Portänderungen ist die Flanke wurscht, es klappt - leider - mit allen.
Grüße, picass
Wenn wir doch nur alle funktionierende Glaskugeln hätten ;-)
Überspringst du beim Start den Interruptvector?
Hallo Volker!
Bin gerade etwas abgelenkt, siehe andere Beiträge. Aber morgen kümmere ich mich wieder um den I! Die Nebel müssen endlich weg. >:(
Grüße, Bernd
Ähm....: wie überspringt man einen IRQ-Vektor?
Das Programm beginnt mit den üblichen Initialisierungen und wenn das rum ist, springt es von ORG Ox0000 zum Beginn der eigentlichen Arbeitsroutine. Dort ist erst eine Schleife, die eine LED befeuert, dann erst wird der IRQ freigegeben. Weil es der Globale IRQ ist, lautet dessen Start-Adresse: ORG 0x0008. Von dort sollte es üblich zu einer IRQ-Routine gehen, das habe ich aber geändert und das Prog springt von 0008 direkt in eine zweite Schleife, in welcher eine andere LED beleuchtet wird. Dann wird der IRQ disabled, das ensprechende Flag abgefragt und dann wieder in die erste Schleife gesprungen.
Inzwischen habe ich meine geliebte Sleep-Routine eingearbeit. Irgendwie klappt das sogar: nach erstem Gewusel findet kein Leuchten mehr statt, die LEDs und der Rest sleepen offensichtlich. Drückt man die Taste, gibts die Erweckung und eine Ehrenrunde mit Erleuchtung, dann wieder Schlummern.
Damit könnte ich mich zufrieden geben, is aber nicht so. Was mich verwirrt ist, dass der PIC nach dem Einschalten seltsame Wege nimmt. Er durchläuft die erste Schleife, dann durchläuft er die zweite Schleife ohne dass ein IRQ stattgefunden hätte, und dann erst bequemt er sich zu ordnungsgemäßem und erwartetem Arbeiten.
Sowas fiehl mir in letzter Zeit auch bei meinem "Garagen-PIC" auf. Nach dem ersten Einschalten macht er Quatsch, er reagiert z.B. falsch auf Tastendrücke oder reagiert gar nicht drauf. Erst dann, wenn er eine Runde geschafft hat, in dem Fall einmal das Garagentor komplett bis zur Endposition gezogen und dann - was er nicht sollte - wieder gleich retourniert hatte, dann erst macht er alles, was er soll.
Er gönnt sich eine erste Runde Eigenwilliges, so wie jetzt auch der PIC im kurzen Interrupt-Testprog. Ich starre auf das kurze Listening und sehe nicht, was der Grund für die Fehlläufe beim ersten Mal sein könnte. Und ein Entstörkondensator, welcher beim Garagen-PIC den Durchbruch brachte, ist es hier nicht, der zeitigt keine Auswirkung.
Grüße, picass
Das hört sich ein bisschen konfus an ;-)
Das Programm beginnt immer an der Adresse 0x00.
Falls man den IR-Vector verwendet, muss man diesen gleich am Start überspringen um zur Initialisierung zu gelangen.
Hier mal ein leicht modifizierter Code aus den mitgelieferten Templates:
;------------------------------------------------------------------------------
; RESET VECTOR
;------------------------------------------------------------------------------
RES_VECT ORG 0x0000 ; processor reset vector
GOTO INIT ; go to beginning of program
;------------------------------------------------------------------------------
; HIGH PRIORITY INTERRUPT VECTOR
;------------------------------------------------------------------------------
ISRH ORG 0x0008
; Run the High Priority Interrupt Service Routine
GOTO HIGH_ISR
;------------------------------------------------------------------------------
; LOW PRIORITY INTERRUPT VECTOR
;------------------------------------------------------------------------------
ISRL ORG 0x0018
; Run the High Priority Interrupt Service Routine
GOTO LOW_ISR
;------------------------------------------------------------------------------
; HIGH PRIORITY INTERRUPT SERVICE ROUTINE
;------------------------------------------------------------------------------
HIGH_ISR
; Insert High Priority ISR Here
RETFIE FAST
;------------------------------------------------------------------------------
; LOW PRIORITY INTERRUPT SERVICE ROUTINE
;------------------------------------------------------------------------------
LOW_ISR
; Context Saving for Low ISR
MOVWF W_TEMP ; save W register
MOVFF STATUS, STATUS_TEMP ; save status register
MOVFF BSR, BSR_TEMP ; save bankselect register
; Insert Low Priority ISR Here
; Context Saving for Low ISR
MOVFF BSR_TEMP, BSR ; restore bankselect register
MOVF W_TEMP, W ; restore W register
MOVFF STATUS_TEMP, STATUS ; restore status register
RETFIE
;------------------------------------------------------------------------------
; INITIALIZATION
;------------------------------------------------------------------------------
INIT
; Insert User Initialization Here
;------------------------------------------------------------------------------
; MAIN PROGRAM
;------------------------------------------------------------------------------
MAIN
; Insert User Program Here
GOTO $ ; loop program counter
END
Besser wäre natürlich noch keinen absoluten Code zu verwenden,
sondern das was man im Ordner mit den "relocatable" Templates findet:
;------------------------------------------------------------------------------
; RESET VECTOR
;------------------------------------------------------------------------------
RES_VECT CODE 0x0000 ; processor reset vector
GOTO INIT ; go to beginning of program
...
Mal abgesehen davon, dass Peter und vloki Dir die Interrupt- Verwendung schon beschrieben haben: Suchst Du noch nach der Lösung des SLEEP- Problems?
Wenn ja, dann habe ich mal einen Test für Dich programmiert.
Da ich nur einen PIC18F24K22 zum Testen habe, musste ich für Deinen PIC18F14K22 das Programm anpassen ohne Testen zu können. Ich hoffe, ich habe alles richtig gemacht.
Programmablauf:
- Register- Initialisierung
- :Schleifenbeginn
- 3x blinken
- PORTA lesen in Tempvar, um den aktuellen Status zu haben (ohne Lesen geht es nicht!)
- INTCON-Bit löschen
- Sleep
- GOTO Schleifenbeginn
Statt Tempvar kann man wohl auch in ein unbenutztes Register R0...Rxx schreiben.
Nach 3x Blinken geht der PIC in den SLEEP und kann per Tastendruck aufgeweckt werden. Ein "richtiger" Interrupt wird nicht ausgeführt, lediglich das INTCON-Bit wird benutzt/ausgewertet.
Da ein Pin-change sowohl bei H/L als auch bei L/H erkannt wird, kann man auch den Taster nach dem Aufwachen festhalten bis zum nächsten Sleep und dann loslassen.
Hier das Programm in mBASIC:
program Sleep
' PIC18F14K22 @ 1MHz INTOSC (default)
' Test des SLEEP- Modus
' Taster an PORTA.2
' LED an PORTC.0
' Funktion: 3xblinken -> Sleep -> aufwachen und von vorn beginnen
Dim Tempvar as Byte ' Hilfsvariable zum Lesen/Aktualisieren
' 1x blinken: 0,5sec ein, 0,5 sec aus
sub procedure blink()
LATC.0 = 1
delay_ms(500)
LATC.0 = 0
delay_ms(500)
end sub
main:
' Main program
clearbit(INTCON, 0) ' RABIF-Bit löschen
setbit(INTCON, 3) ' RABIE Interrupt enable
setbit(IOCA, 2) ' Pin A.2 als Interrupt-On-Change aktivieren
TRISB = 255
TRISC = 0 ' Output
PORTC = 0
ANSEL = 0 ' PORTA digital setzen
Schleife:
blink()
blink()
blink()
Tempvar = PORTA ' PORTA lesen, ist wichtig!
clearbit(INTCON, 0)
Sleep
goto schleife
end.
Im Anhang gibt es das Prog. sowie ASM- und HEX-File.
Gruß
PICkel
Sleep.zip
Ne, Jungs, da habt ihr was missverstanden. Meine Programme starten alle so wie in dem Beispiel von Volker ausgeführt: von 0x0000h springt es zum "normalen" Programmablauf, im Falle eines IRQs wird 0x0008h angesprungen und von dort zur IRQ-Routine oder - testweise - zu einem extra Programmteil.
Seit heute Mittag ist meine IRQ-Phobie Geschichte: das Aufwachen aus dem Sleep-Modus funktioniert gänzlich ohne die üblichen IRQ-Befehle. Es werden tatsächlich nur die drei Bits, rsp. Flags benötigt, welche der Auszug aus dem Databook - siehe erster Beitrag und auch nochmal hier - beschreibt. Eine IRQ-Routine wird damit überflüssig, ebenso wie IRQ-Vektoren.
Grüße, picass
Na, dann war wohl mein Betrag von 15:23 Uhr zu spät.
Vielleicht hift's jemand Anderem.
PICkel
Zitat von: picass in 30.06.2022, 15:44:29 CESTNe, Jungs, da habt ihr was missverstanden...
Ja, die "üblichen Initialisierungen". Darunter hatte ich wohl die Konfiguration von Pins als Ein- oder Ausgänge.
Einstellungen für diverse Peripheriemodule etc., also Programmcode verstanden.
Schlechte Glaskugel eben ;-)
Zitat von: PICkel in 30.06.2022, 15:23:36 CESTSuchst Du noch nach der Lösung des SLEEP- Problems?
Wenn ja, dann habe ich mal einen Test für Dich programmiert.
Ich hoffe, ich habe alles richtig gemacht.
Auch du, mein Sohn, hast es nun gerafft, also das mit dem Sleepen.
Habe gerade mal dem Wunsch entsprechend getestet: bei TA-Druck leuchtet es, ansonsten wird gepennt.
Grüße, picass
ICH HASSE INTERRUPTS !!!
Habe zwei Tage des Kampfes dagegen hinter mir. Es funktioniert nun zwar, aber manchmal ist Assembler voll der Horror! Zumal sich das Wichtigste von Allem im Datenblatt in einer Fußnote versteckt!
Eigentlich habe ich eigene Vorlagen und auch die funktionierenden Beispiele im Beifang des ,,PICkit Low Pin Count Demo"-Boards mit seinen 13 Musterprogrammen. Eigentlich....... Aber wehe, man möchte z.B. aufgrund abweichender Hardware was ändern oder es kommt noch was Niedliches ins Programm dazu wie der Versuch, diejenige Taste, welche den Interrupt-On-Cange Port bedient, entprellen zu wollen. Voll der...., aber das wurde schon gesagt.
Der Ärger beginnt schon damit, dass laut Simulator noch während der Port-Einstellungen gleich zu Anfang ein Interrupt angezeigt wird, der noch gar nicht stattgefunden hat. So wurde immer das ,,RABIF" gesetzt, das seine Fahne hebt, wenn ein Interrupt durch Port-Change stattfand. Und dieses verdammte Flag lässt sich auch nicht einfach löschen. Da kann man ruhig als Befehl: clr INTCON eingeben, wonach theoretisch alles auf Null sein müsste. ,,RABIF" hebt weiter die rote Fahne!
Letztlich lag es an der ,,Missmatch"-Kondition, welche das Löschen nicht zulassen will. Im Kleinst-Gedruckten findet sich das mit dem Missmatch. Also einmal den fraglichen Port lesen, z.B. mit dem Befehl: movf PORTA,0 (Speichern in W) und dann endlich senkt sich die Flagge – sofern man direkt gleich den Befehl fürs Flaglöschen folgen lässt.
Drollig wirds beim Tastenentprellen, wenn man in tagelangen Kampf zermürbt durch ständige Programmänderungen ist. Die Funktion des Progs – also das Millisekunden Aufblitzen der IR-Sendediode – lässt sich ja nicht mal mit einem Oszi so ohne weiteres verfolgen. Also dafür eine Normalo-LED in visible Rot einbauen und über den Nachbarport ansteuern. Ansteuern....., is klar:
Bit-Set-File Port-Pin, also z.B. bsf LATC,0. Also hantiert man wegen der dauernden Nichtfunktionen: mal will der PIC nicht aus dem Sleep-Modus raus, mal läuft er sofort durch, mal hängt er sich im hinteren Teil des Progs auf, anscheinend manchmal alles aufeinmal. Dauernd wird der Kontrollteil verlagert, und wieder nix. Bis man irgendwann entdeckt, dass beim dauernden Hantieren mit dem LAT-Befehl dieser zur Abfrage eines Ports ja weniger gedacht ist. Also stattdessen READ! Is klar, wenn man den Fehler gefunden hat, ist es sowas von klar und ebenso dürfte klar sein, dass andere – also DU oder auch du – da nicht gestolpert wären. Mich hats zwei Tage gekostet, und die Freude über die Endlich-Funktion hält sich in überschaubaren Grenzen.
Grüße, picass
Zitatimmer das ,,RABIF" gesetzt
Meinst Du RBIF? Das setzt Du mit:
BCF INTCON,RBIF,ACCESSzurück.
Du kannst auch den Interrupt ausschalten, in dem Du das Bit RBIE löscht.
alle Interrupts schaltest Du mit
BCF INTCON,GIE,ACCESSab. 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,ACCESSich 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.
@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! ;D
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 :o . 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 >:D , 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
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
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
Staub-Ventilator.jpg
Verrückt was da alles zusammen spielen kann.
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