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://www.piclist.com/techref/microchip/math/index.htm)
http://goumas-info.de/page10.html (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 :D
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 ! :o
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 ! 8) 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! :o 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. >:D
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! >:D 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!
>:D
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. ;D
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. >:D
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! 8)
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! 8)
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. ;D
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.
Ja! :D
Aber nicht das mit dem Mittelwert, das habe ich vorerst aussortiert und durch eine einfache Zeitschleife ersetzt, was die gleiche beruhigende Wirkung hat. Aber es gibt seit heute ein anderes Rechenproblem, und da bin ich im Moment Matsche, weil ich nix verstehen!
Das jetzige Dilemma: in dem Regenerierprojekt werden über den analogen Eingang die Werte eines Spannungsteilers eingelesen. Weil die anfallenden Werte alle nur im Bereich zwischen 1 und 2 Volt liegen, hatte ich den ADC-Wandler angewiesen, auch nur diesen Bereich zu nutzen, wodurch die Auflösung besser wird. Prima, nur unterhalb des Bereiches, also von 0 bis 1 Volt liest der ADC folgerichtig nur Nullen ein. In einer Routine wird durch einfache Subtraktion überprüft, ob eine bestimmter Schwellwert überschritten wird. Und gettz die Überraschung: die Subtraktion des Wertes Null von dem Schwellwert, hier z.B. der Zahl 500 klappt nicht. Also 500 minus 0 ergibt ein negatives Ergebnis laut PIC.
In der Routine ist der Null-Wert in der Variablen adclow und adchigh abgelegt. Die 500 stecken in bitlow und bithigh. Also nun adc in das Wreg und dieses von bit subtrahieren. Im Falle des high-bytes klappt das, aber nicht im völlig gleichartigen low-byte. Ich werd noch irre, was sehe ich da nicht?
In der zip-datei steckt ein asm-File, das ist lauffähig mit MPASM5.2 für den PIC18F14K22
Grüße, picass
Ich habe schon lange nichts mehr in Assembler programmiert. Kann sein, das ich einen Denkfehler habe.
Ich würde es so schreiben.
schwell012:
MOVF ADLO,W,BANKED; lade ADLO nach W
SUBWF BITLO,F,BANKED; BITLO = BITLO-W
MOVF ADHI,W,BANKED; lade ADHI nach W
SUBWFB BITHI,F,BANKED; BITHI = BITHI-W-!C
BN negativ; verzweigt wenn Ergebnis negativ ist
BRA positiv_or_gleich; Ergebnis ist positiv oder gleich
hier wird allerdings BIT(Lo,Hi) mit dem Ergebnis überschrieben.
Danke für dein Engagement! :) Auch, wenn es ins Leere läuft! :(
Dein Prog-Schnipsel ist exakt so wie der meinige, nur dass du beim Highbyte noch das Carrabit berücksichtigt hattest. Aber das war - pardon - nicht das Thema.
Tatsächlich ging es darum, dass zwei exakt gleich geschriebene Subtraktionen jeweils von zwei Ein-Byte-Wörtern im einen Fall funktionierte, im anderen Fall jedoch einen Fehler produzierte, indem fälschlich das Negativ-Flag gesetzt wurde. In plattem Deutsch: zieht man von einer positiven, ganzen Zahl die Zahl Null ab, darf natürlich kein negatives Ergebnis rumkommen.
Um das Dilemma zu verdeutlichen, habe ich aus dem Mini-Prog von gestern die Subtraktion der High-Bytes raus gestrichen und nur diejenige der beiden Low-Bytes drin gelassen. Und wieder wird das N-Flag gesetzt!
Ein mathematisches Wunder ereignet sich! Schaut genau hin, ihr lernt eine absolut neue Mathematik kennen. Vergesst eure Schul-Kenntnisse und der Uni-Abschluss ist auch nichts mehr wert: Null abziehen und schon ist eurer Gehaltskonto fett im Minus!!!
Grüße, picass
Das Problem besteht in der ursprünglichen Version immer noch, also im dem Prog des Beitrages von 19 Uhr, vorgestern.
Das heute eingestellte Prog ist leider dafür misslungen, pardon für die Verwirrung. Aber im Beitrag von gestern (19 Uhr) sind zwei voneinander unabhängige Subraktionen dargestellt, deren Syntax nach meiner Sicht exakt gleich ist. Die eine funktioniert, es wird also kein Negativ-Flag angezeigt, die andere nicht, da gibt es trotz der Subtraktion einer Null ein N-Flag!
Grüße, picass
Zitat von: picass in 01.09.2022, 11:01:14 CESTDein Prog-Schnipsel ist exakt so wie der meinige, nur dass du beim Highbyte noch das Carrabit berücksichtigt hattest.
Das sehe ich nicht so, ich rechne das Ergebnis aus, während du die beiden jeweiligen Bytes vergleichst. Dann mußt Du zuerst die Hi-Byte vergleichen und anschließend die Lo-Byte. Nicht umgekehrt!
Du vergleichst also zuerst die Hi-Byte, wenn das Ergebnis kleiner ist verzweigst Du, ansonsten vergleichst Du anschließend die Lo-Byte und verzweigst dann entsprechend. Das Negativ - Bit sollte eigentlich nur bei einem negativen Ergebnis gesetzt werden. Du kannst aber auch noch das Zero-Bit testen, das Carry-Bit sollte invers zum N-Bit sein, das kannst Du auch mal testen.
Hab' den Bock gefunden, hat nichts mit der Behandlung von 16 bit-Zahlen, rsp. Ausdrücken zu tun. Passiert bei schlichtester Subtraktion von zwei 8bit-Zahlen:
Solange der Minuend kleiner ist als hex'a1', also dez'161', solange läuft alles korrekt. Sobald aber der Minuend gleich oder größer h'a1' ist, taucht nach der S das N-Flag auf. Wohlgemerkt, das Ergebnis ist richtig, also der Wert der Differenz wird korrekt angegeben, aber bei 180 minus 5 gibts mit dem Ergebnis 175 als Zugabe das N-Flag!
Verstehe wer mag , auf jeden Fall ein Fehler im MPLAB, rsp. dem Assembler.
Weil in meinem Programmteil für die Verzweigung dieses N-Flag abgefragt wurde, lief das Prog aus dem Ruder. Das muss nun also anders gehändelt werden.
Grüße, picass
ich habe im Moment leider nur den Linux-Rechner. Da kann ich die alte MPLAB nicht laufen lassen. Mit MPLAB-X kenne ich mich mit dem Simulator nicht aus. Verstehen würde ich es bei einem Wert >0x7F
Schau mal auf das Bild und beachte die Gleichzeitigkeit von N- und C-Flag ! >:(
Grüße, picass
Versteht jemand das nachstehend abgebildete Rechenbeispiel? Es handelt sich um Wurzelziehen, hier im Dualsystem:
-------------------------------------------------------------------
Quadratwurzel aus 2 binär
1. 0 1 1 0 1
------------------
/ 10.00 00 00 00 00 1
/\/ 1 + 1
----- ----
1 00 100
0 + 0
-------- -----
1 00 00 1001
10 01 + 1
----------- ------
1 11 00 10101
1 01 01 + 1
---------- -------
1 11 00 101100
0 + 0
---------- --------
1 11 00 00 1011001
1 01 10 01 1
----------
1 01 11 Rest
---------------------------------------------------------------------------
Gefunden wurde das hier:https://de.wikipedia.org/wiki/Schriftliches_Wurzelziehen
Letztlich geht es für mich um die Lösungs des Probs, für das Projekt Anzeige der Dieselpartikelfilter-Regeneration einen Weg zu finden, wie man aus den "technischen Zahlen", welche der Analog-Eingang des PIC ermittelt, diejenigen einer "echten" Temperatur ermittelt. Generell gibt es die zwei Wege: eine Tabelle anlegen und/oder via Formel berechnen.
Wahrscheinlich werde ich den Weg über eine Tabelle gehen müssen. In der sind die Temp-Werte in 10-er-Schritten festgelegt. Um nun die Zwischenwerte auch ermitteln zu können, sind ein Haufen Zeugs an Interpolation, Multipl., Division, etc. nötig. Die Formelnutzung (FN) wäre eleganter, würde eine irre Menge an Zeit ersparen, wenn die Vorbereitung der Ermittlung der Tab-Werte - für jeden einzelnen sind per Taschenrechner Umrechnungen nötig - wegfallen könnte. Die FN erfordert aber gegen Ende dieser Berechnung das Ziehen einer Wurzel. Da es um um ganzzahlige Temp-Werte geht, sind Nachkommastellen überflüssig.
Mit Verlaub: wie die "händische" Berechnung im obigen Beispiel funktioniert, hat sich mir nicht dargestellt. :(
Grüße, picass
Der 18F14K22 hat einen EEPOM mit 256 Byte. Lege darin eine Tabelle für die Temperaturen an.
Nimm die 8 höherwertigen Bits der ADC-Ausgabe (ADCON2:ADFM=0, ist Vorgabe nach Reset), dann hast Du schon die 256 EEPROM-Adressen und fülle diese mit den dazugehörigen Temperaturwerten.
Je EEPROM-Speicherzelle kannst Du ja nur Werte von 0...255 ablegen, was zu wenig für den gewünschten Temperaturbereich ist.
Du hast also die Wahl:
1.) 256 1-Byte-Werte, die noch mit einem Faktor (2, 3 oder 4) multipliziert werden müssen.
2.) 128 2-Byte-Werte aus je 2 aufeinanderfolgenden Bytes, die damit möglichen 1023°C reichen.
Und: Für diesen Anwendungsfall genügt eine relativ geringe Anzeigegenauigkeit. Selbst Sprünge von 10°C sind in dem Anzeigebereich von mehreren 100°C tolerierbar.
Du hast schon die Formel, also kannst Du z.B. mit EXCEL die Tabellenwerte berechnen.
Andere Möglichkeit: Mit einer "höheren" Programmiersprache ein Prog. schreiben, einen uC damit programmieren und den uC diese Werte berechnen in den EEPROM dieses uC schreiben lassen, diesen Inhalt als hex oder txt wieder auslesen und in Dein Programmiertool einlesen.
(Schreib' doch einmal die Formel hier ins Forum rein, damit man eine Vorstellung bekommt.)
Gruß
PICkel
Zitat von: PICkel in 12.12.2022, 14:45:06 CETAndere Möglichkeit: Mit einer "höheren" Programmiersprache ein Prog. schreiben, Gruß
PICkel
Hallo PICkel!
Die Hochsprache....! Sobald ausreichend komplett lauffähige Beispiele in unserem Projekt für PIC-Anfänger auch in Basic vorliegen, werde ich einen neuen Anlauf nehmen.
Die angefragte Formel:
Da befindet sich in einem Datenblatt einer Firma, welche den orig. Haereus-Sensor PT200 zur Herstellung eines realen Sensormoduls verwendet, eine prima Formel, siehe Bild1. Nicht prima ist es, dass diese Formel zur Berechnung des Widerstandswertes dient. In der ist der gewünschte Faktor T für Temperatur gleich zweimal enthalten, einmal davon noch im Quadrat. Beides führt zum Elend und zur Notwendigkeit, die Formel nach T umzustellen nach dem Prinzip einer quadratischen Ergänzung. Auf diesem Weg hatte ich mich verstrampelt und mir daher Hilfe organisiert. Die Auflösung der Formel und das Endprodukt findet sich im Bild2.
Da es - wie du auch festgestellt hattest - in diesem Anwendungsfall mitnichten um genaue Werte geht - eine Abweichung von 10° C wäre nicht schön, aber würde unterm Strich doch nützlich sein, könnte bei dem Handeln der einzelnen Werte durchaus großzügig vorgegangen werden. Es muss sich aber halt in den Assembler reinquetschen lassen.
Genau muss es natürlich nicht, der Weg über die Tabelle wäre ja auch noch da, aber auch aus Gründen der Neugier wäre der Formelweg schon eine tolle Sache.
Grüße, picass
Soooo, Du wolltest wissen, wie man so eine Berechnung in ein Programm überführt:
Ich habe mal die Formel sowohl in EXCEL als auch in mikroBASIC nachempfunden.
Die Rechnung wurde für eine Temperatur von 250°C ausgeführt.
Im EXCEL-Sheet steht die Formel in ihrer ganzen Schönheit in Zelle B8 und in D8 ist sie nochmal zum Mitlesen als Text abgelegt. Diesen Formel- Bandwurm will man sich sicher nicht in einem uC-Programm antun, denn soetwas zu debuggen grenzt an Masochismus.
Deshalb wurde die Formelberechnung aufgeteilt: Wert1...Wert4 und das Ergebnis der Wurzel. Siehe auch die EXCEL-Tabelle und Temp_Berechnung1.jpg. Damit wird die Sache übersichtlicher und man kann anhand der Tabelle die vom uC berechneten Werte kontrollieren.
In Temp_Berechnung1.jpg sieht man die berechneten Werte von EXCEL und die vom Debugger angezeigten Werte zum Vergleich. Das Prog. belegt 4198 Byte Speicher.
Eine leichte Verbesserung erhält man, wenn man die konstanten Ausdrücke
R0*alpha, (R0*alpha)^2 und 2*R0*beta vorab berechnet und als Zahlenwerte zuweist. Das Prog belegt dann "nur noch" 4028 Byte.
Die zweite Version ist in Temperatur.mbas vorhanden, aber auskommentiert.
Fazit: 32-Bit-Gleitkommaarithmetik auf 8-Bittern ist ein Speicherfresser und es macht sicher keinen Spaß, das in ASM zu proggen. Weiterhin übersteigt die Programmgröße das Limit der mikroBASIC-free-Version (2kByte).
program Temperatur
' PIC18F14K22
' Declarations section
dim alpha, beta, R_0, R_t as float volatile
dim ergebnis as float
dim Temperatur as word
dim Wert1, Wert2, Wert3, Wert4, Wurzel as float volatile
main:
' Main program
R_0 = 201. ' 0°C-Widerstand
R_T = 385.11 ' 250°C-Widerstand
'* erste Möglichkeit mit berechneten Werten:
'* 4198 Byte Programm, 6,93ms @ 8MHz bis NOP
alpha = 0.0038285
beta = -0.000000585
Wert1 = R_0 * alpha ' 201 * 0.000000585
Wert2 = Wert1*Wert1
Wert3 = 4*R_0*beta*(R_0-R_T)
Wurzel = sqrt(Wert2-Wert3)
Wert4 = 2*R_0*beta
'* zweite Möglichkeit mit vordefinierten Werten:
'* 4028 Byte Programm, 6,64ms @ 8MHz bis NOP
'Wert1 = 0.769529
'Wert2 = 0.592174
'Wert4 = -0.000235
'Wert3 = 2*Wert4*(R_0-R_T)
'Wurzel = sqrt(Wert2-Wert3)
'
ergebnis = (-Wert1+Wurzel)/Wert4
Temperatur = word(ergebnis)
nop
end.
Temp_Berechnung1.jpg
temperatur.zip
Hallo PIKcel!
Du hast – mal wieder – grundlegende Recherchenarbeit betrieben. Dafür ein herzliches Dankeschön.
Deinen Worten würde ich entnehmen wollen, das so'n 8-bit-PIC was den Zeitbedarf der Berechnung anbelangt eher nicht ein angesagtes Teil für solche Berechnungen wäre. Die Botschaft höre ich, wenngleich mir das – bitte beachten – in genau diesem einen Anwendungsfall egal wäre: die Änderung der Temperatur im Dieselpartikelfilter von der normalen Betriebstemperatur von irgendwas im Bereich von 180° C bis 250° C auf die Regenerations-Temp von irgendwas oberhalb von 450° C würde mindestens 2 min brauchen. Und die hohe Temp verharrt dann auch für gut 10 Minuten. Die Zeit wäre also kein Prob.
Aber sehr wohl habe ich vernommen, dass solche Formel in Assembler nur für Masochisten bearbeitbar wäre. Nun gut, da möchte ich mich – is klar – ungerne einreihen, also das lassen. Basic kann ich nicht, bleibt nur der Weg über die Tabelle. So gut, so schlecht. Das wird ,ne ziemliche Fleißarbeit, um das positiv zu verbrämen. Nochmal danke für deine aufklärenden Arbeiten.
Grüße, picass
Hallo picass,
das Formelungetüm mit Gleitkommazahlen lässt sich vermeiden:
Deinen Ausführungen vom 13.12.22 entnehme ich, dass Du den Wert von Rt schon berechnet hast, sonst würde ja die Formel keinen Sinn machen.
Schaut man das Diagramm an, so sieht man einen fast linearen Zusammenhang zwischen Temperatur und Rt. Geht man der Sache nach, so ergibt sich in guter Näherung folgende Formel:
Temperatur = (Rt-201)/0,71 (Die 201 ist der Widerstand bei 0°C)
Diese Formel hat im Wertebereich von ca. 300°C...600°C einen Fehler von <3%.
Das sollte eigentlich ausreichend genau sein. Schreibt man:
Temperatur = (Rt-201)*100/71 , vermeidet man die Gleitkommaberechnung mit dem Divisorr 0,71 und die Berechnung kann komplett mit Integer-Zahlen stattfinden.
Genauere Werte, vor allem am oberen und unteren Ende des Wertebereichs erhält man natürlich mit einer Tabelle.
Gruß
PICkel
Temp_Berechnung2.jpg
Au man, mit Zahlen hast du es. Mithilfe dieser stark verküzten Formel wäre es in der Tat möglich, zu arbeiten. Die Ergebnisse sind im Bereich von 200° C bis 500° C im Bereich eines Fehlers unter 10° C. Das wäre super. Oberhalb 600° C werden die Abweichungen größer, ab 700° C dann schon erheblich (25° C). Aber eine Anzeige bis 650° C würde für den angestrebten Zweck absolut reichen. Aber....
...aber nu weich ich mal von meinen theoretischen Vorüberlegungen ab und komme zum angetroffenen Fall der Praxis.
Der PIC18F14 liest an einem PORTA-Pin die sich just ergebende Spannung ab, welche abhängig ist von der aktuellen Temperatur im Diesel-Partikel-Filter. Das ist diejenige Spannung, welche am aktuellen Wert des PT200-Messwiderstandes abfällt. Wie das geschaltet ist und was sich da an Spannungen ergeben kann, ist im nachfolgenden Bild dargestellt.
Und das muss umgesetzt werden, im optimalsten Fall in die Anzeige "echter" Temperaturen. Es handelt sich um den Spannungsvereich - vergröbert gesagt - von 1 bis 2 Volt.
Grüße, picass
Das habe ich befürchtet:
Du hast nicht den Rt, sondern die Spannung an einem Spannungsteiler aus einem Fest- und einem variablen Widerstand zur Verfügung.
Die gemessene Spannung verhält sich stark nichtlinear zur Temperatur.
Nur mal als Bsp. aus Deinen Werten:
0°C: 0,83V
0°C bis 400°C: 1,639V ergibt (1,639-0,83)V/400°C = 0,0020225V/°C
0°C bis 650°C: ergibt: (1,967-0,83)V/650°C = 0,001749V/°C
400°C bis 650°C: 1,967V ergibt (1,967-1,639)V/250°C = 0,001312V/°C
Soviel erstmal zum Thema. Ob sich da etwas lineares draus basteln lässt, werde ich wohl nicht vor Samstag ausprobieren können.
Gruß
PICkel
Die Kurve bei einen Temperaturfühler ist nicht linear, man nimmt da Temperaturfenster und nimmt da einen linearen Wert an. So machen es auch ältere Thermostate mit PT100. Hier kann man manchmal die Werte eingeben. Also Temperaturwerte und Faktor dazu.
Hallo picass!
Ich habe mir das Ganze nochmal angeschaut.
Folgende Annahmen habe ich aus Deinen bisherigen Posts in Erinnerung:
- Speisespannung 5V (relativ stabil)
- Spannungsreferenzen am ADC des PIC: Vref- = 1V , Vref+ = 2V, also ADC-Messbereich 1V
- Im ADC-Mesbereich kann Rt= 250Ohm (65°C) bis Rt= 666Ohm (673°C) betragen
Der ADC hat bei 1V Messbereich und 10Bit eine Auflösung von ca. 1mV,
was einer Temp- Änderung von ca. 1°C entspricht. Das ist zu fein für diesen Anwendungsfall,
weil die Anzeige bei Änderung der Motorleistung nur am Zappeln wäre.
Deshalb schlage ich vor, nur die oberen 8Bit (ADRESH) des ADC auszuwerten.
Das gibt eine Auflösung von ca. 4mV in 256 Stufen, was einer Temp.-Änderung von ca. je 3°C entspricht.
In der EXCEL-Tabelle habe ich das in 10-er Schritten (40mV) nachgerechnet.
Aus der Spannung am Fühler lässt sich ganz einfach dessen Widerstand berechnen,
siehe Spannungsteiler.jpg.
Es gibt jetzt 4 Möglichkeiten der Temperaturberechnung:
1.) Multiplikation des Messwertes mit einem Faktor, das bringt bei konstantem Faktor Fehler bis zu ca. 50°C, siehe Spalte E in der Tabelle.
Also muss der Faktor je nach Wertebereich unterschiedlich angesetzt werden.
Siehe Beitrag von pic18
2.) Berechnung nach Deiner Formel, das ist ein ziemlicher Programmieraufwand in ASM
3.) Berechnung in EXCEL in 4mV-Schritten und übertragen der 256 Werte entweder als Tabelle ins Programm oder händisch in den EEPROM-Editor
4.) Erstellen eines entsprechenden Programms (könnte ich Dir machen) für den PIC
zum Beschreiben des EEPROM. Es ist dabei nur darauf zu achten,
dass beim nächsten Brennen der Anzeigesoftware der EEPROM nicht überschrieben wird.
Kleines Manko beim 18F14K22: Die 256 * 1Byte EEPROM. Entweder die 256 möglichen Werte mit 3 multiplizieren oder 128 * 2Byte ablegen.
Gruß
PICkel
Spannungsteiler.jpg Temp_Berechnung3.jpg Temperatur3.zip
https://www.heraeus.com/media/media/hne/datasheets/technical_information/Tabelle_Grundwerte_TK_3770_200_Ohm_DE.pdf
Hier ist die Tabelle vom PT200, warst Du schon hier? ich würde nur den ersten Teil der Formel nehmen
R0*(1 + 3,8285*10-3 * t), anschließend aus der Tabelle die Differenz je nach Temperaturfenster abziehen.
Zitat von: PICkel in 18.12.2022, 19:29:10 CETHallo picass!
Ich habe mir das Ganze nochmal angeschaut.
3.) Berechnung in EXCEL in 4mV-Schritten und übertragen der 256 Werte entweder als Tabelle ins Programm oder händisch in den EEPROM-Editor
4.) Erstellen eines entsprechenden Programms (könnte ich Dir machen) für den PIC
zum Beschreiben des EEPROM. Es ist dabei nur darauf zu achten,
dass beim nächsten Brennen der Anzeigesoftware der EEPROM nicht überschrieben wird.
Gruß
PICkel
Hallo PICkel !
Da es in Assembler mit dem Berechnen der Wurzel nichts werden wird, kommt die Version 3 und 4 zum Einsatz. Das ist zumindest technisch für mich einfach, da ich schlicht mein schon seit über 2 Jahren im bewährten Einsazt befindendes Prog für die Öltemperaturanzeige in meinem Wagen nutzen kann.
Da ist an den Anfang des Progs eine Abfrage des Inhaltes einer speziellen EEProm-Zelle vorhanden. Wenn da nichts programmiert war, dann kommt die leere Menge zurück, falls doch, dann die spezielle "Geheimzahl". Wenn die stimmt, dann läuft das Prog normal und zeigt die Öl-Temp an. Wenn die leere Menge kam, dann verzweigt das Prog "nach hinten" und dort steht eine Routine, welche im Programm aufgeführte Werte nacheinander in die EEProm-Zellen füllt. Das funktioniert prächtig und deswegen und aus dem vorgenannten Grund wird das demnächst irgendwann mal so ausgeführt. Bin - wie gesagt - gerade anderweitig unterwegs.
@pic18 Muss mal sehen, ob der Platz im EEProm für alles reicht. Hundert Werte im 16-bit-Format passen rein, dann ist aber auch schon Schluss. Das händische Berechnen wird noch 'n Hammer. Für die Zwischenwerte wird wohl interpoliert werden müssen
Einen herzlichen Dank für eure Bemühungen, ich werde sie memorieren!
Danke und Grüße, picass
Mal wieder Mathe-Nachhilfestunde!
Was ist das Gegenteil eines Logarithmus?
Anders formuliert geht es um das Ausrechnen dieser Aufgabe: 10 hoch 0,7148
Ergebnis ist 5,1860.... is klar. Aber wie rechnet man das ,,zu Fuß", rsp. zerlegt diese Rechnung in eine alternative Rechenweise, wenn der Computer, genauer das Prog das nicht kann.
Wenn man das erwünschte Ergebnis 5,1840 nimmt und davon den Logarithmus berechnet, erhält man den Exponenten 0,7148. Na prima, jetzt nur die Umkehrung und das wärs dann. Dann könnte die Formel im Fred "Kellerbelüftung" berechnet werden, dies ist die letzte Hürde.
Grüße, picass
Au man, beinahe hätte ich es gehabt.... leider nur beinahe! :(
Habe in einer Anleitung für BASIC die "wissenschaftliche Schreibweise" für z.b. große, rsp. lange Zahlen gefunden, wie z.B.:
2*10², was im BASIC-Dialekt dann eingegeben würde mit "2E10+2" und das liefert dann erfreulicherweise via print-befehl als Ergebnis 200 dez . Jubel, also dann bei dem gewünschten Beispiel:
1*10 hoch 0,7148 im Basic eingeben "1E10+0.7148" um zu Ergebnis 5,186 zu gelangen. Man gelangt ja auch, leider zu 1 dez ! >:(
Ist die Eingabe von Dezimalzahlen kleiner 1 nicht vorgesehen? Oder muss das in BASIC irgendwie anders eingegeben werden?
5 Schritte vor dem Ziel und noch gestolpert....!
Grüße, picass
Hast Du die 185 Seiten Doku nicht genauer durchgesehen?
Die Schreibweise "2E10+2" (oder ähnlich) liefert Dir nur eine vereinfachte Darstellung der Zahlen.
Was Du brauchst, ist eine Potenzfunktion, z.B.: Zahl = pow(10, 0.7148), die Schreibweise des Funktionsnamens richtet sich natürlich nach dem verwendeten Compiler.
Gruß
PICkel
Und das ganze dann noch als FLOAT deklarieren
damit das Ergebniss stimmt.
Ne, ne: Nicht nur diese Doku kompletto durchgelesen, auch die englisch-sprachige Orig.-Version und zudem noch die für "MicroMite", was im Prinzip das Gleiche für den genannten 32-bit-PIC-Typen darstellt. Auch die Suche im Prog fand nichts außer "power"!
Eine "pow"-Funktion, rsp. irgendwas mit Quadrat gibt es in dieser Sprachversion nicht. In demjenigen Kapitel, in welchem die "wissenschaftliche Notation" aufgeführt ist, gibt es den Hinweis, dass die nur mit Fließkommazahlen funktioniert. Leider ist das ein sehr ungenauer Teil der Wahrheit und bezieht sich nur auf die Zahlen-Komponente vor der Hochzahl, also auf die "4,5" im nachfolgenden Zahlenbeispiel. print 4,5E+3
Für den Exponenten gilt das Gegenteil: nur Ganzzahlen, also ohne Kommastelle.
Der Hinweis auf die vorige Deklaration als Fließkommazahl läuft aus dem Grunde auch ins Leere. Egal, was man da macht, z.B. den Exponenten in Klammern setzen.., hilft nichts. Es werden nur Ganzzahlen verarbeitet.
Die im Inet findbaren Hinweise auf die Umkehrbarkeit der Funktion - wie oben beschrieben - würden ja zum Ziel führen. Nur sind sie wenig bis nicht verständlich geschrieben. In den vermeindlichen Ausführungen werden Zahlen und Variablen aus der Luft gegriffen und ohne Erklärung über die Herkunft genutzt. Nicht ein einziges Beispiel ist nachvollziehbar aufgeführt. Da hat mal wieder einer vom anderen bis zur extremen Potenzierung abgeschrieben, alle fanden sich ganz prima, aber keiner war auch nur im Ansatz in der Lage, sich adäquat für den Empfängerkreis auszudrücken.
Grüße, picass
Merkwürdig sollte aber eigentlich gehen. Dafür muss es doch
Befehle geben. In Mikrobasic sind das nur 2 Zeilen Code.
DIM Zahl as FLOAT
Zahl = pow(10,0.7148)
Das ist alles.
Du kannst es aber auch ohne Komma darstellen und berechnen. Und
zwar so: \( \sqrt[10000]{10^{7148}} \) Aber die Zahl wird dann wahrscheinlich zu
gross um sie zu berechnen.
Bin die Anleitungen noch mal rauf und runter: NIX !
Es gibt keine Funktion zum Potenzieren, auch nicht zur Basis 10. Habe auch in der Suchfunktion alphabetisch gewühlt, nix unter "p".
Auch weitere, wenn auch inzwischen sinnlose - weil sich im Kreis drehende - weitere Versuche: nix, als Exponent werden nur ganze Zahlen akzeptiert. Auch das vorige Festlegen einer Variablen und deren Deklaration als Fließkommazahl - was in dieser Basicversion durch das einfache Anfügen des Ausrufezeichens - "!" - direk an die Variable geschieht und dann diese Variable als Exponent gesetzt: funktioniert prächtig, solange es Ganzzahlen sind, aber sobald ein Komma, rsp. hier ein Punkt auftaucht, ist Schluss mit Lustig.
Das Schreiben als "wissenschaftliche Notation" war ja nur ein Hilfskonstrukt, weil eine Rechenfunktion mit Exponenten nicht existiert, nützt halt nur nichts.
Der Logarithmus zur Basis 10 wird korrekt ausgegeben, nützt nur ebenfalls nichts, ist nur eine Randbemerkung.
Dieses Umschreiben 1000. Wurzel aus 10 hoch sowieso wird auch nichts nützen: es gibt die Funktion des Wurzelziehens, aber die Eingabe von weiteren Zahlen ist nicht vorgesehen... wüsste auch nicht, wie man das händisch rechnen soll. Habe das spaßeshalber mal mit dem Taschenrechner versucht, aber schon der Versuch, die Potenz von 10 hoch 0,45 zu ermitteln, indem die hunderste Wurzel aus 10 hoch 45 errechnet wurde, schlug fehl. Da stimmt auch irgendwas nicht.
Weiß im Moment nicht, ob die Rechnung 10 hoch 0,7148 (als Beispiel) sich irgendwie anders ausführen ließe. Mist, ist die einzige Stelle, welche noch klemmt, sonst könnte ich das Projekt "Kellerentlüftung" wahrscheinlich elegant vom 18F-PIC auf so'n 32-Bitter umswitschen und das Prog wäre ruck-zuck fertig.
Da bin ich extra - nicht nur, aber vor allem - wegen der ungenügenden Rechenfähigkeit der 8-bit-Welt entflohen, nur um im "Hochbereich" auf dieselben Probleme zu stoßen.
Grüße, picass
Habe grade gelesen, dass MMBasic kein Compiler sondern ein Interpreter ist, der auf einem wohl schon älteren Befehlssatz aufbaut.
Probiere doch mal:
print exp10(0.7148)
oder vielleicht auch
print 10^0.7148
Das würde bedeuten das jeder Controller ein Bios
haben muss wo die Befehle interpretiert werden müssen.
Ob das dann für kleinere Prozessoren noch geht da sie ja nicht
soviel Platz haben. Und das ausführen des Programms müsste ja dann
auch länger dauern als wenn man es direkt in einem Compiler eingibt
und das Programm wird dann in eine Sprache übersetzt welcher der
Prozessor kann.
@Peter:
Stimmt! Das steht dazu auf mmbasic.com:
"MMBasic is written in ANSI C. It requires a 32 bit microcontroller and
uses about 94KB of program space (flash memory) and as little as 16KB RAM. It was originally written for the Microchip PIC32 series of microcontrollers but has been ported to the ARM STM32 and Windows/DOS."
Damit sind die minimalen RAM/Flash- Größen absehbar. Ganz abgesehen davon, dass wohl viele Befehle in Textform mehr Speicherplatz benötigen als die entsprechenden ASM-Befehle.
Der Interpreter wird beim Reset gestartet, ähnlich einem Boot-Loader und liest und interpretiert dann den Quelltext.
Und zeitkritische Abläufe muss man dann wohl doch in ASM schreiben, wenngleich die hohe mögliche Taktfrequenz vieles vereinfacht. Wie man aber für eine bestimmte Aufgabe die Anzahl der Prozessortakte bzw. die dafür benötigte Zeit feststellen will, ist mir unklar.
Gruß
PICkel
PICkel! Du Lauselümmel ! >:(
Hat nicht funktioniert! Also der erste Hinweis mit ,,exp10" ! >:(
Aber der Zweite ist voll eingeschlagen: gleich im ersten Versuch mit der hochgestellten Spitze hat's den erhofften Potenzwert zurück gegeben! Man könnte demgemäß also sich der These annähern, dass du doch schon so den einen und evtl. auch anderen Erfahrungspunkt in Sachen µC-Technik mal erhascht hattest!
>:D >:D >:D
Gut, an der Formulierung arbeite ich noch! Gibt vielleicht noch' Nachschlag.
Hatte die Aufzählung aller Befehle, Funktionen etc. mehrfach gelesen, nicht nur die Befehle selbst, sondern natürlich auch die Erklärungen dazu, aber da war nichts fürs Potenzieren. Es gab auch keine Zusammenfassung, rsp. Darstellung von Operatoren, mit denen sich mathematische Funktionen ausführen ließen. Warum das nicht umgesetzt wurde für den Fall des Potenzierens...., man weiß es nicht.
Ihr ahnt nicht, was das für mich bedeutet! Natürlich war ich in die neue Welt mit einer ziemlichen Erwartungshaltung gestartet, zumal die Redakteure im Heise-Verlag so voll des Lobes über diese Art des Basic-Dialektes waren. Gerade die langen und mehrfach hintereinander geschalteten Formeln in aktuell interessierenden Projekten waren ja der Grund für den Aufbruch gewesen. Und da gleich am Anfang schon ausgebremst zu werden, hat mir gestern und heute viel Frust verschafft. Nu' aber die Erkenntnis, dass es in der Ferne doch scheinbar unbegrenzte Möglichkeiten gibt, rsp. zu geben scheint, das ist schon eine tolle Sache. Besser als so manches Weihnachtsgeschenk!
Hatte heute morgen im Vertrauen auf die Zukunft schon Temp- u. Luftfeuchte-Sensoren, Ultraschall-Entfernungsmesser, ein Servo bestellt, gestern 2 kleine Displays..... nu' kann's wirklich losgehen. Der 32-ziger-PIC ist wohl zu kaufen, allerdings nur bei den Versendern, die aus den USA liefern, jeweils für gut 20 € Frachtkosten. Da hab' ich mich noch zurück gehalten, aber das liegt schon in der Pipeline der Absichten.
Jetzt freue ich mich erst mal. Dann noch mal. Dann sowieso.
Dann noch ein Dankeschön, Bernd
Na dann viel Erfolg!
Zur Liefersituation: TME hat noch PIC32 vorrätig. Achte auf den Speicherbedarf von MMBasic!
Ich kenne die Entwicklungsumgebung nicht. Deshalb, wenn Du einzelne PICs bestellst: Der BASIC-Interpreter muss in den PIC geflasht werden können, also entsprechende Möglichkeiten vorsehen.
Gruß
PICkel
Übrigens: Das ^ (Caret) ist keine Funktion sondern wird als Operator bezeichnet (Wie +-*/>< etc.).
Siehe https://geoffg.net/Downloads/picomite/PicoMite_User_Manual.pdf Seite 20.
Ich frage mich warum du einen Basic Interpreter nimmst. Warum muss es Basic sein? Nimm einfach einen Compiler, z.B einen C-Compiler.
Warum jetzt einen Interpreter verstehe ich auch nicht so ganz.
Besonders weil man da doch sehr eingeschränkt ist.
Ob jetzt C, Basic oder sonst was ist eigentlich egal aber sollte schon
ein Compiler sein. Aber wenn dir die ganzen Einschränkungen und Nachteile
nichts ausmachen und du damit gut Arbeiten kannst, ist doch alles ok.
Gemach, Freunde!
Ist echt rührend, wie ihr euch kümmert!
Erst muss ich was nachtragen und auch da muss ich durch: Dieses spitzige Zeichen fürs Potenzieren ist sehr wohl in der Dokumentation vorhanden und ich hatte es auch gefunden. Dies aber erst gestern Abend nach dem Einstellen meines vorigen Textes. In der Übersicht, welche diese Operatoren aufführt, steht's drin, aber da hatte ich vorher gar nicht gesucht, sondern nur in der ewige Seiten langen Aufstellung der Befehle, denen man einen eigenen Namen und eine Beschreibung gegönnt hatte. Also an den Plätzen, an welchen u.a. die mathematische Funktionen ihren Platz haben. Vielleicht hatte ich es gesehen, konnte aber damit nichts anfangen. Die Zeiten des ,,peek" und ,,poke" aus meiner Sinclair ZX Spectrum-Periode sind zu lange her, als das da eine besondere Erinnerung noch bestünde... viel zu lange her. Und gerechnet habe ich mit den Plastik-Kisten wohl eher sowieso nicht. Also... ich bin entlastet. Also fast. >:D
Natürlich: bislang benutzt hatte ich ein reines Terminal-Programm. Das sieht wie eine DOS-Box aus, auch pott-schwarzer Bildschirm mit winzig weißer Schrift. Das Ding war geeignet, um den allerersten Schritt zu gehen, nämlich zu prüfen, ob überhaupt eine Verbindung zustande gekommen war, und danach, ob ,,print 5*4" auch eine Zahl zurück gab, die mit meinen bescheidenen Mathekenntnissen sich in Übereinstimmung bringen ließ. Ansonsten war dieses T-Prog völlig unbrauchbar. Da konnte man nicht mal das erstellte ,,Programm", welches maximal aus 3 Zeilen bestand, speichern. Ne, das war nur der anfängliche Testbetrieb. Aber dafür war es gut, weil wirklich einfach in Betrieb zu nehmen war, und so war alles richtig. Bis dahin.
Die Inbetriebnahme des eigentlich angestrebten Basic-Progs erwies sich als holpriger. Da war die Dokumentation dann doch nicht – räusper – ,,idoten-sicher". Also heute etwas rum probieren, und – tusch – auch dieses ließ sich in Betrieb nehmen, die serielle USB-Verbindung herstellen, und endlich gabs auch keine Meckermeldung des für die Übertragung zuständigen Teil-Progs. Dann musste ich nur noch meinen HP41 anwerfen, um zu prüfen, ob denn die Zahl ,,20" dez korrekt zu erwarten gewesen wäre. Danach entstand meine allererstes Basic-Prog in dieser Umgebung und – is klar – da wurde wieder die berühmte eine LED zum Blinken überredet. Das Prog speichern, wieder aufrufen, ändern, ausführen....
Nun ist es vollbracht: der Anfang ist gesetzt und nu' könnte es losgehen. In der hatten Praxis aber nicht, stattdessen gehe ich zu meinem Elektro-Roller und roller damit zu der Einkaufsmeile. Also Entspannung für euch, für mich weniger, weil es draußen regnet, und mein Dank gilt euch allen.
Grüße, Bernd
Nachtrag: die erst gestern Mittag bei "Reichelt" bestellten u oben genannten Teile sind gerade eben via DPD angeliefert worden. Das geht schon fix heutzutage.
Schön hier..... am anderen Ufer!
Mein zweites Programm mit der neuen MMBasic-Interpreter-Umgebung:
neun Zeilen lang, drei oder vier hätten wohl auch gereicht, und es enthielt die komplette Abarbeitung der Formel, welche aus den zwei Eingangswerten: Innentemperatur (Keller) und Außentemp (sibirische Taiga) einen Taupunkt ermittelt. Hat auf Anhieb – hüstel – geklappt, und nach Abzug der Zeit für die Korrektur der vergessenen Klammern und der aus Gewohnheit ,,Falsch"-Schreibung des Dezimalpunktes noch in der Form als ,,Komma" vielleicht 5 min der Erstellung benötigt. Was bei meinem 18-er-Assembler-PIC Wochen der versuchten Kniffe, doch noch mit Zehner-Exponent und Logarithmus hin zu kommen, benötigte, war nun round-about nach zwanzig Minuten Geschichte.
Die Ausführungszeit wurde vom Terminalprog mit 1,5 sec angegeben, wobei ich aber davon ausgehe, dass diese Zahl die Gesamtzeit beinhaltet: Kompilieren, rüber senden des Progs, in den Speicher verfrachten, es ausführen lassen, das Ergebnis zurück senden und auf dem PC-Monitor anzeigen. Ist mir aber auch für diesen Fall vollständig Wurscht, selbst eine Ausführungszeit von 1 Minute wäre für die angestrebte Anwendung noch rasend schnell.
Ich sitze hier immer noch und wenn ich doch nicht sitze, dann halt im Laufen mit kreisrunden Augen, verstehe irgendwie die µC-Welt nicht so richtig und staune mehr als die berühmten Bauklötze: Nix mit includieren vor dem Programmstart, kein ellenlanges Bearbeiten von Einstellungen, einfach anfangen mit Schreiben der Prog-Zeilen, hier drei Variable/Konstante benennen, los gehts und zack ist das Prog fertig. Auf das ,,Run-Symbol" klickern, die 1,5 sec abwarten und das Terminalprog spuckt das monatelang erhoffte Ergebnis in Gestalt der Temperatur des Taupunktes aus! Kreisrunde Augen, dass so was auch möglich ist!
Dem Hinweis von PICkel auf die Liefermöglichkeit des empfohlenen 32-PICs bin ich noch vor diesem Zweite-Formel-Erfolg heute Vormittag nachgekommen und habe zwei Stücke und eine winzige u evt. gar nicht notwendige Terminal-Platine gleich mit bestellt. Teuer.... Da sind fast 40 € drauf gegangen, das war ein Wechsel auf die ungewisse Zukunft. Ein sinnvolles Prog werde ich da schon rein bekommen. Ob der gewünschte Anschluss einer Anzeige und der Thermo-Sensoren klappt... Zukunft. Die winzige OLED-Anzeige (0,9") ist schon hier.
So recht glauben mag ich das alles noch nicht, es geht irgendwie zu schnell jetzt. Allerdings......
"in echt" dagegen habe ich auch nichts! >:D
Grüße, picass
Hallo
Vielleicht mal ein eigenes Thema dafür aufmachen, wenn es hauptsächtlich
um MMBasic geht, dann geht das nicht in dem langen Thread unter.
Euer ADMIN.
Dran gedacht hatte ich gestern Abend beim Einstellen auch, aber...
Aber das wirft für mich grundsätzliche Fragen auf, wie z.B. die hier:
Je nachdem, mit welcher Einstellung man Inhalte auf einen übergeordneten Begriff - wie auch eine Überschrift - runterbricht, kann man sehr wohl zu der Auffassung gelangen, es würden Berichte über forenfremde µC's - also keine PICs - eingestellt. Da frage ich doch mal ganz vorsichtig, ob das auch erwünscht ist oder nicht.
Grüße, picass
Das ist schon richtig das es ein PIC Forum ist.
Nun gibt es Programmiersprachen und Programme die auch mehrer Controller Familien
unterstützen. Wenn du einen AVR in deiner Sprache programmierst, so kann einer der nur Pic
programmiert in deiner Sprache, dir genauso helfen weil es eine gemeinsame Basis gibt. Da sind
die Unterschiede nicht so gross und andere mit dem selben Wissen in dieser Programmiersprache
können dann Hilfe leisten.
Aber ich würde für jede neue Funktion einen eigenen Thread aufmachen. Wenn du alles in einem
Thraed machst, so ist es schwer etwas zu finden. Und keiner liest einen Thread der über 100 Beiträge
durch, nur um etwas über die Ansteuerung von einem OLED zu finden. Da ist es dann übersichtlicher
wenn du dann dies in einem eigenen Thread machst und jeder kann direkt an der Überschrift sehen
worum es in diesem geht. Aber das überlass ich euch selber wie ihr es macht. Ich gebe dazu
keine Vorgaben.
Euer ADMIN.
Ich habe jetzt auch mal in C gerechnet. Ich will zwei 8 Bit Zahlen multiplizieren und als Ergebnis eine 16 Bit Zahl. Früher hatte ich solche Sachen mit einem Assembler Programm gemacht und dieses unter C aufgerufen.
Das lief sehr gut. Nun hatte ich gedacht, der C-Compiler müsste eigentlich die Grundrechenarten beherrschen, wobei ich auch noch mit ganzen Zahlen arbeite.
Ich hatte folgenden Code probiert:
typedef struct { //für zwischenspeicher h/min
int hour; // uint8_t hour --funktioniert nicht
int minute;// uint8_t minute -- funktioniert nicht
}timeHM_t;
timeHM_t xminuten;
xminuten.hour = 22;
xminuten.minute = 35;
minuten = (xminuten.hour*60)+xminuten.minute;
printOut(
"%i",
minuten);
hex_dec_ausg(minuten);Die printOut() Funktion ist nach dem Prinzip printf() aufgebaut und hat versagt. Es wird nur da Lo-Byte vom Ergebnis angezeigt und ein falsches Hi-Byte.
Nach langen überlegen hatte ich meine eigene Routine genommen. Ich hatte sie hex-dec-ausgabe genannt. Sie mit der Funktion itoa() und Stringausgabe programmiert. Das hat funktioniert.
Allerdings muss ich die Stunden und Minuten als Integer (16Bit) definieren. Um Speicher zu sparen läuft das ganze in meinen Programm aber mit 8 Bit und als Ergebnis will ich 16 Bit. Das bekomme ich aber so nicht gebacken. Hat jemand eine Idee wie ich zwei 8 Bit Zahlen multipliziere und als Ergebnis eine 16 Bit Zahl bekomme? Bei 8 Bits stimmt da Hi - Byte vom Ergebnis wieder nicht!
Das hat mir jetzt keine Ruhe gelassen. Ich habe es nochmal mit uint8_t (8 Bit) probiert. Überall vorher habe ich (int) davor geschrieben. Jetzt funktioniert meine printOut() Funktion und meine alternative Funktion.
if ((UBAMonitorFast.leistungIst)==0 && (pi_alt >4)){ //>4 bei Start auf 5 initialisiert
pi_alt = UBAMonitorFast.leistungIst;
xminuten.hour = 22;
xminuten.minute = 35;
Ta.hour = RCTime.stunden;
Ta.minute = RCTime.minuten;
minuten = (int)(xminuten.hour*(int)60)+(int)xminuten.minute;
printOut(
"\t7%bu:%bu\t>%i\n",
Ta.hour, Ta.minute,minuten);
hex_dec_ausg(minuten);
LCD_cr();
}
Das Witzige ist, wenn ich vor der 60 (int) weglasse, dann bekomme ich als Ergebnis 75 jeweils angezeigt. Das ist der Wert des Low-Byte.
minuten = (int)(xminuten.hour*60)+(int)xminuten.minute;// Ergebnis 75, 0x4b anstatt 0x054b
Zitat von: pic18 in 06.01.2023, 22:27:12 CETDas Witzige ist, wenn ich vor der 60 (int) weglasse...
Meiner Meinung nach ist das ganz normal. Das Ergebnis einer Operation hat den größten der Datentypen der Operanden, unabhängig davon, welchen Datentyp die Variable hat, in der dieses Zwischen-Ergebnis dann gespeichert wird.
Sind beide 8-Bit, dann wird das Zwischen-Ergebnis eben auch in 8-Bit rein gequetscht und erst danach in einer Variablen mit möglicherweise ausreichend großem Typ gespeichert
Casted man einen der Operanden auf 16-Bit, dann wird auch das Zwischen-Ergebnis mit 16-Bit berechnet...
ich habe alle Möglichkeiten ausprobiert, es muß immer die 60 gecasted werden. Alle anderen Operanten sind egal.
minuten = (int)xminuten.hour*60 + xminuten.minute;
funzt nicht?
Seltsam, mit dem XC8 bekomme ich es gar nicht hin ein falsches Ergebnis zu bekommen,
egal, ob cast oder nicht.
Was für einen C-Compiler benutzt du?
nein, muß immer (int)60 sein. Wobei ich mit jetzt gar nicht sicher bin ob int 2 oder 4 Byte sind. Short sollte nämlich 2 Byte sein. Ich benutze den alten c8? Compiler.
Beim C18 sind short und int beide 16bit.
Bei mir funktioniert das mit dem cast auch beim C18 (v3.40) egal wo...
seltsam, ich habe den C18 Compiler.
Mein Programm macht auf jeden Fall das was es soll :)
case ausg_schalthys:
stdOut_mr =stdOut;
stdOut = source_lcd;
//printOut("schalthys\n");
if ((UBAMonitorFast.leistungIst>0) && (pi_alt <20)){
pi_alt = UBAMonitorFast.leistungIst;
Te.hour = RCTime.stunden;
Te.minute = RCTime.minuten;
printOut(
"%bu:%bu",
Te.hour, Te.minute);
}
if ((UBAMonitorFast.leistungIst)==0 && (pi_alt >4)){ //>4 bei Start auf 5 initialisiert
pi_alt = UBAMonitorFast.leistungIst;
Ta.hour = RCTime.stunden;
Ta.minute = RCTime.minuten;
minuten = ((int)60*((int)Ta.hour-(int)Te.hour)+Ta.minute-Te.minute);
printOut(
"\t7%bu:%bu\t>%i\n",
Ta.hour, Ta.minute,minuten);
//hex_dec_ausg(minuten);
//LCD_cr();
}
stdOut = stdOut_mr;
break;
Zitat von: pic18 in 08.01.2023, 19:38:49 CETseltsam, ich habe den C18 Compiler.
Mein Programm macht auf jeden Fall das was es soll :)
Auch Umwege führen nach Rom 8)