Gast
#444313
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?
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.
Gast
#444383
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?
Gast
#444390
Ich glaube kaum, dass dein Temperatursensor eine Genauigkeit hat, die besser ist als 1/256 Grad.
Gast
#444394
Das nicht, aber wie vergleichst du ein double (z.B. 21,43°) mit einer Zahl, die in eine ganze Zahl + Nachkommastelle aufgeteilt ist?
Gast
#444399
Gar nicht. Ich vergleiche einfach zwei Zahlen, die jeweils in eine ganze Zahl + Nachkommastellen aufgeteilt sind, miteinander.
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.
Gast
#444466
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.