Gast
#6472447
Hallo, beim DS18B20 liegen die Minusgrade ja zwischen 64656 und 65528 wie wandle ich diese Werte in Dezimalwerte am besten um? In Bascom. Grüße Franz
Franz Müller schrieb: > Hallo, > > beim DS18B20 liegen die Minusgrade ja zwischen 64656 und 65528 wie > wandle ich diese Werte in Dezimalwerte am besten um? Die Werte liegen als Zweierkomplement vor. Da muss man gar nichts umrechnen wenns um Negative geht (für den Wert in °C schon). In C kann der Wert direkt in eine signed Variable. Evt. mal den Wikiartikel zu Zweierkomplement lesen. https://de.wikipedia.org/wiki/Zweierkomplemen > In Bascom. Bascom hat sicher auch einen passenden signed typ.
Gast
#6472476
Cyblord -. schrieb: > Bascom hat sicher auch einen passenden signed typ. Ja, nennt sich integer. Welch' Überraschung...
Gast
#6472659
Zweierkomplement ist "normales" signed. Also nicht so eine Sauerei wie Vorzeichen und Betrag oder sowas. Solche Chips gibt's auch. Da frage ich mich dann immer, was die Entwickler geraucht haben.
Gast
#6473102
Man übergibt der Routine für die Plusgrade die Differenz 65536 - Sensorwert als Parameter und schreibt ins Display an die Plus/Minusstelle ein "-".
LostInMusic schrieb: > Man übergibt der Routine für die Plusgrade die Differenz 65536 - > Sensorwert als Parameter und schreibt ins Display an die > Plus/Minusstelle ein "-". Falls man einen schweren Hirnschaden hat: JA! Alle andere machen es richtig.
Gast
#6473430
Schön - und wie macht man es Deiner Meinung nach richtig? Einfach "STR(Sensorwert)" schreiben, weil die BASCOM-Funktion STR (Integer-zu-String-Konvertierung) schließlich das Zweierkomplement versteht? Das funktioniert hier leider nicht, denn dem Sensorwert 65535 = 0xFFFF ist nicht die Temperatur "-1 °C" zugeordnet. Wenn der DS18B20 mit 12-bit conversion resolution (*) läuft, ändert sich der Sensorwert nicht um 1, sondern um 16 pro Ein-Grad-Celsius-Temperaturänderung. Der -1 °C repräsentierende Sensorwert ist deshalb 65520 = 0xFFF0. Weil nun aber "STR(Sensorwert/16)" auch nicht funktioniert, würde mich interessieren, wie Deine Lösung aussieht. __________________ (*) was er höchstwahrscheinlich tut, denn die entsprechende Tabelle im DB passt zu den vom TO angegebenen Werten. Außerdem ist es die Default-Einstellung.
Gast
#6473455
Wie wäre es denn mit: STR(Sensorwert)/16 ??
Gast
#6473458
LostLogic schrieb: > STR(Sensorwert)/16 ?? Was soll das bewirken? Von den 16 Pixel hohen Schriftzeichen die unteren 15 Pixel wegschneiden?
Gast
#6473459
LostInMusic schrieb: > Weil nun aber "STR(Sensorwert/16)" auch nicht funktioniert Warum sollte das nicht gehen? 0xFFF0 ist -16 und -16/16 ist -1. Passt doch!
Gast
#6473471
"Falls man einen schweren Hirnschaden hat: JA! " Lol, und das schreibt offenbar einer dieser... Denn eine Auflösung gibt es nicht, die korrekte Bezeichnung solcher Menschen lautet Laberkopp
Gast
#6473579
>Warum sollte das nicht gehen?
Du hast recht, hier war ich im Irrtum. Das funktioniert - zu dem Preis,
dass die Division Sensorwert/16 in Fließkommaarithmetik gerechnet werden
muss. Die Nachteile (Flash-Speicher, Rechenzeit) sind hinlänglich
bekannt, aber vielleicht wird die Funktion sowieso gebraucht, dann
relativiert sich das.
Meine Lösung wäre übrigens, 10·Sensorwert zu berechnen, anschließend
einen Rechtsshift um 4 Stellen auszuführen und vom Ergebnis die
Hunderter-, Zehner- und Einerstelle zu berechnen. Kann man z. B. per
sukzessiver Subtraktion mit zuerst 100 und in der zweiten Stufe mit 10
machen. Für positive Temperaturen ist das schon alles (korrekte Rundung
auf eine Nachkommastelle inklusive!). Ist das MSB des Sensorwertes
gesetzt, liegt eine negative Temperatur vor (z. B. -4.5 °C --> 0xFFB8).
Dann vom Sensorwert das Einerkomplement bilden, 1 addieren und weiter
wie oben (plus natürlich ein '-' im Display anzeigen).
So würde es ohne FP-Arithmetik gehen.
Gast
#6473590
LostInMusic schrieb: > Du hast recht, hier war ich im Irrtum. Das funktioniert - zu dem Preis, > dass die Division Sensorwert/16 in Fließkommaarithmetik gerechnet werden > muss. Das ist purer Unsinn.