In einem Projekt soll fleißig gerechnet werden. Ein PIC18F14K22 hat ja erbaulicherweise einen 8-bit-Multiplizierer in Hardware, also als Befehlssatz. Aber der ganze "Rest" muss irgendwie händisch im Programm ausgeführt werden. Nun muss ja nicht jedes Rad immer wieder neu erfunden werden.
Gesucht sind also fertige Routinen für Standard-Rechnungen wie 16-bit Multipl., Subtraktion und vor allem Division - is klar: in Assembler bitte sehr. Vermutlich gibt es sowas als Bibliotheken.
Gefunden habe ich was in einem stonealten Datenbuch von 1994. Aber - mit Verlaub - so recht kann ich mit denen nichts anfangen. Da sind eng und kleinst gedruckt auf 4 Seiten Programmschnipsel abgelegt in einer Assemblersprache, die längst nicht mehr brauchbar ist. Würde ich das in tagelanger Arbeit versuchen, erst abzutippen und dann in aktuellen Speach umzusetzen, reicht ein einziger Fehler/Irrtum, um alles ad absurdum zu führen.
Bei Sprut habe ich da auch keine Aufstellung gefunden. Kann mir jemand einen Hinweis auf solche Mathe-Routinen geben?
Grüße, picass

Hier warst du schon ?

http://www.piclist.com/techref/microchip/math/index.htm

http://goumas-info.de/page10.html

http://ww1.microchip.com/downloads/en/DeviceDoc/39500a.pdf
16*16 Bit Multiplizierer. S 124..

http://www.schulheft-ottakring.eu/vane/Schule/Literatur/PIC/Gooligum/Intro%20to%20PIC%20Programming%20gooligum%20Base%20A/PIC_Base_A_11.pdf

kann man sich auch mal anschauen

Ganz herzlichen Dank für eure Anregungen. Habe die auch alle angeschaut, und nach zahlreichem Stirnerunzeln mich zwecks eines ersten Versuches einer Division für ein scheinbar gut dokumentiertes Beispiel in/aus einem Buch des Markt&Technik Verlages aus dem Jahr 1996 entschlossen, die Autoren: Dr. Anne König plus ihr Mann.

120 dividiert durch 20 ergibt 3 !!!!! Nach Wahl auch schon mal 7.
Beim Versuch der Übersetzung des Speeches für PIC16F8X-Typen in Assembler für den PIC18F14K22 hängt es anscheinend an zwei Ausdrücken, die zumindest ich nicht einsortieren kann:
1) - BCF STATUS,CY     Das damalige Register STATUS kennt aber kein "CY" und im Prog ist auch keine solche Variable definiert.
2) - SKPNC    watt is dat??? im damaligen Befehlssatz gab es sowas nicht. Soll vielleicht heißen skip if not carry?!
Warum verwendet Frau Dr. einen nicht einsetzbaren Befehl?!!!
3) Der Programmaufbau ist schon seltsam. Da wird nicht etwa subtrahiert, sondern zunächst der Nenner nach links rotiert, also jedesmal vom Wert her verdoppelt, was dann das Ergebnis von 3 erklärt, und danach wird der Zähler nach rechts rotiert. Bei Aufstoppen mit Breakpoint wird als Ergebnis 7 ausgespuckt.

Warum muss mir das immer passieren?: Blut, Schweiß und Tränen und ein irrer Zeitaufwand. Kann nicht mal jemand eine Routine geschrieben haben, in welcher 14550 geteilt durch 100 auch funktioniert? Das Zahlenbeispiel ist eines, welches demnächst gebraucht wird.
Muss wohl doch das Rad wieder neu erfinden. Weiß nicht, wie lange ich diesen Aufwand noch erbringen will.
Grüße, picass

frag Google
https://www.google.de/books/edition/Das_gro%C3%9Fe_PIC_Micro_Handbuch/HOJ2DwAAQBAJ?hl=de&gbpv=1&dq=BCF+STATUS,CY&pg=PA141&printsec=frontcover

Seite 141 - 142
STATUS,CY entspricht STATUS,C
SKPNC entspricht BTFSC STATUS,C

ich habe hier noch etwas gefunden
https://www.elepal.fi/antennit/pic/muldiv18.html

Zitat von: pic18 in 13.05.2022, 15:18:57 CESTSTATUS,CY entspricht STATUS,C
SKPNC entspricht BTFSC STATUS,C

Den Passus für "STATUS,CY hatte ich auch schon rausgefunden, ebenso wie den Ersatz für SKPNC. Bei Letzterem gibt es wohl zu bemerken, dass "BTFSC STATUS,C" ein ungewöhnlicher Ausdruck, weil doppel-gemoppelt ist. Während einer Subtraction wird ja das Carry-Bit von STATUS auf jeden Fall gesetzt oder eben nicht. Es reicht demnach, einen einfachen Sprungbefehl wie BC oder BNC einzusetzen.
Ist aber eine rein akademische Debatte, denn nichts davon nützt. Habe alle Versionen ausprobiert - es bleibt dabei: 120 dividiert durch 20 gibt 3 !

Wenn ich schon mal mecker, dann gründlich!   Von deinem neuen Beispiel habe ich zur Vorsicht und zum Einüben - bevor ich sowas Komplexes wie eine Division einer 32-bit-Zahl durch eine 16-bit-Zahl probiere - zunächst die voran gestellte Multiplikation 16 mal 16 bit ausprobiert.
Nach mehr als einer halben Stunde Arbeit und dem Versuch, auch diesem alten Speech - kenntlich an den equ-Anweisungen - auf die aktuelleren Sprünge zu helfen, ist nur dieses erreicht: siehe angehängte Fehlerdatei. Da läuft schon beim Umändern nichts zusammen, geschweige denn, ob und wie das Prog evtl. funktionieren könnte.

Ich schmeiße jetzt mal die Brocken hin, gehe in den Garten und lasse mein Ungemach am Unkraut aus.

Tut mir leid, pic18 ! Du hast dich sehr bemüht, mir zu helfen. Du bist echt ein lieber Kerl..... alleine, die Karre ist zu festgefahren und was vielleicht - vielleicht vor 30 Jahren mal funktionierte, ist ohne Wundertaten heute nicht mehr brauchbar. Und heutzutage arbeitet wohl kaum noch jemand mit Assembler.... und hat mit den Niederungen von Grundrechenarten zu Fuß nix mehr am Hut.
Ab zum Unkrautjäten, picass

Moment, der Anhang kommt noch, vielleicht...

BTFSC : Bit Test File, Skip if Clear
hat nichts mit dem Carry Bit zu tun, sonder Testet ob das Bit gelöscht ist. Du könntest aber auch schreiben BC bzw BNC (Adresse) wie Du schon gemerkt hast.

Deine 100 Fehlermeldungen sind seltsam.
WRDH kenne ich nicht

den Rest kenne ich wohl, allerdings vom C18 Compiler womit ich noch arbeite
MOVF f,d,a
MULWF f,a
MOVFF fs,fd
hast Du diese in Befehle in Klammer geschrieben? Versuche es mal mit Großschreibung ohne Klammer

ansonsten solltest Du das mal in C probieren. Allerdings mußt Du dann mit float Datentype arbeiten. Siehe IEEE 754 Format. Bei meinem C18 Compiler findest Du das unter /microchip/mplabc18/v3.47/src/traditional/math/divFP.asm

Zitat von: pic18 in 13.05.2022, 22:14:05 CESTDeine 100 Fehlermeldungen sind seltsam.

Wohl war! Immerhin war mir mit dem ersten Prog, dem der beiden "Könige" eine Umstellung des Speeches gelungen, obwohl das bei dem testweise ersten Aufruf des Debuggers mindestens genauso viele Fehler anzeigte. Bei dem zweiten Prog sperrrte es aber schon am Anfang. Was da im Argen lag......, man weiß es nicht und man wird es auch nicht mehr erfahren.

Denn danach hatte ich den Kaffee auf mit den tollen Progs aus dem Inet, sogar von Leuten mit Dr.Titel verfasst, sicher hoch raffiniert mit allen Profi-Tricks optimiert, ..... nur leider: 120 geteilt durch 20 gleich 3 !

Da hatte ich mich düster erinnert, dass eine Division sehr wohl ganz simpel als fortgesetzte Subtraktion des Nenners aufgefasst werden kann, halt solange, bis der Zähler ins Negative rutscht. Und - ach ja - so'ne Subtraktionsroutine für zwei 16-bit-Zahlen existierte doch in einem meiner früheren Programme. Dass die Routine dort funktionierte, bewies sich immer wieder, wenn ich in mein Auto kletterte und dem dicken Motor erlaubte, seine 6 Beine ins Traben zu bringen, wobei dann die Öltemperatur-Anzeige zum Rechnen kam.

In diese Subtraktions-Routine eine schlichte Schleife eingearbeitet und - TUSCH ! Das war's ! Also fast! Im Moment kann die Routine noch keine Stellen hinterm Komma verarbeiten. Aber es wird höchstens eine gebraucht, und die lässt sich sicher interpolieren. Evtl. geht es auch ganz ohne Dezimalstelle ab, weil an die Genauigkeit keine besonderen Anforderungen gestellt werden.
Auch die Rechenzeit meiner nicht-hochakademischen Routine ist für den geplanten Einsatzzweck der Verarbeitung von Feuchtewerten höchstens dreißig-rangig: es reicht, alle halbe Stunde ein neues Messwert-Paar errechnet zu haben. In 30 Minuten schafft es der PIC bestimmt, seine 14 Durchläufe der Sub-Routine zu erledigen.....

Ach ja, meine nicht-hochakademische Divisions-Routine kommt bei Berechnung von 120 geteilt durch 20 auf das Ergebnis 6 !!!!
Wenn ich meinen Taschenrechner finde, könnte das für Entspannung sorgen!
Danke sehr für alle angebotenen Hilfen, ihr ward da sehr fleißig.
Grüße, picass

Heute ging es in den Dschungel! Will sagen, tief in die Niederungen der Zahlensysteme Dual-, Dezimal- und Hexadezimal-Systeme. Immer fleißig alle 3 Systeme gleichzeitig in Betrieb, hübsche, meist aber schnell hingeworfenen Skizzen, viel mit Papier und Bleistift.... Was ging ab?
Nach der Division wollte ich auch die Multiplikation endlich in den Griff bekommen. Is klar, im Eigenversuch.
Der 8-bit-Multiplikationsbefehl des PIC18F14K22 ist ja schon ganz nett, aber was is mit 16 bit? Irgendwann klappte die Multi einer 16 bit x 8 bit Zahl, aber das Umgekehrte, also 8 bit x 16 bit komischerweise gar nicht. Wohl bemerkt: den 16-bit-Zahlenbereich wollte ich nicht verlassen, also nix mit 32 bit.
Wieder Grübel und Haarausfall..... und beim dritten Kontrollieren dann das:
für das Springen in den drei Zahlensystemen nutze ich einen Taschenrechner, der erstens älter ist und zweitens ein eher kleines Zahlenfeld hat. Und da hatte ich doch mal locker im Hexadezimalbereich das Zeichen "b" für eine "6" gehalten, und das ewig lange nicht bemerkt..... War mal wieder typisch für mein Ringen mit den Grundlagen.
Zum Zieleinlauf bis vor dem Start des Sonntagabends mit Tagesschau und Krimi hats aber so gerade noch gereicht, nun also auch die Multi im Sack, gettz kann es endlich losgehen.
Grüße, picass

ich rechne eigentlich immer im Hexadezimalsystem, das ist für mich einfacher als das Zehnersystem. Nach 0-9 kommen die Buchstaben A-F für Wertigkeit 10-15. Das Assemblerprog. vom Microchip.
http://ww1.microchip.com/downloads/en/DeviceDoc/39500a.pdf (siehe oben) hatte ich vor Jahren schon benutzt, es funktioniert.

Kleine Zwischenmeldung: Die "hundert Fehler" - siehe oben - finden zum größten Teil eine unerwartete Erklärung: Die Autoren König&König hatten in ihrem Programm einen Editor benutzt, der bewirkt, dass meine MPLAB-X-Versin 5.20 manche Leerstellen als Zahlen interpretiert. Das wars!   Fügt man an diese Stellen nachträglich "echte" Leerstellen ein, dann sind nur noch ein paar undefinierte Variablen etc. als Fehler übrig.
Was für ein Assemblerprogramm? Der Link zeigt auf ein Datenblatt. Bei die Gelegenheit: du hast mir einen Riesen-Gefallen erwiesen, ich wollte schon immer und endlich mal ein Datenblatt mit eintausend Seiten Länge durcharbeiten!
 
Grüße, picass

Hast Du dir mal die Section 6 ab Seite 123 mal angeschaut?

Selbstverständlich....!
Aber erst gerade jetzt, also nach dem Entdecken deines obigen Beitrages.
Danke sehr für den Hinweis. Das werde ich gleich in Angriff nehmen, will sagen, versuchen, das umzusetzen. Hatte gestern eine Multiplikationsroutine der beiden vorgenannten Könige mal getestet. Die hatte ich tatsächlich auch zum Laufen bringen können, obwohl sie anfangs auch so an die Hundert Fehler im Debugger verursacht. Dabei entdeckte ich die Ursache, nämlich die Verwendung eines Editors, der wohl eine Null anstelle einer Leerstelle hinter Befehlscode einfügte.
Als nochmal danke, muss jetzt ab zum Multiplizieren.
Grüße, picass

Zitat von: pic18 in 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.