Die Port A-Beschaltung verursacht Trouble oder anders gesagt: das HW-Debuggen korrespondiert nicht mit dieser Beschaltung

Für ein aktuelles Prog wird PA2 als analoger Messeingang genutzt, und weil das zu messende Signal sich nur in einem schmalen Bereich von weniger als einem Volt bewegt, rsp. nur dieser Bereich interessiert, wird von der Möglichkeit Gebrauch gemacht, an den PA0 und PA1 jeweils einen Spannungsteiler vorzuschalten, der genau die gewünschte Eingrenzung ermöglicht. Soweit, so schlecht.
Das Prog ist fertig, also fast: den vermeindlich letzten Floh gilt es, dingfest zu machen und unabhängig davon wüsste ich auch gerne realiter, welche Daten der ADC einliest und auch, was aus der Tabelle im EEProm dazu passend entnommen wird. Der Software-Simulator ist durch, nun sollte der Hardware mittels Debugging auf den Zahn gefühlt werden. Klappt nur nicht, weil das Clocksignal des PICkit3-Programmers einen Dauerpegel von über 4 Volt bereitstellt und damit doppelt so hohen Saft anliefert, als an PA1 für den ADC-Pegel gebraucht wird.
Mist flixter, das µC-Leben ist ungerecht.
Grüße, picass

Zitat von: picass in 25.09.2023, 13:15:58 CESTKlappt nur nicht, weil das Clocksignal des PICkit3-Programmers einen Dauerpegel von über 4 Volt bereitstellt

Im Debug-Mode sind alle "normalen" Funktionen der Pins PGD/PGC/Vpp blockiert.

sehe ich auch so beim 18F14k22, Hast Du die Möglichkeit eine LCD-Anzeige anzuschließen und die Werte auszugeben? So mache ich es immer.

Zitat von: vloki in 25.09.2023, 16:15:26 CEST.....alle "normalen" Funktionen der Pins PGD/PGC/Vpp blockiert.

Hatte im Stillen gehofft, die obere Grenze für den Messbereich um-zwitschen zu können von externer Widerstandskette auf Ausgabe eines intern erzeugten Referenzwertes - passen würden da 2,048 Volt. Aber wenn das Alles nicht funkt.....
LCD-Anzeige nicht, aber es hängt eine 3-stellige 7-Seg-Anzeige dran. Mit solchem Equippment - also einer funktionierenden solchen Anzeige - bin ich überhaupt gestartet. Das lief schon anfangs des Projektes "Anzeigeplatine für Dieselpartikelfilter-Regeneration". Diese "Frühform" zeigte bereits Zahlen an, allerdings passte da allerlei noch nicht. In der Folge wurde das Prog kräftig umgewürfelt, die Portbelegung und ihre Initialisierung geändert, etc..... Ein Zurück zu dem damaligen Zustand wäre möglich, aber das werde ich nicht mehr versuchen, der Aufwand wäre mir zu groß.

Gestern sprach ich von dem "vermeintlich letzten Floh". Den habe ich gestern am frühen Abend entdeckt und - is klar - gleich noch einen weiteren. Beseitigt sind die aber noch nicht, das kommt jetzt gleich. Und weil ich hoffnungsschwanger bin, es könnten tatsächlich die Letzten sein, stürze ich mich darauf.
Wenn das hardwaremäßig nicht möglich ist, dann muss halt die Software-Sim weiter helfen.
Grüße, picass

Mit dem Simulator kann ich mir nicht vorstellen, wie Du die Werte einlesen willst.

Nein, das klappt mit dem Soft-Sim (SS) natürlich nicht. Diese SS ist ja eine voll manipulierbare Angelegenheit und damit einer der Gründe, weswegen ich nicht so recht weiter komme. Dieser SS vermittele ich ja an diversen Stellen solche (Eingabe-) Werte, die nach meiner Erwartunshaltung dort "hingehören". Kann gut sein, dass man sich mit dieser Erwartungshaltung lediglich selbst austrickst.
Noch ein zweites "Nein": der Durchbruch ist noch nicht da. Die diversen Blöcke/Unterprogs funktionieren für sich genommen, aber wahrscheinlich habe ich mich in dem gesamten Progablauf verirrt. Im Prog gibt es 36 Variable und allein drei davon sind für die Ablaufsteuerung - also die jeweilige Position - zuständig. Dann gibt es noch 2 Tabellen im EEProm, zweimal wird der ADC eingelesen.....schwitz.
Habe mir eine Liste mit sechs Techniken/Lösungsansätzen erstellt, die ich heute abarbeiten werde. Zumindest das Auslesen der Tabellen sollte mit dem HW-Debugger klappen. Vielleicht bringt der wechselseite Einsatz der beiden Simulatoren was.
Grüße, picass

ich würde mir überlegen die Anzeige zu aktivieren. Wie wird sie denn angesteuert? Sind Dekoder davor geschaltet oder hängen Sie direkt am Port?

Dieses Vieh - also das Prog - droht, mich zu schaffen.
Der von dir - pic18 - genannte Hinweis, sich erst um einwandfreie Anzeige zu bekümmern, war einer der oben genannten  fünf Punkte. Das hatte ich auch als Erstes in Angriff genommen und damit das Pferd vom Schwanz her aufgezäumt Abgesehen von einer unbedeutenden Kleinigkeit gab es da aber nichts zu bemängeln, die Anzeige zeigte, was ihr angeliefert wurde.
Dann hatte ich für eine  bessere Übersicht über die drei Ablaufvariablen (AV) gesorgt, danach das ganze Prog akribisch durchforstet und dabei eine Ablauftabelle für die Zwischenstände der ABs erstellt. Die dann per Soft-Sim neu abgegrast und - tusch - entdeckt, dass die Einsprungadresse für die zweite der beiden Tabellen falsch war. Das also korrigiert und eben etwas aufgeregt zwecks neuer Hoffnung gestartet, aber zum x-ten Male wieder nix. Es wird eine (neue) Zahl angezeigt, die macht aber weder Sinn und schon gar nicht reagiert die Anzeige auf Änderungen des Eingangswertes.
Jetzt brauche ich erst mal viel Kaffee. Aber so langsam gehen mir sowohl die Hoffnung auf Besserung als auch die Ideen aus, wie man dem RIESEN-FLOH, der irgendwo verborgen schlummert, auf die Spur kommen könnte.
Grüße, picass

Nachtrag: der PIC gibt seine Daten an drei 7-seg-Anzeigentreiber vom Typ CD4511 aus. Der invertiert quasi und speichert u.a. Dieser Schaltungsteil ist aber unverdächtig. Ach ja, neu ist immerhin, dass die EEProm-Werte (Inhalt der Adressen) vom Soft-Sim angezeigt werden, das half schon mal tüchtig weiter.

der CD4511 ist keine günstige Wahl, da du nur Ziffern von 0 bis 9 anzeigen kannst. Besser wäre da sowas wie MC14495, der ist aber leider nicht pinkompatibel, du kannst aber mal den U40511 bzw V40511 anschauen, der dürfte pinkompatibel sein, ich weiß aber nicht ob es den noch gibt. Ich sage das deswegen, weil du dadurch Hexadecimal Werte anzeigen kannst.
Wenn Du magst, dann kannst Du ja dein Progr. mal hochladen. Dann sehe ich darüber.

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

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

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?

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

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

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.

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

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

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

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

Kurz zur Klarstellung: das o.g. Projekt war in der Tat vollendet worden und gelungen.

Nun stehe ich vor einem neuen Problem mit dem Hardware-Debugging (HwD).
In meinem neusten Projekt "Reaktionstester" steckt noch ein Floh, den ich nicht finden kann. Die Hardware - also die PIC-Schaltung mit den Anschlüssen für die Schalter und das 100-Hz-Signal der Netzfrequenz sind mehrfach kontrolliert. Die benötigten Signale kommen alle an richtiger Stelle an. Das Prog läuft im Soft-Sim auch prima, dort ist kein Haken zu finden. Aber der PIC weigert sich, das in die Praxis umzusetzen. Also bliebe noch das HwD. Um da für ungestörte Verhältnisse zu sorgen, wurden fürs HwD die drei Signale vom Port A weg verlegt auf den Port B. An dessen 4 Pinnen liegen 3 Eingänge, der vierte Pin ist ein Ausgang (für LED an oder aus).
Aber der HwD scheint ein eigenwilliges Eigenleben zu führen. Er reagiert nicht auf die Drücke der beiden Tasten pb4 und pb5, obwohl dessen Signale richtig anliegen. Was geht da ab? Der müsste doch "eigentlich" real auf Portsignale reagieren? Die Abfrage erfolgt über übliche Sprungbefehle wie z.B. "btfss PORTB,4"  :also springen, wenn pb4 auf "1" liegt. Macht er aber nicht.
Kann der überhaupt nicht auf Signale von außen reagieren? Den Soft-Sim kann man derart nutzen, dass der Port-Pin stimuliert wird. Das klappt dort prima, nur ist beim HwD diese Funktion der Stimulation nicht vorgesehen, weil ja das echte Signal genutzt werden kann.
Komme nicht weiter und an die verplemperte Zeit mag ich nicht mehr denken.
Grüße, picass