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
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?
irgendwie ist der Code sehr aufgebläht, es wird ständig MOVLB geladen.
MBLABX IDE v.5.5, C18(v3.47) Compiler
Das N Bit wird gesetzt, wenn das MSB des Ergebnisses 1 ist.
Das ist so definiert und im demnach auch so in der ALU des PICs festgelegt.
Kann man im Datasheet nachlesen und hat mit der IDE rein gar nichts zu tun.
Interessant! Allerdings unverständlich. Konnte trotz Suchens keine solche Stelle "im Datasheet" entdecken, und daher fehlt mir eine Begründung, warum dieses Setzten so gewollt ist.
Ist aber auch fast egal, es bestätigt ja meine Aussage, dass das N-Flag bei Subtraktionen nicht, rsp. nur sehr eingeschränkt sinnvoll brauchbar ist, zumindest bezogen auf das Ergebnis. Da hilft in diesen Fällen nur, das N-Flag besser zu ignorieren und sich stattdessen am C-Flag zu orientieren, das weiß wenigstens zuverlässig, was positiv und was negativ ist.
Grüße, picass
Guckst du bei STATUS Register ;-)
z.B. beim 18F14K22 -> 3.3.5
ZitatN: Negative bit
This bit is used for signed arithmetic (two's complement). It indicates whether the result was negative
(ALU MSB = 1).
1 = Result was negative
0 = Result was positive
Danke, habe geguckt! ;)
Echt abgefahren! Das haben sie jetzt von ihrer Trickserei mit der Addition des "two's compliment", statt wie wir anständigen Leute auch "echt" zu subtrahieren, indem man Bit für Bit abarbeitet und "abzieht"! >:(
Das Leben wird schon wieder noch komplizierter! ???
Grüße, picass
Zitat von: picass in 10.09.2022, 17:40:36 CESTDas haben sie jetzt von ihrer Trickserei...
:)) Wie würdest du denn negative Zahlen binär darstellen.
Für mich war das Zweierkomplement schon immer sehr plausibel.
Das MSB geht halt für das Vorzeichen drauf, wenn auch negative Zahlen vorkommen können
und der maximal sinnvoll verwendbare Wert bei 8-Bit ist eben nur 127 und nicht mehr 255.
Du entscheidest du als Programmierer ja selber.
Wenn du voraussetzt, dass keine negativen Werte vorkommen, dann kannst du mit Werten bis 255 rechnen.
Aber es macht dann nunmal keinen Sinn mehr das N-Bit abzufragen!
Zitat von: vloki in 14.09.2022, 13:26:04 CEST:)) Wie würdest du denn negative Zahlen binär darstellen.
Das kann ich dir genau sagen: Wenn ich eine solche Zahlendarstellung creieren würde, dann würde ein N-Flag, wobei das N ja für negativ stehen soll, seinem Namen auch voll Rechnung tragen und es würde nur dann, aber auch immer dann gesetzt werden, wenn der Wert einer Differenz "in Echt" negativ wäre. Um ein Rechnen so wie jetzt möglich zu machen, würde ich dann noch ein anderes Flag einführen - Name beliebig -, welches als Hilfs-Flag zuständig wäre.
Als "Verbraucher" sehe ich die Lage einfach: 8-bit ist eine rechte Einschränkung, halt nur 256 Werte verfügbar. Das hat schon Generationen von µC-Nutzern aufgeregt, die 16-Bitter, die 24-Bitter, die 32-Bitter, etc. lassen grüßen . Eine "Rechenmethode" einzuführen, welche diesen niedlichen Zahlenbereich auch noch zweiteilt in einen "sicheren" Bereich und einen, in welchem man mit unsicherem Ausgang rechnen muss, halte ich für eine Zumutung.
Es lebe - wenn auch mit Aufregung - der 8-bit-Microprozessor mit seinem kompletten 8-bit-Zahlenraum. Mit 7-bit-Microprozessoren oder einem solchen Zahlenraum möchte ich nichts zu tun haben. >:(
Ganz ehrlich.
Grüße, picass
Zitat von: picass in 14.09.2022, 15:34:38 CESTEine "Rechenmethode" einzuführen, welche diesen niedlichen Zahlenbereich auch noch zweiteilt in einen "sicheren" Bereich und einen, in welchem man mit unsicherem Ausgang rechnen muss, halte ich für eine Zumutung.
Die Verantwortung liegt beim Programmierer.
Der muss wissen, was er tut und die
passenden Flags als Hilfsmittel heranziehen.
Wenn man das N-Flag abfragt, dann geht man davon aus, dass es negative Zahlen gibt,
somit das MSB nicht mehr für den Zahlenraum zur Verfügung steht und nicht mit Zahlen > 127 gerechnet werden kann.
Die "a8" aus dem Eröffnungspost ist dann ja schon eine negative Zahl (-88).
Wenn man da noch "5" abziehst, kommt "a3" raus (-93). Passt doch ;-)
Mir gefällt nicht, dass die Verantwortung für diese Krücke dem Programmierer in die Schuhe geschoben wird. Würden - wie von mir dargestellt - zwei Flags verwendet, eines für die wahre Anzeige des negativen Wertes und eines für die technische Handhabung der Subraktionsrechnung im Zweier-Komplement, dann wäre das eine saubere Sache und die Verantwortung läge dort, wo sie hingehört, nämlich beim Ersteller eines Rechensystems, welches keine oder zumindest keine unnötigen Fallgruben bereit hält. Mir muss nicht alles gefallen, schon gar nicht, wenn es unnötig unvollkommen ist. Für mich ist die Logik nicht diejenige, dass man sich einer Krücke anpassen muss, sondern vielmehr, dass es bessere Lösungen ohne Fallen geben sollte.
Einem Sparkassen-Angestellten, welcher mir vermitteln wollte, dass die Mahnung der Überziehung meines Kontos zu Recht bestünde, obwohl von einem Guthaben von 2.500 € nur 250 € entnommen wurden, und der darauf hinweist, dass ihr System nun mal so rechnet, werde ich auch weder "Recht geben" wollen, noch sowas für gut befinden müssen. Das sollte nachvollziehbar sein.
Grüße, picass
Waterloo beim Rechnen !
Habe nach einer Pause die Spur der ,,Rechenkunststücke" in Assembler unter MPLAB X IDE bei Version 5.20 wieder aufgenommen. Da fasst einen nicht nur das Grauen, da ist das Ende des Rechnens mit dem PIC nahe.
Ein voll lustiges Beispiel für User mit Galgenhumor ist angefügt. Da soll in einer schlichten 8-bit-Subtraktion dieses gerechnet werden: dez'1' minus dez'244'. Der PIC kann sich nicht entscheiden, was er vom Ergebnis halten soll, weswegen er gleich gar kein Flag setzt, weder das N für negativ noch das C für positiv. Braucht man das Ergebnis für eine Sprungverzweigung, ist man am Ende, nichts geht mehr. So habe ich feststellen müssen, dass nicht nur das N-Flag gelegentlich nicht gesetzt wird, nix, das triftt auch für das C-Flag zu. Und einen daraus resultierenden ,,echten" Rechenfehler hatte ich auch gefunden.
In einem meiner Programme wird über einen analogen Eingang ein 10-bit-Wert eingesammelt. Der wird dann für die Ausgabe des bis 1.023 reichenden Ergebnisses auf vier Stück 7-segm.-Anzeigen als erstes umgesetzt: vier Variable sammeln die Werte für Tausender, Hunderter, Zehner und Einer ein. Für die Bildung dieser Variablen wird je eine Subtraktion benötigt und darauf folgt eine Verzweigung, je nachdem, ob was Positives oder Negatives rum gekommen ist. Da kann man es nur falsch machen: Setzt man auf das N-Flag, gibt es Fehler, setzt man auf das C-Flag, wird es nicht anders.
Was ein Schrott. Die neueren Versionen nach 5.35 haben eine völlig andere Syntax, sodass man komplett von vorne neu lernen müsste. In diesem Zusammenhang war schon mal von ,,Kultur-Schock" die Rede. Bin mit dem X IDE-Zeug am Ende.
Grüße, picass
Nachtrag:
- das zip-File enthält den kompletten Ordner, welchen das X IDE erzeugt, darunter dann auch das asm-File mit dem Programm.
- das Bild aus seinem Debug-Lauf zeigt das "Unentschieden" nach der Subtraction, der grüne Balken ist die Position des Debuggers.
Na ja, wenn du schon mit negativen Zahlen rechnest, dann gibt es eben keine .244.
Das ist dann -12! (hatten wir doch weiter oben schon, alles >127 ist dann negativ)
1 -(-12) = 13. Kein Überlauf und nicht negativ. Passt alles.
Verwende (lerne) irgendeine Hochsprache, dann musst du dich mit den Details nicht mehr plagen ;-)
Zitat von: vloki in 30.09.2022, 09:36:55 CESTPasst alles.
Nichts passt, siehe nachfolgendes Beispiel.
Die Croux beginnt bei so was scheinbar Simplem wie einer 16-bit-Subtraktion. Wenn 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. Ende der Erklärung und dafür die Bankrott-Erklärung der Subtraktion beim PIC unter den genannten Bedingungen – Assembl. und X IDE. Da sollte man nicht drum rum reden und da helfen auch keine Grundrechen-Beispiele, die keinen Bezug zur Realität dieser Problematik haben.
Wenn an einem analogen Eingang tatsächlich die Werte von 0 bis max. 10 bit vorkommen, dann kann nicht ernsthaft erwartet werden, dass man diesen Wertebereich in 8-bit-Dekaden zerlegt und die dann nochmal in zwei 128-bit-Bereiche und die Eingangswerte auf die entsprechenden Zugehörigkeiten abklopft. Das ist einfach Murks, wenn die Programmiersprache da kein verlässliches Arbeiten zulässt und dieser Murks sollte auch als Murks benannt werden.
Jetzt verstehe ich im Nachhinein auch, warum ich beim Ausbaldowern solcher Prog-Beispiele anderer Autoren ins Stolpern und Grübeln kam, warum das manchmal einfach nicht klappen wollte. Auch die weiter oben genannten beiden promovierten Autoren, die beiden Könige, sind in diese Falle getappt, ohne auch nur im Ansatz dieses Problem genannt und noch viel weniger, einen Ausweg aufgezeigt zu haben. Es war mir früher schon aufgefallen, dass deren Beispiele zu Rechenfehlern führten, ohne allerdings die Ursache gekannt zu haben.
Da bin ich nun echt ratlos, wie es weiter gehen soll, wenn niemand in der Lage ist, eine praktisch umzusetzende Hilfe zu geben. Das Assemblern möchte ich ungerne aufgeben. Es gibt Programme, die in diversen Steuerungen laufen und für die einfach Service in dieser Sprache bereit stehen muss.
Eine Frage wäre es, ob in den neueren Versionen der MPLAB-Umgebung dieses Prob beseitigt wäre.
Grüße, picass
Schade, die Nachbearbeitungszeit war schon rum.
Kann sein, dass ich mich wie weiland Münchhausen gerade am eigenen Haarschopf aus dem Sumpf ziehe, denn ich habe gerade in die PIC-Bibel geschaut, also in das Datenblatt. Und da gibt es sowas wie die "compare"-Befehle. Die benötigen selbst kein Flag und erzeugen auch keines. Wenn die gleich stattfindenden Test das verifizieren sollten, was da versprochen wird, dann wäre das die Lösung.
Grüße, picass
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!
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)
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
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 ;-)
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
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
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
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?
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
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...
;-------------------
_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 ;-)
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
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
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!
;D 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 ;D
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:
...
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
endGepacktes Projekt im Anhang...
PS: die Kommentare sollte man evtl. noch überarbeiten.
(Da stehen noch einige Altlasten)
Noch ein beispielhafter Screenshot vom Watches Fenster:
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.
#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...
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
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.
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
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 :o
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
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 :o
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