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?Art...
What's All This Calculator Stuff, Anyhow? April 2, 1992

man beachte allerdings das Datum und den letzten Satz

LOL - herrlich!

>>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!