MPLAB X IDE : Fehler bei Subtraktion: falsches Flag gesetzt

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...

picass · 21.10.2022, 17:42:46 CEST

Es gab diverse Gründe, warum ich mich erst jetzt wieder einschalte: zum Einen kam ein anderes, für mich wichtigeres Projekt (keine µC-Anwendung) unangemeldet dazwischen, zum Anderen war das Rechenproblem bereits von mir gelöst worden– siehe oben. Leicht tragisch empfinde ich den Verlauf dieses Freds. Da haben wir offenkundig zuletzt prima aneinander vorbei geredet.

Mir ging es in diesem Fred darum, eine Schwäche des ,,Zweier-Komplent-Rechnens" aufzuzeigen, nicht mehr, aber ganz sicher auch nicht weniger. Etwas unglücklich widersprachst du, Volker, und schobst das auf vermeintliche Fehler in meinem Programm. Danach bemühtest du dich, das Programm so umzuschreiben, dass es ohne Fehler auflaufen konnte. Da hattest du dir ordentlich Mühe gegeben, dafür auch ein herzliches Danke. Aber mehr hätte ich mich gefreut, wenn du meine Darstellung der erkannten Schwäche anerkannt hättest. Das Programm zum sauberen Laufen zu bekommen, war mir ja selbst schon gelungen.

Dazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden und stattdessen das C-Flag für Verzweigungen nutzen. Oder man vermeidet überhaupt eine ,,echte" Subtraktion und setzt auf einfachen Überlauf, das Abfragen des C-Flags und damit auf den ,,bit-test-und-Sprung-wenn"-Befehl, so wie du es in deinen beiden letzten Prog-Vorschlägen ausgeführt hattest. Wobei es genau genommen um andere Sprungbefehle geht, statt bra also bit-test.

Mein ganzes µC-Bemühen liegt seit einigen Tagen brach, weil anderes erledigt werden musste. In den nächsten Tagen versuche ich, weiter zu kommen.
Grüße, picass

vloki · 22.10.2022, 13:39:47 CEST

Zitat von: picass in 21.10.2022, 17:42:46 CESTDazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden

Man könnte auch einfach akzeptieren, wozu CARRY, /BORROW und NEGATiV Flags benutzt werden und sich nicht versuchen raus zu reden. Es gibt keine Schwäche des 2er Komplements und dein Problem existiert schlicht nicht.

picass · 24.10.2022, 17:24:36 CEST

Ich werde die fruchtlose Debatte hier beenden. Es konnte aufgezeigt werden, dass in dem Problem-/Spannungsfeld von Assembler-Programmierung in der MPLAB X IDE-Umgebung (bis Vers. 5.35) logische Fehlentscheidungen und auch Rechenfehler stattfinden.

Anhand von Beispielen konnte nachgewiesen werden, dass nach Subtraktionen mal weder ein Negativ- noch ein Carry-Flag gesetzt wurde, und ebenso das Gegenteil, dass danach gleichzeitig ein N- und ein C-Flag gesetzt wurden. Beides steht für einen Fehler. Ebenfalls gab es Beispiele von Subtraktionen, in denen schlichtweg ein echter Rechenfehler auftrat.

Diese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler. Die gezeigten Rechenfehler finden sich nicht nur in meinem Beispiel wieder, sondern auch in Muster-Rechenentwürfen namhafter Autoren, hier gezeigt am Beispiel im Buch ,,Mit dem PIC-Controller erfolgreich arbeiten" von Dr. Anne König und Manfred König, erschienen im Verlag Markt@Technik, Auflage 1996, Seite 398. Das exakt gleiche Programmbeispiel inclusiv des Rechenfehlers (bis auf unwesentliche Bezeichner-/Variablen-Namen Änderungen) findet sich bei SPRUT, und alles geht auch auf Beispiele von Microchip zurück.

Das sind Beweise genug. Für Lern- und Akzeptanz-Unwillige werde ich nun aus grundsätzlichen Erwägungen heraus keine Zeit mehr investieren. Mag sein, dass es nicht jedem gegeben ist, zwischen dem Problem und der Problembeseitung einen Trennstrich zu ziehen. Mir ging es in diesem Fred alleine um die Darstellung des Problems, rsp. den Hinweis darauf.

Jeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen. Damit ist für mich hier Schluss. Ich beende meine Beiträge und bin stolz auf meine Entdeckung. Der Fred erhält von mir das vom Forum zur Verfügung gestellte Merkmal: gelöst. Wer sich an dem anderen Problemfeld, der Vermeidung dieser Rechenfehler – z.B. durch Umgehungsstrategien – engagieren möchte, darf und sollte das in einem eigenen Fred tun und kann sicher sein, dafür auch Anerkennung zu finden.
Grüße, picass

vloki · 24.10.2022, 19:06:50 CEST

Zitat von: picass in 24.10.2022, 17:24:36 CESTIch werde die fruchtlose Debatte hier beenden.

Gut

Zitat von: picass in 24.10.2022, 17:24:36 CESTAnhand von Beispielen konnte nachgewiesen werden...

Nö

Zitat von: picass in 24.10.2022, 17:24:36 CESTDiese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler

Welche? (nein, bitte nicht antworten;-))

Zitat von: picass in 24.10.2022, 17:24:36 CESTDas sind Beweise genug.

Ich habe keinen einzigen gesehen

Zitat von: picass in 24.10.2022, 17:24:36 CESTJeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen...

... und wird keinerlei Systemfehler finden

picass · 27.10.2022, 10:31:24 CEST

Widerspruch auf allen Ebenen wie es scheint. Ich halte mich aber an mein Wort und lege diese Angelegenheit auf Eis. Viel.... viel zu viel Zeit ist bislang dafür geopfert worden und meine anderen, wichtigen Projekte lagen da auf Eis. Die müssen aber dringend weiter geführt werden und denen wird meine Aufmerksamkeit nun gelten. Mag sein, dass diese Angelegenheit hier auch noch mal aufgegriffen wird für eine Überprüfung. Aber nun gibt's Eis. Das könnte auch zur Abkühlung evtl. angeheizter Atmosphäre dienen.
Grüße, picass

vloki · 27.10.2022, 13:24:00 CEST

etwas off-toppic, aber mit Bezug zu einem Beitrag von mir weiter oben:

Zufällig bin ich in einem anderen Forum auf deine Anfrage bzgl. MPASM - PIC_AS gestoßen
und dadurch auf die Lösung meines Problems mit der Anzeige der Variablen im Debugger gekommen.

Die Variablen müssen dafür beim PIC-AS als "global" deklariert sein.
Wird auch im MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf irgendwo erwähnt

picass · 28.10.2022, 10:29:43 CEST

Nachfolgendes sieht nach einer veritablen Unhöflichkeit oder gar Provokation aus. Ist aber nur der Anschein:
Ich werde auch deinen gerade formulierten Hinweis nicht aufgreifen. Jedenfalls nicht jetzt. Sitze wirklich total in einer Zeitklemme drin, es sind zu viele Jobs, die ich auf einmal erledigen müsste. Und z.Z. sitzt mir auch meine Frau im Nacken, die - leider zu Recht - anmahnt, dass etliches Zugesagtes immer noch nicht erledigt wäre.

Die Gemengelage mit dem Rechenfehler möchte ich einfach noch mal komplett von vorne aufrollen, auch, weil ich natürlich darin interessiert bin, zumindest dicht an so was wie die "Wahrheit" ran zu kommen. Es gibt immerhin schon den dezenten Hinweis, dass die Funktion des Carry-Flags von mir nicht genau erfasst wurde. Aber jetzt kommen erst mal andere Projekte dran, z.B. mein Regenerations-Anzeiger, danach die Garagentor-Steuerung. Dann kommt Urlaub, dann.....
Ein offenes Wort noch: es würde mich freuen, wenn es uns gelingen würde, ein weitgehend friedliches Miteinander bewahren zu können.
Grüße, picass

Neuigkeiten:

MPLAB X IDE : Fehler bei Subtraktion: falsches Flag gesetzt

vloki

picass

vloki

picass

vloki

picass

vloki

vloki

vloki

vloki

picass

vloki

picass

vloki

picass

vloki

picass

Schnellantwort

Similar topics (5)