Die 0,25 müssen meiner Meinung nach vom Runden auf halbe Kelvin stammen.
Alabel möge mich korrigieren - ich verstehe (ansatzweise) den Sensor etwa so:
Zwei unterschiedlich stark temperaturabhängige Oszillatoren treiben einen Counter an (bzw ein Oszillator inkrementiert den Counter, der andere bestimmt die Zähldauer).
Das Zähl-Register ist mit -55 initialisiert, in Zweierkomplementdarstellung (also als 16bit-Integer) - ABER um eine Stelle nach links geschoben.
Außerdem wird eine Nachkomma-Information gewonnen, die als "½-Kelvin-Bit" an der minderwertigsten Position des Zählregisters abgelegt wird.
Addiert man auf diese ½ jetzt konstant ¼, hat man nach abhacken des Rests effektiv auf halbe Kelvin gerundet.
Meine Vermutung ist also, daß die Inhalte von Count_Remain und Count_per_C nach der Formel wegen dieses Rundens 0,25 Kelvin zu groß sind, und daß deswegen auf den ganzzahligen Anteil (Temp_Read) des Ergebnisses der gebrochene Rest ((Cnt_PC-Cnt_Rem)/Cnt_PC) addiert werden muß, und ein viertel-Kelvin subtrahiert werden muß.
So, zurück zur Praxis:
Kannst Du mal ein paar Beispieldaten posten (also die vier Werte, Deine erhaltenen Werte kann auch der Simulator ermitteln) - dann könnte man auch ohne Sensor experimentieren.
Irgendwo im SRAM wird ein (Byte-) Array angelegt, in das die Bytes des Sensors eingelesen werden. (Das CRC mußt Du übrigens nicht unbedingt auslesen, wenn Du es nicht verarbeiten willst).
Code:
Array
1 Temp_Low
2 Temp_High
3 User_1
4 User_2
5 Res_1
6 Res_2
7 Cnt_Rem
8 Cnt_PC
9 CRC
Nötig sind die ersten beiden, die enthalten die gelesene Temperatur als 16Bit-Integer (also in Zweierkomplementdarstellung). Relevant sind neun Bits, wobei das LSB (least significant bit) einem halben Kelvin entspricht).
Für eine höhere Auflösung müssen dann "7" und "8" verarbeitet werden.
Zum Rechenweg:
Das "halb-Kelvin-Bit" ist laut Datenblatt zu verwerfen. Was aus dem Datenblatt nicht ganz offensichtlich ist ist, daß außerdem durch zwei geteilt werden müßte. Das Abschneiden erledigst Du etwas komliziert in den Zeilen126 und 127 (eigentlich solltest Du das Bit auch einfach Null setzen können ("Ar1(1).1=0"). Durch zwei teilst Du, indem Du mit verhundertfachten Werten arbeitest, aber nur mit 50 multiplizierst. Das ist Dezimal. Ich würde auf dem Binärsystem bleibend stattdessen mit 128 "multiplizieren" bzw erst "durch zwei teilen" und dann "mit 256 multiplizieren". Dazu wird das Temp-Doppel-Byte (Integer) einfach einmal nach rechts geschoben/gerollt (asymmetrisch). Kostet zwei Takte. Fertig. mit 256 multiplizieren ist noch leichter - das High-Byte beinhaltet jetzt keine Information mehr (außer Vorzeichen-Nullen oder -Einsen), ein Vorzeichenbit wurde in das Lowbyte gerollt. Wenn man sich dieses Lowbyte jetzt als Highbyte eines Integers denkt (dessen Lowbyte null ist), hat man das 256-fache (so, als wenn du im Dezimalsystem 'ne "0" an 'ne Zahl hängst und mit 10 multipliziert hast). Beim Denken hilft Dir Bascom, indem Du auf die Speicherzellen mit einem anderen Variablennamen zugreifst, der
Overlay definiert ist:
Code:
Array Temp_Read (Integer-Overlay-Variable)
Dummy = Temp_Read_L
1 Temp_Low = Temp_Read_H
2 Temp_High
3 User_1
4 User_2
5 Res_1
6 Res_2
7 Cnt_Rem
8 Cnt_PC
9 CRC
Overlay heißt, daß kein neuer Speicherplatz reserviert wird, sondern nur ein neuer Name (und/oder ggf ein anderer Datentyp) auf diese Speicherzelle zugreift.
Damit ist auch das "Makeint" aus Zeile 128 erledigt - der Sensor lefert Dir diesen Integer bereits. Laut Bascom-Hilfe rechnet Bascom Highbyte*256+Lowbyte - ich denke allerdings, daß einfach nur die beiden Bytes in den SRAM (zwei aufeinanderfolgende Adressen) kopiert werden. Das ist aber bereits der Fall. (Basom legt Integer und Words im SRAM so ab. Erst das Lowbyte, dann das Highbyte).
Die Overlay-Definitionen erzeugen keinen Code durch die Definition haben wir bisher mit nur zwei Instruktionen den ganzzahligen Teil freigestellt und mit 128 Multipliziert. Der Rest (Zeile 130ff) folgt noch. die Ausgabe muß dann natürlich auch angepaßt werden - Fusing geht nur mit singles oder?
"LCD integervariable" sollte natürlich gehen, aber dann zappelt die Anzeige wegen abgeschnittener führender Nullen.