MPLAB X IDE : Fehler bei Subtraktion: falsches Flag gesetzt

vloki · 30.09.2022, 11:47:24 CEST

Zitat von: picass in 30.09.2022, 10:34:16 CESTEine Frage wäre es, ob in den neueren Versionen der MPLAB-Umgebung dieses Prob beseitigt wäre.

Nochmal - die IDE und der Assembler haben mit deinem Problem absolut nichts zu tun.
Die sind nicht in der Lage die Hardware nach deinem Geschmack zurecht zu biegen!

vloki · 30.09.2022, 12:31:22 CEST

Zitat von: picass in 30.09.2022, 10:34:16 CESTWenn der Subtrahend größer ist als der Minuend, was ja nun wirklich nicht als ,,Spezial-Fall" deklariert werden sollte, dann muss ein Übertrag erfolgen, rsp. dem Subtrahend eine ,,Eins" abgezogen werden. Dafür braucht es ein Flag. Zwei stehen zur Verfügung und beide sind unzuverlässig.

Ach so, bei der Subtraktion ist das "Carry" ja ein "/Borrow".
Also muss auf "0" verglichen werden. (bnc negativ)

picass · 02.10.2022, 18:23:43 CEST

Hallo Volker!
Deine Einlassungen stimmen so nicht. Wenn man davon ausgeht, dass die Rechenfehler, rsp. die Rechenprobleme nicht in beiden Bestandteilen, hier auf der einen Seite der µC und auf der anderen Seite die ,,Software" – egal, welcher Art sie auch ausgestaltet ist, rsp. wie sie benannt wird - liegt, dann muss man schon deutlich auf eine der beiden möglichen Seiten zeigen.

Ich gehe davon aus, dass nicht der PIC18F14K22 einen in Hardware gegossenen Flag-, rsp. Rechenfehler aufweist, sondern dass dieser auf der Softwareseite zu finden ist. Das hast du ja auch schon selbst indirekt bestätigt, indem du mir geraten hattest, eine andere Software zu verwenden, nämlich eine Hochsprache.

Also dann doch ganz klar: das Problem liegt – wie ich es wiederholt beschrieben hatte – bei den Mängeln, rsp. der Unzulänglichkeit, rsp. der Unzuverlässigkeit der IDE und des MPLAB. Diese beiden Komponenten fasse ich mal unter dem Oberbegriff ,,Software" zusammen, auch wenn das etwas unscharf ist, weil auch noch das davon erzeugte Programm mit dazu gehört, aber egal: diese beiden Komponenten sind es, welche die Probleme ursächlich erzeugen.

Leider magst du meine Beispiele nicht beachten, z.B. das mit der Unzuverlässigkeit auch des C-Flags, rsp. versuchst sie umzudeuten in sowas wie persönliches falsches Verhalten. Aber nein: nicht ich rechne mit negativen Zahlen, diese Zahlen sind ja nur willkürliche Beispiele für eine einzelne Rechenaufgabe, welche sich aus dem Einlesen und Verarbeiten der 10Bit des Analogwandlers ergeben. Das hat mit einzelnen Personen nun wirklich gar nichts zu tun.

Wenn man sich bei Assemblieren nun aber weder auf das N- noch auf das Carry-Flag verlassen kann, dann ist das aus meiner Sicht eine Bankrotterklärung für dieses System. Klar, man kann die von einem Negativ-Flag geforderte, aber nicht geleistete Funktion ersetzen, indem man – wie ich dargestellt hatte – zu Compare-Befehlen (CB) greift. Wenn man aber nun auch noch Konstruktionen für das Ersetzen des unzuverlässigen C-Flags erstellen muss, wird das System irgendwie unbrauchbar, rsp. eine Zumutung. Das Gestrampel mit dem Ersetzen des C-Flags habe ich auch geschafft, ebenfalls mit CB, aber das generiert und summiert dann doch zu einer abstrusen Einschränkung der Handelbarkeit des Assemblers.

Eine solche Einschränkung hätte selbstverständlich entsprechende deutliche Hinweise in den technischen Unterlagen nach sich ziehen müssen. Kleinste, geschickt verborgene und noch kryptische Einsilbrigkeit kann nicht akzeptiert werden. Mit diesen Einschränkungen kann man leben, aber das befreit sie nicht vom Makel.
Grüße, picass

vloki · 04.10.2022, 20:15:55 CEST

Zitat von: picass in 02.10.2022, 18:23:43 CESTIch gehe davon aus, dass nicht der PIC18F14K22 einen in Hardware gegossenen Flag-, rsp. Rechenfehler aufweist, sondern dass dieser auf der Softwareseite zu finden ist. Das hast du ja auch schon selbst indirekt bestätigt, indem du mir geraten hattest, eine andere Software zu verwenden, nämlich eine Hochsprache.

Es gibt weder Rechenfehler in der Hardware noch der Software und die Hochsprache hatte ich empfohlen, weil ich davon ausgehe, dass die Programmierer der Compiler die Geschichte mit den Flags so gut im Griff haben, dass korrekte Berechnungen durchgeführt werden ;-)

picass · 05.10.2022, 14:43:26 CEST

Zitat von: vloki in 04.10.2022, 20:15:55 CESTEs gibt weder Rechenfehler in der Hardware noch der Software und die Hochsprache hatte ich empfohlen, weil ich davon ausgehe, dass die Programmierer der Compiler die Geschichte mit den Flags so gut im Griff haben, dass korrekte Berechnungen durchgeführt werden ;-)

Wenn es deinem Verständnis der von mir entdeckten Flag-Fehler, rsp. Unzuverlässigkeiten hilft, dann bennene das nicht "Rechenfehler" sondern stattdessen "inkorrekte Berechnung".

Habe jetzt in meinem aktuellen Prog alle Sprungbefehle, welche das N- oder das C-Flag verwendet hatten, durch andere Sprungbefehle ersetzt. Und - tusch - nun sind die vorher elendig störenden Fehler weg.
Zwecks einer anderen Sprache:
versuche gerade - wenn auch mit gebremsten Schaum - mal einen Blick in die neuere Assemblerversion zu werfen, in das PIC-ASS. Wer weiß schon, warum Microchip das MPASMWIN ausgemustert und durch eine andere Version ersetzt hat. Vielleicht spielten "inkorrekte Berechnungen" ja auch eine Rolle?!
Is klar, beim ersten Versuch mit dem PIC-ASS hakt es, weil da etliche Bezeichungen geändert wurden. Im eigentlichen Programm sehen die Änderungen auf den ersten Blick nicht besonders schwierig aus. Bin neugierig genug, rauszufinden, ob das ein möglicher Weg wäre.
Grüße, picass

vloki · 06.10.2022, 09:14:28 CEST

Zitat von: picass in 05.10.2022, 14:43:26 CESTWer weiß schon, warum Microchip das MPASMWIN ausgemustert und durch eine andere Version ersetzt hat. Vielleicht spielten "inkorrekte Berechnungen" ja auch eine Rolle?!

Die hatten einfach zwei Assembler, den alten eigenen MPASM und den, der beim Hightech C-Compiler dabei war.
Zwei Produkte für den gleichen Zweck weiter zu entwickeln und zu pflegen macht wenig Sinn.

So wurde zuerst der eigene alte C18 Compiler eingestampft und später eben auch der MPASM Assembler.
Blöd für die, welche die ursprünglichen MCHP Produkte verwendeten...

Inkorrekte Berechnungen haben da aber bestimmt keine Rolle gespielt.

Ein Assembler ist ja mehr oder weniger nur ein besseres Textersetzungsprogramm,
welche den einigermaßen menschenlesbaren Assemblercode 1:1 durch binären Maschinencode ersetzt.

Etwaige Hoffnungen, dass ein neuer Assembler anderen Maschinencode hervorbringt
erscheinen mir daher extrem unrealistisch.

Da ich schon lange keine Assemblerprogramme mehr geschrieben und mich auch noch nicht mit dem
"neuen" Assembler beschäftigt habe, würde mich ein 1:1 Vergleich deines Eingangsbeispiels
auch interessieren. Also wie der Programmcode im Vergleich aussieht.

Hast du das mit dem /Borrow Flag eigentlich mal getestet?
BNC negativ
BC positiv

picass · 06.10.2022, 10:20:25 CEST

Schau nochmal in meinen Beitrag vom 29.09. um 18:38 Uhr. Das ist das Dilemma bestens dargestellt: nach einem "stinknormalen" Subtraktionsmanöver wird weder ein N noch ein C Flag gesetzt. Also kann man die Flags vergessen, egal, wie der Sprungbefehl danach lautet. Ja, hatte ich getestet, half nur nichts.

Wenn das mit ein wenig Fingerschnipsen - sprich: einem überschaubaren Zeitaufwand - zu machen wäre, würde ich gerne auch auf eine andere Prog-Sprache umwechseln. Aber im Moment ist mir dieser Aufwand nicht möglich, zuviel andere Arbeit und zudem muss ich wohl oder übel beim Assembeln bleiben, um die vorhandenen Steuerungsprogramme warten zu können. Da eine längere Pause einzulegen oder das gar gänzlich beiseite zu legen, das hatte für mich bislang immer bittere Konsequenzen, weil ich einfach zuviele Basics dann vergessen hatte und mich wieder neu reinquälen musste. Allein deshalb versuche ich, in Übung zu bleiben.
Die Welt ist unvollkommen, Volker, auch im µC-Bereich.
Grüße, picass

vloki · 06.10.2022, 11:01:22 CEST

Zitat von: picass in 06.10.2022, 10:20:25 CESTDas ist das Dilemma bestens dargestellt: nach einem "stinknormalen" Subtraktionsmanöver wird weder ein N noch ein C Flag gesetzt.

Ja, bei der Subtraktion entspricht das nicht gesetzte Carry aber einem Borrow!
Ich bin der Meinung, das funktioniert. Also bei deinem (auf BNC negativ abgeänderten)
Testprogramm hat das mit allen Werten funktioniert, die ich getestet habe.

Hast du denn ein konkretes Beispiel, wo es deiner Meinung nach nicht funktioniert?

picass · 08.10.2022, 16:59:47 CEST

Hier nun das erwünschte Beispiel für Rechenfehler auch wegen falschen Carry-Bit-Setzen's.

Es handelt sich um eine schlichte 16-bit-Subtraktion. Das Beispiel ist ein Auszug aus dem Prog. ,,Anzeige Regeneration Dieselpartikelfilter". Da werden u.a. die Werte eines analogen Eingangs (10-bit) ausgelesen und für die Anzeige auf drei 7-Seg-Anzeigen aufbereitet. Für die Hunderter und Zehner wird vom Datenwert jeweils dez'100', rsp. d'10' solange abgezogen, bis sich ein negatives Ergebnis zeigt. Die Rundendurchläufe repräsentieren dann je den Wert des Hunderters, rsp. des Zehners.

Als willkürliches Beispiel wird ein Analog-Wert von d'280' angenommen. Um den aufzubereiten, wären ,,normal" drei aufeinander folgende 16-bit-Subtraktionen im Hunderter-Bereich notwendig. Der Ausführlichkeit halber und weil es praktisch im Programm auch so abläuft, werden die insgesamt sechs 8-bit-Subtraktionen dargestellt.

Zwei Variable: "adc" für den Analog-Wert und "bit" für jeweils 100 oder 10.
Gerechnet wird: adc minus bit, das Erbnis wird in adc gespeichert

1. Runde: 280 minus 100 // adc hält h'0118' = d'280' und bit hält h'0064' = d'100'

---------------------------------------------------------------------------------------------------
RE 1) 280-100=180

adclow h'18' / d'24'
- bitlow -h'64' / d'100'
------------------------------
adclow h'b4' / d'180' Flags: N ja, C nein //Ergebnis negativ=Decrement high bit nötig

RE 2) adchigh hielt h'01', nach Decrement nun h'00'

adchigh h' 00' / d'0'
- bitlow -h'00' / d'0'
----------------------------
adchigh h'00' / d'0' Flags: N nein, C ja // Ergebnis positiv

In Schleife wird Hunderter-Zähler incremiert = Hundert hält d'1'

-----------------------------------------------------------------------------------------------------
RE3) 180-100=80

adclow h'b4' / d'180'
- bitlow -h'64' / d'100'
------------------------------
adclow h'50' / d'80' Flags: N nein, C ja //Ergebnis positiv= kein Decrement high bit

RE 4)

adchigh h' 00' / d'0'
- bitlow -h'00' / d'0'
----------------------------
adchigh h'00' / d'0' Flags: N nein, C ja // Ergebnis positiv

In Schleife wird Hunderter-Zähler incremiert = Hundert hält d'2'
-----------------------------------------------------------------------------------------------------

RE 5) 80-100= -180

adclow h'50' / d'80'
- bitlow -h'64' / d'100'
------------------------------
adclow h'ec' / d'236' Flags: N ja, C nein //Ergebnis negativ = Decrement high-bit nötig

RE 6) adchigh hielt h'00', nach Decrement nun h'ff' / d'255'

adchigh h' ff' / d'255'
- bitlow -h'00' / d'0'
----------------------------
adchigh h'ff' / d'255' Flags: N ja, C ja // Ergebnis positiv

In Schleife wird fälschlich Hunderter-Zähler incremiert=Hundert hält d'3' // RECHENFEHLER !!!
------------------------------------------------------------------------------------------------------------------

Die Rechnung 6) , die Subtraction des High-Bytes produziert Fehler am laufenden Bande:
1. aus dem eigentlich negativen Wert des High-Bytes nach dem Decrement, das danach h'ff'
hält, wird nun auf einmal ein positiver Wert. Dieses urprünglich negative h'ff' verursacht den nachfolgenden Kollabs:
2. es werden sowohl das N-Flag als auch das C-Flag gesetzt und das kann nur falsch sein.

Der danach erfolgende Sprung mit BNC bewirkt ein weiteres und damit falsches Hochzählen des Hunderter-Zählers:
Das Rechenergebnis wird falsch und laufend falscher.

3. zusätzlich zum Desaster des falschen Ergebnisses gelangt das Programm in eine Endlosschleife und ist nur noch mit dem weiteren Verfälschen des Hunderter-Zählers beschäftigt.

Somit ist nachgewiesen, dass sowohl das Benutzen des N-Flags im Sprung-Befehl ,,bra" als auch dasjenige des C-Flags zu Fehlern führen kann.

Das System des Zweier-Komplents ist über seine Grenzen getreten, rsp. sie wurden aufgezeigt. Nur mit Programmier-Tricks, rsp. - Ausflüchten, rsp. Vermeidungs-Strategien kann ein sauberes, genauer gesagt: normales Rechnen ermöglicht werden.

Das angehängte Zip-File enthält 3 Dateien:
- den kompletten vom MPLAB erstellten Ordner ,,rechnen08" u.a. mit dem ASM-File
- dieses ASM-File als Text-File
- diesen im Forum eingestellten Beitrag als PDF-File mit den einzelnen Rechenbeispielen, die sich ausgedruckt wohl bequemer nachvollziehen lassen.

Grüße, picass

vloki · 10.10.2022, 16:07:50 CEST

Also dein erster Fehler ist beim Ende Hunderter.
Da muss nicht nur adclow wieder hergestellt werden, sondern auch adchigh,
weil das am Ende auf -1 steht (muss Null sein / incf oder clrf)

Wenn dann die Zehner mit bnc berechnet werden wie die Hunderter klappt das evtl auch.
Hattest du wohl schon die Lust verloren...

Code Auswählen

;-------------------
_hun:                           ;adc minus bit, ergebnis wieder in adc
     clrf        hundert
     movlw       h'64'          ;bitl & bith mit h'64' = d'100' füllen
     movwf       bitl
     movlw       d'0'
     movwf       bith           ;
_hunLoop:                       ;
     nop
     movff       adclow,temp	;sichern u wiederherstellen,wenn negativ war 
     call        subtract       ;adc minus bit
     nop
     bnc         _hunEnd        ;wenn negativ, ab zu zehner
                                ;wenn positiv, weiter in schleife
     incf        hundert        ;ist noch hunderter
     bra         _hunLoop       ;weiter hunderter zählen     
                                ;ausgang:hunderter in hundert,zehnerrest in temp
_hunEnd:                           
     movff	 temp,adclow    ;erst adclow wiederherstellen
     clrf	 adchigh	; das aber auch !!!
;----------------
_zehn:                          ;eingang: zehner u einer
     clrf        zehner
_zehnLoop:
     movff       adclow,temp    ;vorsorglich umspeichern in einer
     movlw       D'10'          ;wieviel zehner stecken in adclow ?
     subwf       adclow,1,1     ;minus zehn, der rest in adclow
     bnc         _zehnEnd       ;keiner zehner mehr,ab zum einer-zählen
     incf        zehner         ;ist noch zehner
     bra         _zehnLoop      ;weiter zehner zählen
_zehnEnd:
     movff	 temp,adclow    ;erst adclow wiederherstellen
;----------------
_ein:                            ;eingang: einer-anzahl in temp
     movff       temp,einer     ;ist ja schon fertig jetzt !!!!
                                ;ende der zählroutine, bzw. der umwandlung
     nop
     nop
     return     ;bra     main1  ;in hunderter, zehner, einer
                                ;zurück zum anfang

(((Die verwendete Namensgebung macht das ganze nicht gerade einfach zu verfolgen)))

Sorry, sehe gerade in subtract habe ich auch was geändert. Blick ich gerade selber nicht mehr ;-)

Code Auswählen

subtract:                       ;adc minus bit, ergebnis wieder in adc
                                ;bitl & bith enthalten d'1000' oder d'100'
     nop                          
     movf        bitl,0,1       ;bit-wert low minus adclow
     subwf       adclow,1,1     ;ergebnis wieder in adclow
     
     btfss	 STATUS,C	;ergebnis positiv, dann dec überspringen
     decf        adchigh
     return

picass · 10.10.2022, 18:43:15 CEST

Zitat von: vloki in 10.10.2022, 16:07:50 CESTBlick ich gerade selber nicht mehr ;-)

......so isses! Keine Fehler von mir, sondern von dir:
Du hast zwar was verändert, aber nicht wirklich geändert.

Die Abfage des positiv-negativ Statusses nach der Subraktions-Schleife hast du von ,,bnc" auch ,,bnc" geändert, was natürlich keine Wirkung haben kann. Und die Einführung der ,,Wiederherstellung" von adhigh durch ,,clr adchigh" ist verschwendete Liebesbemühung, denn das Programm kommt ja gar nicht bis dorthin wegen des Flag-Fehlers, dass nach der Sub-Schleife gleichzeitig N- und C-Flag gesetzt werden.

In der Subraktionsschleife hattest du was Schlimm-Verbessert, indem die Bearbeitung des High-Bytes übersehen wurde.

Da sitzt du jetzt im selben Schlammassel wie ich! Willkommen im FFC!
Also dem Falsch-Flag-Club!
Grüße, picass

vloki · 10.10.2022, 20:51:02 CEST

Zitat von: picass in 10.10.2022, 18:43:15 CESTder Subraktionsschleife hattest du was Schlimm-Verbessert, indem die Bearbeitung des High-Bytes übersehen wurde.

Da sitzt du jetzt im selben Schlammassel wie ich! Willkommen im FFC!

Mir scheint du hast dir nicht mal die Mühe gemacht, das zu testen.
Ich pack das Projekt mal morgen und dann gibst du mir einen Wert, bei dem es nicht funktioniert.
Wäre natürlich möglich, da ich schon Jahrzehnte nicht mehr in Assembler programmiere

vloki · 11.10.2022, 09:21:41 CEST

Zitat von: picass in 10.10.2022, 18:43:15 CESTIn der Subraktionsschleife hattest du was Schlimm-Verbessert, indem die Bearbeitung des High-Bytes übersehen wurde.

Nö, Tausender berechnest du ja auch nicht. Das passt so ;-)

Ok, ich habe das ganze nochmal ein bisschen ausgemistet,
um für mich persönlich die Übersichtlichkeit zu erhöhen:

Code Auswählen

...
indezimal:                  ;adc minus bit
                            ;  - analogmeßwert in adcL & adcH
                            ;  - d'100' oder d'10' in bitl & bith
			    ; für rechenprobe adc füllen mit h'0118' = d'280'
    movlw   h'67'           ;adcL
    movwf   adcL            ;
    movlw   h'02'           ;adcH
    movwf   adcH
    nop

;-------------------
_hun:                       ;adc minus bit, ergebnis wieder in adc
    clrf    hundert
_hunLoop:                   ;
    movff   adcL,einer      ;sichern u wiederherstellen,wenn negativ war
    movlw   D'100'          ;bitl & bith mit h'64' = d'100' füllen
;    call    subtract       ;adc minus bit
    subwf   adcL,F,A	    ;ergebnis wieder in adcL
    btfss   STATUS,C	    ;ergebnis positiv, dann dec überspringen
    decf    adcH
    bnc     _hunEnd	    ;wenn negativ, ab zu zehner
    incf    hundert	    ;ist noch hunderter
    bra     _hunLoop	    ;weiter hunderter zählen

_hunEnd:                    ;ausgang:hunderter in hundert,zehnerrest in temp
    movff   einer,adcL      ;erst adcL wiederherstellen temp,adcL
    clrf    adcH	    ; das aber auch !!!
;----------------
_zehn:                      ;eingang: zehner u einer
    clrf    zehner
_zehnLoop:
    movff   adcL,einer      ;vorsorglich umspeichern in einer
    movlw   D'10'           ;wieviel zehner stecken in adcL ?
    subwf   adcL,F,A        ;minus zehn, der rest in adcL
;    bnc     _zehnEnd        ;keiner zehner mehr,ab zum einer-zählen
    btfss   STATUS,C
    return
    incf    zehner          ;ist noch zehner
    bra     _zehnLoop       ;weiter zehner zählen

    end

Gepacktes Projekt im Anhang...

vloki · 11.10.2022, 09:29:56 CEST

PS: die Kommentare sollte man evtl. noch überarbeiten.
(Da stehen noch einige Altlasten)

Noch ein beispielhafter Screenshot vom Watches Fenster:

vloki · 14.10.2022, 12:41:27 CEST

So, weil ich gerade mal wieder mein Script überarbeite und den Assemblerteil an den Assembler vom XC8 anpassen möchte, habe ich das mal mit diesem kleinen Progrämmchen versucht. Leider ist es mir nicht gelungen, die Variablen im Debugger anzeigen zu lassen (IDE v6.00, XC8 v2.30). Hoffentlich wird das noch verbessert

Trotzdem hänge ich das mal hier an.
Kommentare habe ich etwas angepasst und den einen Bit-test-skip Befehl in einen Branch abgeändert, weil evtl. nicht offensichtlich ist, warum das Überspringen des Inkrement für den sich ja darauf beziehenden nachfolgenden Branch hier kein Problem darstellt.

Code Auswählen

#include <xc.inc>

PSECT udata_acs
adcL:        DS  1   ;variable für daten aus analog-eingang
adcH:        DS  1
hunderter:      DS  1   ; für decode
zehner:         DS  1
einer:          DS  1    ; auch fuer temp!

PSECT resetVec,class=CODE,reloc=2
resetVec:
    goto    main

PSECT code
main:
    movlw   00000010B        ;set cpu clock speed of 31KHz
    movwf   OSCCON,A        ;move contents of working register into OSCCON
    clrf    OSCTUNE,A       ;
    clrf    LATA,A
    clrf    TRISA,A         ;port a ausgang
    clrf    LATB,A          ;
    clrf    TRISB,A         ;port b ausgang
    clrf    LATC,A          ;
    clrf    TRISC,A         ;port c Configure as output
                    ; für rechenprobe adc füllen (mit irgendwas)
_MainLoop:
    nop                     ;adc = wert nach auslesen des analogen eingangs
    movlw   0x67            ;adcL
    movwf   adcL,A          ;
    movlw   0x02            ;adcH
    movwf   adcH,A

    call    indezimal       ;zerlegen in hunderter, zehner, einer
    bra        _MainLoop        ;zurück zum anfang

indezimal:                  ;adc wert in dezimalstellen
                            ;  - analogmesswert in adcL & adcH
                            ;  - d'100' oder d'10' in WREG
;-------------------
_hun:                       ;hunderter stelle ermitteln
    clrf    hunderter,A
_hunLoop:                   ;
    movff   adcL,einer      ;sichern u wiederherstellen,wenn negativ war
    movlw   100             ;WREG mit h'64' = d'100' füllen
    subwf   adcL,F,A        ;ergebnis wieder in adcL
    bc        _hunInc        ;wenn ergebnis positiv, hundert++
    decf    adcH,A        ; sonst adcH--
    bnc     _hunEnd        ;wenn adcH negativ wird, ab zu zehner und einer
_hunInc:
    incf    hunderter,A        ;ist noch hunderter
    bra     _hunLoop        ; weiter hunderter zählen
_hunEnd:                    ;ausgang: hunderter in hunderter, rest in einer (temp)
    movff   einer,adcL      ;erst adcL wiederherstellen einer (temp) -> adcL
    clrf    adcH,A        ; das aber auch !!!
;----------------
_zehn:                      ;eingang: zehner und einer
    clrf    zehner,A
_zehnLoop:
    movff   adcL,einer      ;sichern u wiederherstellen,wenn negativ war
    movlw   10              ;wieviel zehner stecken in adcL ?
    subwf   adcL,F,A        ;minus zehn, der rest in adcL
    btfss   CARRY        ;keiner Zehner mehr?
    return            ; fertig - Einer sind schon in einer!
    incf    zehner,A        ; sonst zehner++
    bra     _zehnLoop       ; und weiter zehner zaehlen

    END

Unten noch das Variablenfenster mit Anzeige der Werte durch Eingabe der Adressen...

Neuigkeiten:

MPLAB X IDE : Fehler bei Subtraktion: falsches Flag gesetzt

vloki

vloki

picass

vloki

picass

vloki

picass

vloki

picass

vloki

picass

vloki

vloki

vloki

vloki

Schnellantwort

Similar topics (5)