Die kurze Antwort: die Subtract-Routine ist ein Teil einer Schleife, welche solange durchlaufen wird, bis der Wert der Subt. negativ ist. Dann wird ausgesprungen und es geht zur Anzeige. Aber nicht der genannte Wert wird benötigt, sondern der Stand des Rundenzählers in der Schleife. Mit dessen Wert wird jeweils in die beiden im EEProm abgelegten Tabellen eingesprungen.
Die andere Antwort: das gesamte Prog geht recht manipulativ ans Werk. Zwar wird am Eingang via ADC ein der Temperatur im Dieselpartikelfilter entsprechender Spannungswert eingelesen, aber schon am Anfang nicht wirklich als solcher verwendet. Dazu müsste man eine Formel mit den Sensor-Eigenschften haben. Die gibt es auch, aber zum einen lässt die sich schon auf dem Papier nicht so auflösen, dass der eingelesene Spannungswert zur Anzeige genutzt werden kann, noch wäre ein Acht-Bitter unter Assemblerprogrammierung dazu in der Lage. Und ich auch nicht.
Also werden in mehreren Stufen so was wie Analogien benutzt, um zu einer Anzeige zu kommen. Ein bißchen um vier Ecken rum, aber das ist wenigstens machbar. Also keine direkte Nutzung und Durchreichung von (Spannungs-) Werten.

Was nun hat gestern den Erfolg gebracht?
Nächste Frage, ich weiß es nicht. Weder habe ich einen krassen Fehler gefunden, noch etwa eine von sich ändernden Bedingungen abhängige temporäre Unzuverlässigkeit entdeckt. Der Erfolg trat ein, weil ich gestern nochmal Grundlagenforschung betrieb, das Hauptprogramm – Obacht: wirklich nur dieses mit nur drei der sonst 10 Seiten – ausdruckte und dann jedes Wort auf dem Papier umdrehte und sofort am Compi eine sich anbietende vermeintliche Verbesserung, rsp. Änderung ausführte.
Da wurde zunächst die lange Liste der deklarierten Variablen ausgemistet, dann wurden die Variablen einzeln mittels Suche im Prog aufgerufen und alle Positionen kontrolliert, da wurden an mehreren Stellen Vereinfachungen vorgenommen, sprich: Umständliches eliminiert, da gab es kleine, aber wohl unnötige Verbesserungen, z.B. wurde an zwei Befehle noch ein Index angehängt, obgleich per Datenblatt auch ohne das die Funktion ,,per default" vorgenommen würde. Is klar, die Subtr.-Routine wurde zum zigsten Male auseinandergenommen und wieder zusammen gesetzt. Allerdings blieb sie im Kern/von der Systematik her unverändert. Zudem wurden die Kommentare angepasst und erweitert für später mal. Der papierne Ausdruck war teilweise mit roten Markierungen reichlich bedeckt, aber nochmal: einen echten Fehler konnte ich nicht entdecken.

Ganz fertig ist das Prog noch nicht, es fehlt z.B. noch die Bearbeitung für das Überschreiten des gewünschten Messbereiches. Da springt im Moment die Anzeige zwischen dem korrekten und einem anderen Wert. Aber wenn ich bis hierher gekommen bin, wird das auch noch werden. Ist ja auch nicht als neues Problemfeld ausgemacht, sondern nur schlicht noch nicht bearbeitet. Und – ach ja – die Piepser-Funktion muss noch rein. Da soll ja noch so'n kleiner Krachmacher integriert werden, welcher den Beginn einer Regeneration LAUT verkündet.

Aber ein Segen, dass nach den schier endlos langen Tagen an Bemühungen nun die Ziellinie überschritten werden konnte. Mehrfach hatte ich ans Hinschmeißen gedacht. Nun muss sich das Alles erst mal wieder beruhigen, schließlich warten noch andere Projekte auf der berühmten Bank.
Grüße, picass

was genau machst Du eigentlich mit der Subtract-Routine. Warum mußt Du das Ergebnis nicht sichern?

N'en paar Minuten später dieses:
Am Ende des Progs wurde nun anstelle von sleep eine Dauerschleife eingerichtet: also ein kompletter Durchlauf, wobei es zum Anzeigen eines Wertes kommt wie auch zu erwarten zum Abspeichern der Verlaufs-Variablen, und danach nur noch Dauerlauf auf der Stelle, ohne irgendwas zu verändern.

Und dabei zeigt er nun nach je einem Durchlauf ALLES an möglichen Zahlenwerten an, also auch problemlos oberhalb von 440 - das war die bisherige Obergrenze, ab der nur noch 950 gezeigt wurde.
Daraus würde ich nun schlussfolgern wollen, dass sämtliche Programmfunktionen in Ordnung sind, aber nur einmal. Beim wiederholten Durchlauf wird irgendwas, wenn nicht alles über den Haufen geworfen.
Ein Schritt vor der Ziellinie, welcher Schritt ist der richtige?
Grüße, picass

Am Poti liegt es nicht und kann auch nicht. Erstens hatte ich gemessen: da springt nichts. Zweitens könnte es nur ein Minisprung sein, weil im Spannungsteiler für den ADC der Wert des Potis nur ein sehr geringer ist - für die hohe Auflösung - und der Wert der beiden Festwiderstände "oben" und "unten" erheblich größer ist.
In der Subtract-Routine darf das Ergebnis in das WREG-Register, in der Variablen eeplow/high muss nichts gespeichert werden. Entscheidend für den Fortgang des Progs ist der Wert des Rundenzählers, welcher die Position der beiden Tabellen im EEProm vorgibt. Die Rechenroutine selbst habe ich mehrfach überprüft. Bislang war mir kein Rechenfehler aufgefallen....

Das kann jetzt nur noch Sabotage sein. Auch mein letzter ultimativer Rettungsweg ist gescheitert. Nachdem ich jüngst festgestellt hatte, dass entgegen meiner vorigen Annahme bei HW-Debugging doch der EEProm-Inhalt angezeigt werden kann, entwickelte sich dieser Plan ,,um zwei Banden rum":
Zunächst wurden dem Prog mehrere gleichartige Routinen implementiert, die dafür sorgten, dass an markanten Stellen der aktuelle Wert interessierender Variablen ins EEProm gespeichert wurde....., es war ,,hinten" gerade noch Platz für 10 Bytes. Das wurde natürlich im Soft-Sim (SS) getestet und funktionierte prima. In einen papiernen Ausdruck wurden für den kritischen Grenzbereich – klappt noch, klappt nicht mehr – alle Werte zusätzlich eingetragen, alles gut bis dahin.

Dann wurde es ernst: Zunächst den PIC mit einem Prog befüllen, ihn dann ganz normal – also auch mit der adc-Messung – laufen lassen, aber nur einen Durchlauf (DL) zulassen und am Ende des DLs eine Sleep-Anweisung anbringen. Der eine DL würde reichen, alle Funktionen auszuüben und am Ende im neuen, zusätzlichen EEProm-Bereich quasi die Dokumentation des Verlaufs abgespeichert zu haben.

Danach wurde das  Prog nur insofern verändert, dass gleich beim Beginn der Hauptroutine ein Stopwatch eingelegt wurde. Also dieses Prog dann gleich mit dem HW-Degugger aufzurufen, sollte bewirken, dass dieses ,,neue" Prog halt auch nur bis zum Anfang laufen würde, somit noch keinerlei Änderungen von Variablen und auch kein Überschreiben im EEProm stattfinden würde. An dieser Stoppstelle nun sollte der Inhalt des EEProms mit dem neuen Bereich Auskunft über den vorigen Ablauf geben.

Alles klar, jedenfalls in der Theorie. Beim Aufruf des EEP-Inhaltes wurde dieser nicht angezeigt. Keine Ahnung, warum, auch das sonst mögliche Aktualisieren des Inhaltes über ein entsprechendes Symbol innerhalb dieses EEP-Anzeigefensters brachte nichts.

Das ist jetzt die Deprise numero 25! Warum zum Henker sträubt sich die MPLAB-Umgebung (MU), das zu zeigen, was sie wenige Minuten vorher noch getan hatte? Zeitgleich klappte manchmal auch das Anzeigen der Variablen nicht, obwohl das bislang immer geklappt hatte. Ist die bislang bewährte Vers. 5.20 irgendwie defekt? Oder doch nicht so bewährt?

Wenn ich mir die bislang investierte Lebenszeit so anschaue, frage ich mich, ob das noch passt.
Grüße, picass

ich arbeite hier mit MPLAB-X, benutze aber viele Funktionen wie den Simulator nicht. Mit der alten MPLAB-IDE konnte ich vom C-Programm den erzeugeten Assembler-code anschauen, also links das C-Programm und recht denn erzeugten Code. Diese Funktion habe ich im MPLAB-X nicht entdeckt. Auch benutze ich noch den alten C18 Compiler, da meine Programme sonst kompiliert werden.
Das mit dem Springen des Wertes klingt für mich wie wenn der Poti springt. Hast du mal die Eingangsspannung nach gemessen?
-oder kann es sein das das Ergebnis < 0 ist? Was für einen Wert gibst Du denn aus, den eep-Wert oder den adc-Wert?

Die Sub-Routine sollte eigentlich stimmen, du benutzt doch einen PIC18!? Der sollte den Befehl SUBWFB kennen. Probiers doch damit einmal.

    sub1:
    MOVLB eephigh ;Bank auswählen                
    movff  eephigh,sub      ;eephigh soll nicht überschrieben werden: sichern
    movf    adclow,W,BANKED      ;adclow in WREG
    subwf  eeplow,F,BANKED      ;eep minus adc (WREG),ergebnis in F-REG! -WREG?
    movf    adchigh,W,BANKED      ;adchigh in WREG
    subwfb  eephigh,F,BANKED    ;eeprom minus adc (WREG),ergebnis in F-REG! - WREG?

    return 

was mir jetzt aufgefallen ist, Du schreibst das Ergebnis jedesmal ins W-Register, muss das Ergebnis nicht ins F-Register eep. Oder willst Du nur den Wert vergleichen? Dann kann es sein das Du das C bzw. N - Bit vor der Hi Subtration löschen mußt. So kenne ich es noch vom 6510 Motorola.

Pic18, du bist ja voll der Liebe! Dass du dir soviel Zeit nimmst, um in eine Materie rein zu schauen, welche nicht zu deinem üblichen Tageswerk gehört, ist 'ne ganz feine Sache. Wenn Hilfe von Nöten ist, bist du da! Das war der freundliche Teil   und nun zum anderen!

Stichwort: Banking. Man merkt und sieht auch an deinem Beispiel, dass du in der Tat da länger nicht mehr in der Materie steckst. Mit dem MPLAB X, der ja auch nicht mehr die neueste Entwicklungsumgebung darstellt, ist vieles geändert worden – auch der Umgang mit dem Banking. Früher mal war das voll der Horror: andauernd in den Datenblättern rascheln und nur ja keine falsche Bank wählen. Das ist heute mit dem X nicht mehr so verkniffen. Bei den SFR's, also den tagesüblichen ,,Befehlen", braucht man gar nichts zu machen. Die liegen allesamt  in einer Bank, der Numero 15, und bei diesen SFR's kann man sogar das Benennen der Bank unterlassen. Der Assembler ist ein schlaues Kerlchen und kombiniert sich da was Richtiges zusammen.

Stichwort: Wandelzeit für den ADC. Das ist auch recht unkritisch. Der braucht mindestens 1,7 µS, dann passt es. Meine PICs haben da kein Prob, weil ich meine Steuer-PICs mit nur 31kHz betreibe, da passt es immer. Zudem hatte ich mir das Leben leicht gemacht und die komplette Beispiel-Routine fürs ADC-Einlesen aus dem Datenblatt kopiert und übernommen. Zudem-Zwei: würde da was nicht passen, gäbe es häufiger zufällige, divergierende Ergebnisse. Das ist aber bei meinem Prob nicht der Fall: es gibt nur immer ein- und dasselbe Ergebnis und dessen Eintritt ist auch immer steuerbar.

Stichwort: der ADC-Wert wird rechtsbündig ausgelesen. Passt. Und ja: adc ist eine Kopie von ADRES

Stichwort: die übersandte Subtraktions-Routine. Ok, dass ,,Retten" des High-Register kann und sollte man auslassen, das stammte noch aus einem früheren Prog. Aber man merkt, dass du das Beispiel nur ,,beblickt" hattest, denn den Pferdefuß konntest du so kaum entdecken. Ich hatte nicht umsonst angeregt, die zwei Rechenübungen auszuführen. Macht man das, sieht man bei der ersten  Variablen das Erwartete, bei der zweiten V die Sprengfalle: diese Sub-Routine entspricht zwar vielen Vorlagen aus dem Inet, aber die sind genauso fehlerbehaftet wie die abgebildete: die ist Murks hoch sowieso und liefert zu 50 % Fehler. Du hast vermutlich keinen Compi mit installiertem MPLAB X. Falls doch, mache den Versuch, es lohnt sich.

Der Riesenfloh ist aber noch immer nicht dingfest. Ich versuchs mal mit einer Grobskizze des Prog-Ablaufes:
(1.) Generell soll an einem Port ein analoges Signal im Bereich zwischen ca. einem und ca. zwei Volt eingelesen werden. (2.) Dieses Signals wird in eine Zählschleife (ZS) geschickt, in welcher geschaut wird, wann es von der Größe her mit einer anderen Variablen in etwa korreliert, die ihre Größe aus einer Tabelle im EEProm raus gelesen hat. Das kann sie, weil in der ZS eine weitere Variable ,,die Runden" mitzählt. (3.) Die beiden Variablen – adc und eep – werden in der vermaledeiten Subtractions-Routine verglichen und (4.) entsprechend verzweigt: entweder zu (5.) ,,höher" oder (6.) zur Anzeige.
Diese 6 direkt aufeinander folgenden Teile des Hauptprogrammes werden in einer Dauerschleife durchlaufen: passt es, wird angezeigt, passt es noch nicht, wird nach oben geswitscht. Weil diese Dauerschleife immer bei Null beginnt, muss nicht extra ,,runter"-geswitscht werden. Also fortwährender Dauerlauf.

Gettz bitte Konzentration, es folgen drei zu vergleichende PIC-Einsätze, deren Progs sich nur in einer Winzigkeit unterscheiden:

1.) Im Soft-Simulator (SS) wird nur das ADC-Einlesen manipuliert, der Wert muss natürlich vorher ins Prog gestanzt werden. Aber alles andere ist ,,original", also gleich dem Prog in dem µC. Und im SS klappt Alles! Da kann man für den ADC eingeben, was man will, hinten kommt immer was Richtiges raus.

2.) Dasselbe Prog nun in den PIC geschoben, wobei natürlich der ADC für normalen Betrieb freigeschaltet wird. Mittels Trimmer wird die Eingangsspannung im genannten Bereich variiert und raus kommt, dass von Null bis 450 (die Zahlen sollen Temperaturen repräsentieren) alles palletti ist, aber 'nen winzigen Tacken höher getrimmt und schon ist das Malheur da: es wird nur noch 950 angezeigt. Trimmt man wieder runter, passt alles wieder, es werden sinnvolle Temps angezeigt.

3.) Gettz die Version numero Drei, gestern frisch gefunden:
Packt man das im SS harmonierende Prog in den PIC – der ADC ist wieder deaktiviert und stattdessen ein passender Wert im Prog vorgegeben - und ruft den HW-Debugger (HD) auf, dann – Tusch – gibts Überraschendes. Für den HD wird im Prog ein einziger StopWatch implementiert und zwar ganz am Ende der Prog-Schleife, nachdem also die Anzeige gefüttert und komplett beschickt war. Ein Wunder: auch in diesem Modus macht der PIC brav alles, was er sollte. Er schluckt jedwede Zahlenvorgabe für den ADC und schietet hinten das exakt passende Zahlen-Triumvirat aus!!!
Aber ganz alleine, so ohne Compi-Verbindung, schlägt der Riesenfloh zu!
Gettz ihr! Wo ist der?
Grüße, picass

sorry, ich hab es noch einmal durchgeschaut, ist schon zu lange her, dass ich in Assembler prog. habe. BNN in Zeile 6 ist natürlich richtig
BC wäre auch richtig

ich habe mal kurz die Subtration angeschaut. BNN dürfte hier falsch sein. Hast Du auch das BSR  - Register entsprechend gesetzt? Hier mein Vorschlag, wenn alle Variablen auf der gleichen Bank sind. Warum Du eephigh zum Schluß zurückschreibst ist mir noch ein Rätsel.

sub1:
    MOVLB eephigh :Bank auswählen                 
    movff   eephigh,sub      ;eephigh soll nicht überschrieben werden: sichern
    movf    adclow,W,BANKED       ;adclow in WREG
    subwf   eeplow,W,BANKED      ;eep minus adc (WREG),ergebnis in WREG
    bnc     sub2             ;wenn positiv nach sub2
    decf    eephigh,F,BANKED          ;ist negativ: für nächsten substract negativer
                             ;übertrag in eephigh
sub2:
    movf    adchigh,W,BANKED      ;adchigh in WREG
    subwf   eephigh,W,BNKED     ;eeprom minus adc (WREG),ergebnis in WREG
    ;movff   sub,eephigh      ;eephigh zurück sichern
                             
    return  

ich kenne es noch so, ist aber im Prinzip das selbe

        movf    SourceL,W
        subwf   DestL
        movf    SourceH,W
        btfss   STATUS,C
        incfsz  SourceH,W
        subwf   DestH   

mal eine Frage: adc /low-hi ist eine Kopie vom ADRES Register? hast Du da bei ADCON2 ADFM auf rechts- oder linksbündig gestellt?
ist die Zeit hoch genug zu konvertieren des Anlogswertes?

Es ist zum Mäusemelken!
Die Schaltung arbeit nun wie erwünscht von null bis 450 - was Temperaturen anzeigen soll. In diesem Bereich kann man alles regeln und fein einstellen. Aber sobald man einen Tacken "höher" dreht, springt die Anzeige auf 950 und verharrt dort, egal, wie man weiter im  höheren Bereich regelt. Regelt man wieder nach "unten", also unterhalb 460, dann läuft es wieder.

Ein und dasselbe Prog läuft im Soft-Simulator (SS) einwandfrei. Im SS werden lediglich an zwei Positionen die Werte für den Eingang, also den ADC, vorgegeben, das Auslesen der passenden EEProm-Werte klappt - gleich für beide Tabellen, und somit zeigt der SS jedwedes "richtige" Ergebnis passend zum simulierten Eingangswert des ADCs. Das Ganze wieder zurück in den PIC und schon will der nur bis 450, danach beharrt er auf 950.
Watt'n Mist, dass der Hardware-Debugger quasi völlig untauglich ist. Weil der wohl alles abgeschaltet hat - sowohl den ADC-Eingang als leider auch das EEProm - ist der somit nutzlos.
Wieder mal die leere Menge. Kann sein, dass ich Abstand brauche, es fällt mir gerade nichts Sinnvolles ein.
@pic18 : hattest du schon Gelegenheit, die Subtractionsroutine zu beblicken?
Grüße, picass

Der CD4511 ist ein Klassiker, aber bitte: es ist nicht die Hardware, welche Probs bereitet, der Riesen-Floh sitzt in der Software.

Nachdem gestern Nachmittag erst mal ,,leere Menge" vorherrschte, fielen mir spätabends dann doch noch 8 weitere Test-Möglichkeiten ein. Etliche kamen heute zum Einsatz und wieder heißt es wie bekannt: die Hoffnung ....... zuletzt.
@pic18:
Du des Wahnsinns fette Beute hattest mir (wieder) angeboten, das störrische Prog hochzuladen und ggf. einen Blick drauf zu werfen. Davon würde ich nun doch mal Gebrauch machen wollen. Aber nicht das ganze Prog. Das ist schon ohne den Ausdruck des randvoll gefüllten EEProm-Bereiches ganze 10 Seiten  lang. Aber ein Schnipsel daraus wäre fein: eine Subtraktions-Routine. Die ist für 16-bit ausgelegt, wird aber nur mit 8-bit-Worten betrieben....: egal. Bitte wirf einen  Blick drauf. Im Zip-File ist alles drin: diese eine Routine, Text, ASM......, der ganze Ordner könnte sofort in MPLAB X in ein Projekt übernommen werden. Der µC ist quasi egal, bei mir ist es – is klar – der PIC18F14K22. Ist dem Software-Simulator aber auch weitestgehend egal, ist ja nur ,ne kleine Sub-Routine.
Eine Bitte hätte ich: es gibt viele Wege (Routinen), welche nach Rom führen. Bitte nicht gleich was Anderes nehmen, sondern wirklich diese eine beblicken und wenn möglich, im Sim testen.
Grüße, picass
copy9.zip