ich habe mal im C-Compiler nachgeschaut, wie hier ein Vergleich übersetzt wird. Hier wird das Carry Register abgefragt.

uint16_t x, y;
uint8_t ergxy;

172:               if(x>y)
73DA  010A     MOVLB 0xA
73DC  51F5     MOVF iss, W, BANKED
73DE  010A     MOVLB 0xA
73E0  5DF7     SUBWF 0xF7, W, BANKED
73E2  010A     MOVLB 0xA
73E4  51F6     MOVF 0xF6, W, BANKED
73E6  010A     MOVLB 0xA
73E8  59F8     SUBWFB 0xF8, W, BANKED
73EA  E204     BC 0x73F4
173:                   ergxy ='>';
73EC  010A     MOVLB 0xA
73EE  0E3E     MOVLW 0x3E
73F0  6FF9     MOVWF lastport, BANKED
174:               else
73F2  D003     BRA 0x73FA
175:                   ergxy ='<'; //<=
73F4  010A     MOVLB 0xA
73F6  0E3C     MOVLW 0x3C
73F8  6FF9     MOVWF lastport, BANKED

ich weiß nur nicht wo ich die technische Adresse von iss und lastport finde. lastport scheint ergxy zu sein, iss?

Meine Hoffnung, der in der Version 5.20 entdeckte Rechenfehler könnte in der Version 5.35 – der letzten vor der Umstellung – beseitigt sein, hat sich nicht bestätigt. Der Fehler tritt bei der Subtraktion zweier 8-bit-Zahlen auf, wenn der Wert der Differenz
größer als dez 160 ist und besteht darin, dass das Negativ-Flag gesetzt wird, obwohl das Rechenergebnis ein eindeutig positives ist. Putzigerweise tauchen dann die Flags N und C gleichzeitig als gesetzt, also ,,1" auf, was natürlich nicht sein darf.
Zwei Beispiele:

Minuend Variable bitl  hält h'a8'
Subtrahend Var.   adcl hält h'05'
-----------------------------------------
ergebnis in wreg               h'a3'  , aber N- und C-Flag gleichzeitig gesetzt

Minuend Variable bitl  hält h'a8'
Subtrahend Var.   adcl hält h'a5'
-----------------------------------------
ergebnis in wreg               h'a3'  ,  nur C-Flag korrekt gesetzt

Demnach ist große Vorsicht bei allen Abfragen des N-Flags geboten.
Grüße, lippe1audi

Schau mal auf das Bild und beachte die Gleichzeitigkeit von N- und C-Flag !
Grüße, picass

ich habe im Moment leider nur den Linux-Rechner. Da kann ich die alte MPLAB nicht laufen lassen. Mit MPLAB-X kenne ich mich mit dem Simulator nicht aus. Verstehen würde ich es bei einem Wert >0x7F

Hab' den Bock gefunden, hat nichts mit der Behandlung von 16 bit-Zahlen, rsp. Ausdrücken zu tun. Passiert bei schlichtester Subtraktion von zwei 8bit-Zahlen:

Solange der Minuend kleiner ist als hex'a1', also dez'161', solange läuft alles korrekt. Sobald aber der Minuend gleich oder größer h'a1' ist, taucht nach der S das N-Flag auf. Wohlgemerkt, das Ergebnis ist richtig, also der Wert der Differenz wird korrekt angegeben, aber bei 180 minus 5 gibts mit dem Ergebnis 175 als Zugabe das N-Flag!
Verstehe wer mag , auf jeden Fall ein Fehler im MPLAB, rsp. dem Assembler.

Weil in meinem Programmteil für die Verzweigung dieses N-Flag abgefragt wurde, lief das Prog aus dem Ruder. Das muss nun also anders gehändelt werden.
Grüße, picass

Zitat von: picass am 01.09.2022, 11:01:14 CESTDein Prog-Schnipsel ist exakt so wie der meinige, nur dass du beim Highbyte noch das Carrabit berücksichtigt hattest.

Das sehe ich nicht so, ich rechne das Ergebnis aus, während du die beiden jeweiligen Bytes vergleichst. Dann mußt Du zuerst die Hi-Byte vergleichen und anschließend die Lo-Byte. Nicht umgekehrt!
Du vergleichst also zuerst die Hi-Byte, wenn das Ergebnis kleiner ist verzweigst Du, ansonsten vergleichst Du anschließend die Lo-Byte und verzweigst dann entsprechend. Das Negativ - Bit sollte eigentlich nur bei einem negativen Ergebnis gesetzt werden. Du kannst aber auch noch das Zero-Bit testen, das Carry-Bit sollte invers zum N-Bit sein, das kannst Du auch mal testen.

Das Problem besteht in der ursprünglichen Version immer noch, also im dem Prog des Beitrages von 19 Uhr, vorgestern.
Das heute eingestellte Prog ist leider dafür misslungen, pardon für die Verwirrung. Aber im Beitrag von gestern (19 Uhr) sind zwei voneinander unabhängige Subraktionen dargestellt, deren Syntax nach meiner Sicht exakt gleich ist. Die eine funktioniert, es wird also kein Negativ-Flag angezeigt, die andere nicht, da gibt es trotz der Subtraktion einer Null ein N-Flag!
Grüße, picass

Danke für dein Engagement! Auch, wenn es ins Leere läuft!
Dein Prog-Schnipsel ist exakt so wie der meinige, nur dass du beim Highbyte noch das Carrabit berücksichtigt hattest. Aber das war - pardon - nicht das Thema.
Tatsächlich ging es darum, dass zwei exakt gleich geschriebene Subtraktionen jeweils von zwei Ein-Byte-Wörtern im einen Fall funktionierte, im anderen Fall jedoch einen  Fehler produzierte, indem fälschlich das Negativ-Flag gesetzt wurde. In plattem Deutsch: zieht man von einer positiven, ganzen Zahl die Zahl Null ab, darf natürlich kein negatives Ergebnis rumkommen.

Um das Dilemma zu verdeutlichen, habe ich aus dem Mini-Prog von gestern die Subtraktion der High-Bytes raus gestrichen und nur diejenige der beiden Low-Bytes drin gelassen. Und wieder wird das N-Flag gesetzt!

Ein mathematisches Wunder ereignet sich! Schaut genau hin, ihr lernt eine absolut neue Mathematik kennen. Vergesst eure Schul-Kenntnisse und der Uni-Abschluss ist auch nichts mehr wert: Null abziehen und schon ist eurer Gehaltskonto fett im Minus!!!
Grüße, picass

Ich habe schon lange nichts mehr in Assembler programmiert. Kann sein, das ich einen Denkfehler habe.
Ich würde es so schreiben.

schwell012:
MOVF ADLO,W,BANKED; lade ADLO nach W
SUBWF BITLO,F,BANKED; BITLO = BITLO-W
MOVF ADHI,W,BANKED; lade ADHI nach W
SUBWFB BITHI,F,BANKED; BITHI = BITHI-W-!C
BN negativ; verzweigt wenn Ergebnis negativ ist
BRA positiv_or_gleich; Ergebnis ist positiv oder gleich

hier wird allerdings BIT(Lo,Hi) mit dem Ergebnis überschrieben.

Mittlerweile ist die Rev 3.0 der Platine eingetroffen, also die dritte Ausführung.
Die eingelesenen Werte in dem ausgewählten Bereich von 1 bis 2 Volt werden durch 3 Schaltschwellen eingeteilt, entsprechend leuchtet/en die entsprechende/n LED/'s und ein Piepser macht sich bemerkbar.
Grüße, picass