Zitat von: pic18 am 16.05.2022, 21:11:02 CESTHast Du dir mal..... angeschaut?

Von der Schau bin ich angetörnt! Die Microchip-Jungs - und die paar Mädels - haben's halt drauf. Die 16x16-bit unsigned-Routine werde ich übernehmen. Übernommen hatten da schon andere was: die beiden bereits mehrfach genannten Könige. Da hat die Frau Dr. es sich nicht nehmen lassen, genau diese Routine fast wörtlich abzukupfern und als eigene auszugeben. Die Reihenfolge an einer unbedeutenden Stelle geändert und schwups..... Ein Fall für die Plagiats-Forscher. Behaupten kann ich das, weil die Kommentare hinter den Semikolons verräterisch exakt dieselbe Menge und Formulierung haben, nur die Variablen haben einen anderen Namen.

Klare Empfehlung für die Microchip-Variante: die Abkürzung der Variablen ist sofort verständlich, das Ergebnis steht auch genau da, wie beschrieben, im Gegensatz zu ... aber das Meckern über wenig gelungene Plagiate lasse ich jetzt mal. Also fast.
Danke dir für diese Hilfestellung, pic18.
Grüße, picass

Nochmal zu den "Hundert Fehlern" !
Habe mich noch an der Transformation einer weiteren, tollen Rechenroutine versucht: 32 bit geteilt durch 16 bit = 16 bit Ergebnis. Is klar, wieder der Speech des vorigen Jahrtausends, aus dem Zeitalter der PIC16, also irgendwas Mitte der 90-ziger Jahre. Is auch klar: das war wieder ein Schlag ins Wasser trotz aller Bemühungen und nunmehr gewisser Erfahrungen.
Aber einen Spass hat das dennoch erbracht, nämlich erneut der Kampf gegen die gefürchtete Hundertschaft der ominösen Fehler. Damit ihr nicht glauben könntet, dass da ein totaler Anfänger schon stolpert, bevor er überhaupt angefangen hat, bittesehr, diese Aufgabe in zwei Bildern für euch Cracs:

Unter den vielen anderen wird auch in den Zeilen 191 und 192 je ein Debug-Fehler vermeldet, und jeder von diesen beiden verhindert die Nutzung des Programmes. Wo liegt der Fehler? Und strengt euch verdammt noch mal an!
Bitte!
Grüße, picass

S I E E E C H !

Es ist vollbracht: der PIC18F14K22 hat gerade eben erstmals eine komplette Berechnung eines Taupunktes geschafft. Ist klar: war falsch! Da musste erst mal wieder eine Rechenroutine - die der Multiplikation - zur Ordnung gerufen werden, aber dann....
Dann vermeldeten zwei Register den Wert von h'3078', was das Eintreten des Erfolges bedeutete, hier die Temp von 12,4 Grados!

Natürlich: gemach, das ist ein erster Testlauf, da werden noch mehr kommen müssen. Und ganz sicher liegt da noch die eine oder andere Falle verborgen. Aber wenn das bis hierher gekommen ist, ist der Auftrieb groß genug, um den Rest zu schaffen. Der "Rest" bedeutet u.a. das händische Einlesen von 50 Spannungswerten, welche dann alle einem dazu passenden Umrechnungswert für Feuchtigkeit, ausgedrückt in Prozent zugeordnet werden müssen. Also eine ewig lange Messreihe.....
Dann das händische Eintragen der Werte in eine EEprom-Tabelle. Dann das Auslese-Prog für diese Tabelle, dann.....
Aber der aus meiner Sicht diffizielste Brocken, dem 8-Bitter diese Rechenoperationen beibringen zu müssen, ist geschafft. Wobei ich mal großzügigst davon absehe, zu erwähnen, dass ich mir die R-OP's erst selbst mal beibringen musste.
Aber na gut, erst mal 'ne Runde freuen, denn zwischenzeitlich - wenn mal wieder ein "nicht-erwartetes Ergebnis" auftauchte oder der Weg zum Ziel im Dunst nicht mehr zu blicken schien, war von Freude nichts zu sehen.

AUF DEN PIC !
Der hat auch mal ein Lob verdient!
Grüße, picass

Wieder was für Mathe-Freaks, diesmal wieder das Dividieren! Meine selbst erfundende Divisionsroutine war ja ganz nett, aber nur für 8 bit Zahlen. Heuer soll eine 14 bit-Zahl durch 4, evtl. später durch 8 geteilt werden. Eine Div durch 4 reizt zum Gedanken, "einfach" zweimal nach rechts zu shiften......ach, ist das einfach. Aber die beiden letzten Bits gehen dabei flöten.
Wenn ich erst 4 Stück 10-bit-Zahlen addiere - in 99% aller Fälle werden die Zahlen im Bereich von ca. 230dez bis 320dez liegen - , um sie dann durch 4 zu teilen, könnten dann nicht die letzten beiden unter den Tisch fallenden Bits das Ziel konterkarrieren, für eine ruhigere Zahlenausgabe zu sorgen? Is klar, die Beiden haben einen Wert von nur 3dez, aber lass ma'...?!?!
Nicht, dass durch dieses Rechenmanöver der Mittelwertbildung erst recht eine Unruhe eingeführt wird?!
Grüße, picass

benötigst Du denn die Kommastellen? Wenn ja, dann würde ich sie in einem neuen Byte schieben. Die Kommastellen kannst Du dann umrechnen. Ich hatte einmal eine Programm für den DS18B20 geschrieben. Dieses kann 4 Bits nach dem Komma auswerten.

Nicht wirklich, also die Kommastellen! Im normalen Prog ohne die Mittelwertbildung (MWB) tauchen keine auf. Interessant wäre es höchstens, nach der MWB evtl. eine Art Rundung für die letzte Stelle noch anzufügen. Im Moment ist das Prog noch in der Entwicklungsphase. Am besten teste ich es mal.

Testen muss ich leider auch das noch ungelöste Thema der Divisionen. Für 8 bit Div. ganzer Zahlen habe ich da was Ausreichendes, benötigt werden aber auch 16 bit-Divisionen. Habe gestern nochmal eure Links mit Hinweisen durchgeforstet, und so recht nichts gefunden. Entweder ist das eine Mischung aus - was weiß ich: "C" mit Assembler - oder es sind so stonealte von 1996 und früher, dass die damalige Assemblersprache kaum zu verstehen ist, siehe auch meine Versuche mit der Vorlauge aus dem Buch der beiden König-Doktoren.
Grüße, picass

warst Du schon auf dieser Seite? http://www.piclist.com/techref/microchip/math/div/index.htm

ich habe hier eine Seite gefunden, wo die Division erklärt ist. http://www.piclist.com/techref/microchip/math/div/div16or32by16to16.htm

Habe mir den Link auf eine der Seiten gespeichert und werde mir das beizeiten zu Gemüte führen. Dabei gefunden hatte ich ein Beispiel, das stammt zwar auch aus dem Jahr 1996, ist jedoch von der Schreibart her gut verständlich. Es gibt da anscheinend Programmierer, die schaffen es, ein gut leserliches Prog zu hinterlassen. Andere scheinen eher darauf aus zu sein, sich selbst als "Experten" raus zu stellen, denken aber nicht im Ansatz daran, da etwas Leserliches zu schaffen.

Hier mal ein kleiner Auszug aus "großer Mathematik", die Division einer 16-bit-Zahl durch 4 für Assembler-Freunde:

- das low-Byte (lB) zweimal nach rechts shiften;
- bit0 und bit1 des high-Bytes (hB) händisch auf bit6 und bit7 des lB übertragen.
  Händisch: Test auf ,,0" und entsprechend die beiden Bits setzen;
- das hB 2x nach re shiften;
- die beiden obersten Bits des hB auf Null setzen.

Grüße, picass

Da gibt es schon Putziges: der PIC mag meine Routine mit der Mittelwertbildung nicht.
Sobald sie eingefügt ist, steigt er nach ca. 6 Sekunden aus, indem er nur noch Nullen zur Anzeige rausgibt. Kommentiert man die Routine raus (durch Semicolon), zeigt er brav alles an, die Skala der zu erwartenden Zahlen rauf und runter. Ist sie wieder drin, zeigt er auch brav die Skala an, auch mit aktiven Veränderungen, aber eben nur in den ersten ca. 6 Sekunden....!
Pro Sec tätigt er - geschätzt am Geflimmer der Anzeige - ca. 10 Messungen. Demgemäß erledigt er gut 50 Messungen, danach führt er ein Eigenleben.
Grüße, picass

ich würde die Divison durch 2 so schreiben:

MOVLB VAR16; Bank laden

BCF STATUS,C; Carry Bit löschen
RRCF (VAR16)+1,F,BANKED; HI nach rechts schieben mit Carry
RRCF (VAR16),F,BANKED; Lo nach rechts schieben mit Carry

Im Carry bit steht dann die Kommastelle, die weiterverarbeitet werden kann

Das ist dann in welcher Prog-Sprache?
Nix für ungut, das verstehe ich nicht, rsp., es hilft mir nicht. In Assembler gibt es - soweit ich weiß - keine Möglichkeit, einzelne Bits von einem Byte in ein anderes direkt zu schieben. Diese Rotate-Befehle beziehen sich immer nur auf ein einzelnes Byte, das gilt auch für das Carry-Bit.

Diese spezielle Rechenroutine des Dividierens hatte ich mit mehreren Zahlen-Beispielen überprüft, das hatte immer das zu erwartende Ergebnis gebracht. Den Floh erwarte ich woanders: in der Routine steckt auch eine Schleife, vielleicht klappt der Aussprung nicht zuverlässig.
Grüße, picass

Das ist Assembler,
RRCF Rotate Right f through Carry

schiebt die Bits nach rechts, Bit 0 ins Carry-Bit und Carry-Bit ins Bit 7.
Wenn Du das Carry-Bit löscht und dann das Hi-Byte nach rechts schiebst, dann wird Bit 7 gelöscht und Bit 0  wird ins Carry-Bit geschoben. Wenn Du dann das Lo-Byte nach rechts schiebst, dann wird das Carry-Bit (Bit 0 vom Hi-Byte) ins Bit 7 übernommen, Bit 0 kommt dann ins Carry-Bit.
Das ganze kannst Du mit beliebig vielen Bytes machen. Du mußt nicht irgendwelche Bits extra ins andere Byte übertragen, das geht alles automatisch übers Carry-Bit.

0 -> C -> Hi-Byte -> C -> Lo-Byte -> C

Au man, pic18, da hab' ich echt was gelernt von dir! Hatte die Vorstellung, dass das Carry-Bit (CB) sozusagen ein persönliches ist, welches zu einem individuellen Byte gehört. Dass dieses CB gänzlich unabhängig und ohne Übergang jedwedem anderen Byte zum Nutzen zugeordnet werden kann, stand nicht auf meinem Radar. Danke für die Aufklärung, werde das baldmöglichst ausprobieren.

Baldmöglichst.....
Habe mich heute abgequält, den Floh in meiner Routine zur Mittelwertbildung (RzMMB) zu finden. Ich habe ihn gefunden und beseitigt, weiß aber nicht, wie  er heißt und warum er da war. Will sagen, der Fehler ist raus, das Gesamt-Prog - Anzeige einer analogen Spannung auf 4-stelliger-7-Segment-Anzeige läuft nun wieder sauber. Mit der RzMMB war nach 5 Sek Schluss mit Lustig und es wurden nur Nullen angezeigt. Nunmehr alles paletti! Ausgerechnet das Sicherheits-Feature in der Schleife, welches den Ausstieg ermöglichen sollte, falls mit dem Zählen was nicht klappt, war der Fehler. Die Si-Überprüfung habe ich aus der Schleife rausgenommen und davor eingefügt, nun läuft es. Warum das Gleiche in der Schleife zu ungutem Ergebnis führt, ist mir nicht klar. Aber im Moment reicht es mir, den Floh erschlagen zu haben. Warum der da war....., das lasse ich jetzt mal ruhen und gebe mich mit dem Ergebnis zufrieden.
Ach ja: danke für deinen Tipp mit der Relocate-Funktion, pic18.
Grüße, picass

Magst Du mal Dein Programm hochladen, dann kann ich mal darüber schauen.