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

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