Hallo, ich bin neu hier im Forum. Seit kurzem beschäftige ich mich mit AVR-Mikrocontrollern. Da ich bei der Suche nach einer kostenlosen Gleitkommabibliothek mit echten 64 Bit double Zahlen erfolglos war (für 8 Bit AVR Prozessoren), habe ich eine Gleitkommabibliothek für den PC, die ich vor einiger Zeit geschrieben habe, für AVR angepasst. Für klassische Mikrokontroller-Anwendungen ist eine solche Bibliothek wahrscheinlich etwas übertrieben. Da jedoch neuere µC zunehmend mehr Speicher bekommen, gibt es wohl auch einige Anwendungen, bei denen eine solche Bibliothek sinnvoll ist. Die Bibliothek ist so ausgelegt, dass man eine beliebige Genauigkeit einstellen kann. Dies bedeutet, dass sie nicht für 64-Bit Zahlen optimiert ist. Obwohl ich Funktionen wie sin, cos, exp, log, arctan schon entfernt habe, benötigt sie auf meinem ATMega32 immer noch etwa 25 kBytes Programmspeicher. Der Flash meines ATMega32 hat gerade noch ausgereicht, um als Anwendung einen Taschenrechner zu programmieren, den man mit einer RC5-kompatiblen Fernbedienung bedienen kann. Performancemessungen ergaben bei 16 MHz Taktfrequenz etwa 2000 Multiplikationen und 1000 Divisionen pro Sekunde, wenn man mit 64 Bit Mantisse (etwa 20 dezimale Stellen) arbeitet. Dies gilt bei der Division nur für das Standard-Verfahren. In meiner Taschenrechner-Anwendung musste ich aus Speichergründen jedoch ein anderes Divisionsverfahren anwenden (aktiviert mit dem #define DIVISION_DURCH_NEWTON_ITERATION in der Datei Gleitkomma.h), welches deutlich langsamer arbeitet. Die Gleitkomma-Bibliothek ist in C++ geschrieben und lässt sich mit avr-gcc compilieren. Wegen des hohen Speicherbedarfs sollte man µC mit mindestens 64 KBytes Flash bevorzugen. Außerdem muss man aufpassen, dass es nicht zu einer Kollision von Heap und Stack kommt. Die Bibliothek verwendet malloc(), prüft jedoch NICHT, ob malloc 0 geliefert hat (out of memory). Bei Speicherknappheit gibt es wahrscheinlich einen Crash. Außer meiner Gleitkomma-Bibliothek verwende ich in der Taschenrechner-Anwendung den RC5-Code von Peter Dannegger und Code für LCDs von Peter Fleury. Ein USART-Code von Ulrich Radig ist in der ZIP-Datei ebenfalls enthalten, aber in der Taschenrechner-Anwendung wird er aus Speichergründen nicht kompiliert. Bugs bitte hier im Forum melden.
Auch wenns nichz zum Thema gehört. Wo hast du diese tolle LCD Libary her :) Find ich super. ABer dein Gleitkomma dings ist auch super. Benutze ich jetzt für nen Frequenzzähler.
Robin Tönniges wrote: > Auch wenns nichz zum Thema gehört. Wo hast du diese tolle LCD Libary her > :) > Find ich super. ABer dein Gleitkomma dings ist auch super. Benutze ich > jetzt für nen Frequenzzähler. Steht doch im File. Von Peter Fleury ;)
@ Robin Tönniges (rotoe) >Find ich super. ABer dein Gleitkomma dings ist auch super. Benutze ich >jetzt für nen Frequenzzähler. Clevere Leute nehmen Festkommaarithmetik. MfG Falk
Und wie willst du z.B. einen wissenschaftlichen Taschenrechner mit Festkommaarithmetik programmieren ? Um z.B. Größenordnungen von 10 hoch -100 bis 10 hoch 100 verarbeiten zu können, müsste man schon Festkommaarithmetik mit 100 Stellen vor und 100 Stellen nach dem Komma benutzen ==> nicht gerade effizient (in Bezug auf die Ausführungszeit). Der Vorteil von Festkommaarithmetik ist lediglich, dass man deutlich weniger Programmcode benötigt. Und in manchen Fällen ist Festkommaarithmetik schneller als Gleitkommaarithmetik, nicht jedoch bei meinem Taschenrechner-Beispiel.
In so einem Fall macht das Sinn, aber bei einem Frequenzzähler, bei dem schon die 5. Stelle hinter dem Komma mehr von der Luftfeuchtigkeit, Betriebsspanung usw. als von der Frequenz abhängt, ist eine 32kByte große Fließkomma wohl ein wenig fehl am Platz...
Die 32 KB Fließkomma-Bib ist meiner Meinung nur dann fehl am Platz, wenn man sich wegen ihrer Größe in anderer Hinsicht einschränken muss, um die Anwendung noch in den Speicher zu bringen, oder wenn die Geschwindigkeit zu gering ist. Bei einem ATMega32 kann das schon mal vorkommen. Bei einem ATMega644 gibt es schon mehr Spielraum, und der ist auch nicht besonders teuer. Wenn man einen "ganzen" ATMega nur für einen Frequenzzähler verwendet, ist es auch egal, ob 5 % oder 99 % des Flashs voll sind. Viele der heutigen µC sind mindestens so leistungsfähig wie der gute alte C64 (wenn man mal von der geringen SRAM-Größe absieht). Und im C64 gab es nicht umsonst 5 Byte große Fließkommazahlen. Der Arithmetik-Code passte jedoch zusammen mit einem BASIC-Interpreter in 8 KByte ROM hinein. Zugegeben, meine Gleitkomma-Bib ist kaum optimiert, und man könnte die Codegröße und die Ausführungsgeschwindigkeit verbessern, wenn man nicht beliebige Mantisselängen unterstützen würde.
@Benedikt >aber bei einem Frequenzzähler, bei dem >schon die 5. Stelle hinter dem Komma mehr von der Luftfeuchtigkeit, >Betriebsspanung usw. als von der Frequenz abhängt, Das ist eine Unterstellung; es gibt hier sehrwohl Leute, die präzise Meßeinrichtungen entwickeln und bedienen können. Da macht sich einer mal die Mühe, die Rechengenauigkeit für float zu erhöhen und wird gleich wieder von Bastlern angemacht, Festkomma zu verwenden. Und das soll dann auch noch klever sein. Sicherlich haben diese Experten fertige Routinen in der Schublade, wie man mit Festkomma GPS-Koordinaten verrechnet. Viel Spatz!
Bob Pease hat mal nachgewiesen, dass Taschenrechner nicht mehr als 13 Dezimalstellen haben können, da dann das natürliche Rauschen die Auflösung begrenzt: http://electronicdesign.com/Articles/Index.cfm?ArticleID=6140 What's All This Calculator Stuff, Anyhow? April 2, 1992 man beachte allerdings das Datum und den letzten Satz
>>Da ich bei der Suche nach einer kostenlosen Gleitkommabibliothek mit >>echten 64 Bit double Zahlen erfolglos war (für 8 Bit AVR Prozessoren), Gibts hier Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"
Ich habe in der Funktion real::optimal_decimal_representation() meiner Gleitkomma-Bibliothek einen "unsauberen" Code gefunden und korrigiert. Er führte zwar nicht direkt zu einem Fehler, hing aber in unschöner Weise von einem speziellen Verhalten der Funktion real::to_decimalExp() ab. Die IEEE754-Gleitkomma-Bib. von Detlef_a ist ja kompakter und wohl für einen µC besser geeignet. Ich habe sie um sqrt, exp, log, sin, cos, tan, arcsin, arccos, arctan sowie um Dezimal-float64-Konvertierung und umgekehrt erweitert (siehe den obigen Link). Dies führt allerdings auch zu größerem Speicherverbrauch.
Hi. Habe mir auch mal die Codes runtergeladen, weil die Festkommaarithetik bei mir nicht funzt. Also deinen Versuchsaufbau finde ich am schärfsten!!! Nun weiß ich was "On the Fly" aufgebaut heißt ;-). Trotzdem vielen Dank für den Code!
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.