double

[bst (Gast)]

double "verschwendet" im ATmega 8 Byte meines Wissens.
Wenn man nun Temperaturwerte im XX.X Format verarbeiten will, kann man 
das effizienter als mit double lösen?

[Benedikt K. (benedikt)]

Die Größe eines doubles hat nichts mit dem uC zu tun, sondern hängt vom 
Compiler ab. Bei avr-gcc sind es z.B. 4Byte.

Für Temperaturdarstellung verwende ich gerne Festkommazahlen im 8.8 
Format:
Ein Byte für die ganzen Zahlen (-128...+127) und ein Byte für die 
Nachkommastellen in 1/256 Schritten.

[bst (Gast)]

Daran habe ich auch schon gedacht, aber wenn man mit den GENAUEN Werten 
rechnen will (z.B. um Temperaturbereiche auszuwerten), kommt man wohl 
nicht um double umher, oder?

[Rolf Magnus (Gast)]

Ich glaube kaum, dass dein Temperatursensor eine Genauigkeit hat, die 
besser ist als 1/256 Grad.

[bst (Gast)]

Das nicht, aber wie vergleichst du ein double (z.B. 21,43°) mit einer 
Zahl, die in eine ganze Zahl + Nachkommastelle aufgeteilt ist?

[Rolf Magnus (Gast)]

Gar nicht. Ich vergleiche einfach zwei Zahlen, die jeweils in eine ganze 
Zahl + Nachkommastellen aufgeteilt sind, miteinander.

[Benedikt K. (benedikt)]

Ganz einfach: Man schreibt 21,43 nicht als double sondern als 
Festkommazahl:
21,43°C entspricht 5486.
Die Temperatur wird einfach mit 256 multipliziert und als signed int 
gespeichert. Damit lässt sich wunderbar rechnen, nur beim Anzeigen des 
Wertes muss man den wieder zurückrechnen: Das Highbyte kann man direkt 
anzeigen, dann kommt das Komma und danach noch die beiden Stellen von 
Lowbyte*100/256.
Dies ergibt die ersten beiden Nachkommstellen.

[Rolf Magnus (Gast)]

Im Prinzip muss man es auch nicht auf eine bestimmte Anzahl an 
Nachkommabits festlegen. Man könnte die Temperatur z.B. auch einfach 
direkt in Hunderstelgrad abspeichern. Dann fällt die Rechnung beim 
Anzeigen auch noch weg. Man kann die Zahl einfach so ausgeben und muss 
nur das Komma an der richtigen Stelle einfügen. Die 21,43° entsprechen 
dann eben dem Wert 2143.