Makeint fügt irgendwie (rechnet zusammen) zwei Bytes zu einem (neuen/anderen) Integer zusammen. Die Quell-Bytes müssen dabei nicht unbedingt nacheinander im Speicher liegen. Da sie das bei uns aber bereits tun, braucht da gar nichts gerechnet zu werden - wir haben Bascom mit der definition ..at..overlay nur gesagt, wie die dort bereits liegenden Daten weiter zu behandeln sind.
Shiftout pumpt ein (oder auch mehrere) Byte seriell durch ein Bein des Controllers. Quasi über die serielle Schnittstelle (SPI), je nach Vorgabe auch in Software umgesetzt.
Fusing wandelt eine Gleitkommavariable (Single) in einen String um, der der dezimalen Darstellung des Wertes entspricht. Dabei wird die Darstellung bezüglich der Nachkommastellen nach einer vorzugebenden Maske getrimmt.
Wenn Du von °C auf centi°C kommen willst, mußt Du die °C mit 100 Multiplizieren. Da Du aber sechzehntel-°C als Wert hast, mußt Du auch noch durch 16 teilen.
Da Integer Ganzzahlen sind (und bei der ganzzahligen Division theoretische Nachkommastellen verschwinden), muß erst multipliziert werden, und zuletzt dividiert.
Vorher kannst Du natürlich kürzen.
Also mal 25 und durch vier.
Außerdem darf das Zwischnergebnis der Multiplikation nicht überlaufen. Der Sensor liefert maximal 2000dez bei 125°C, minimal -880dez bei -55°C.
Das Produkt würde (oben) leider nicht in eine 16Bit-Integer passen. Entweder man verschenkt die Auflösung, indem man erstmal durch zwei teilt (und ggf rundet), dann mit 25 multipliziert, und anschliessend nochmal durch zwei teilt.
Oder man legt die Temperatur-Variable auf eine größere Integer aus. (In Assembler gäbe es noch mehr Möglichkeiten) In Bascom wäre das eine Long (vorzeichenbehaftete 32Bit Integer).
CodeBox BascomAVR
dim Temperatur_L as Long
Temperatur_L=Temperatur*25
Temperatur_L=Temperatur_L/4 'effizienter wäre hier viermal arithmetrisch rechtsschieben, geht sicher auch in Bascom
'in String packen
'ggf an drittletzter Stelle ein Komma dazwischenschummeln (gibts sicher 'n Bascom-Befehl)
'ausgeben
Das wäre eine zusätzliche, neue (echte) Long-Variable zur vorhandenen Integer-Variable (die in Wirklichkeit nur Overlay im Sensordaten-Array liegt)
Im Gegensatz zur Overlay-Integer verbraucht diese neue Long also Speicher.
Verstanden?
Dann leg ich noch eins drauf:
Im Sensordaten-Array hast Du ja
Sensordaten(1)=Low-Temperaturbyte <-- hier greift außerdem die Integer Temperaturvariable (Overlay)
Sensordaten(2)=High-Temperaturbyte
Sensordaten(3)=ausgelesener TH-Alarmwert
Sensordaten(4)=ausgelesener TL-Alarmwert
Sensordaten(5)=Controlregister <--hier kannst Du die tatsächliche Auflösung des Sensors ermitteln, und per Fallunterscheidung die zu ignorierenden Bits in Sensordaten(1) löschen
Sensordaten(6..8)=reservierte Bytes
Sensordaten(9)=Prüfsumme
Wenn Du die Prüfsumme kontrollieren willst, mußt Du das machen bevor Du im Array irgendwelche Daten überschreibst (also zB die invaliden Bits).
Wenn Dich die ausgelesenen Alarmgrenzen interessieren, verwertest Du die jetzt.
danach verleibst Du die beiden Speicherplätz in die Temperaturvariable ein - Du definierst Temperatur also nicht als Integer, sondern als *Trommelwirbel* ... Long. Natürlich auch "at Sensordaten(1) overlay".
Wenn die Temperatur positiv war (also das MSB von Sensordaten(2) null ist), müssen diese beiden Bytes (in allen Bits) auch null sein. Wenn die Temperatur negativ war, müssen alle Bits eins sein.
Oder anders formuliert: der Sensor liefert das Ergebnis mit 16 Stellen(Bits). Wir deklarieren vorn weitere 16 Stellen hinzu, und füllen die führenden Nullen oder Einsen auf.
klingt komplizierter als es ist:
CodeBox BascomAVR
'Sensordaten in Array lesen
'Checksumme
'ggf Alarmwerte verwerten
'invalide Bytes mithilfe des ausgelesenen Konfigurationsbytes aus Sensordaten(1) löschen
'Sensordaten(3..4) in Temperaturvariable assimilieren
If Sensordaten(2)>127 then
Sensordaten(3)=255
Sensordaten(4)=255
else
Sensordaten(3)=0
Sensordaten(4)=0
end if
'Temperatur kann jetzt auf die korrekten vier Bytes zugreifen, und ist groß genug