Multiplikation (med 0.0625) utan flyttalsberäkning?

[Croaton]

Hej,

sitter och knåpar med lite 1-wire och DS18B20 och måste ha hamnat i en tankevurpa när det gäller att konvertera "AD-värdet" till decimaltal, för jag får det inte att stämma. (Jag vill alltså undvika att använda flyttalsberäkningar i Atmel AT90USB128'an jag använder)

Jag får alltså ett 12-bitars resultat från DS18B20 där varje steg motsvarar 0.0625 grader celcius.

Jag får i detta exempel 0x017F från sensorn vilket skall mot svara ~23.94 grader enligt denna beräkning:
0x017F (383) * 0.0625 = 23,9375 grader.

Eftersom 0.0625 är en 16-del av 1 så borde jag alltså kunna skifta 0x017F till höger fyra steg för att dividera med 16:
0x017F >> 4 = 0x17 = 23 grader

Heltalsdelen är alltså inte så svår... problemet får jag när jag vill plocka fram decimalerna. Den initiala tanken var att helt enkelt maska ut dom bitar som jag skiftar bort i beräkningen ovan och sedan shifta dessa till vänster, men jag får inte det att stämma:
(0x017F & 15) << 4 = 240 (vilket inte alls stämmer med min flyttalsberäkning ovan).

Shiftar jag 6 bitar så kommer jag upp i 960, men även det är ju helt fel. (samt att jag inte ser logiken i att göra det)

Så, vad har jag missat?

/Croaton

[Porto]

Gör en tabell för de 4 lägsta bitarna med decimalerna ,0000 ,0625 ,1250 ,1875 upp till ,9375
Avrunda till det antal decimaler som du vill ha, t.ex. ,00 ,06 ,13 ,19 upp till ,94
Heltalen får du ju som sagt genom de översta 8 bitarna av de 12 bitarna från sensorn.

Alternativt ta värdet från sensorn * 625 istället för 0.0625 och flytta decimalpunkten 4 steg åt vänster vid utskrift av värdet.

[Croaton]

Att multiplicera med 625 tänkte jag på, men det kändes inte helt rätt.... det är ju dock smidigare än en tabell.

Måste testa lite mera

/Croaton

[Swech]

Om din upplösning är 0.0625 så är ju presentation av 0.0x grader lite
väl brusig för att egentligen vara till någon nytta.
En tiondels grad är mer nära "rätt svar" än vad en hundradel någonsin kommer
att vara.

Visserligen är det ju fräckt med 2 decimaler och ingen lär väl kunna kolla hur
bra det stämmer...

Swech

[Croaton]

Swech: Så sant så, speciellt när DS18B20'n är specad att ha en noggrannhet på +/- 0.5 grader (mellan -10 och +85 grader).

Man skulle nästan kunna konfa om sensorerna att endast köra 9 (0.5) eller 10 (0.25) bitars upplösning... jag är dock av åsikten att jag gärna har så mycket detaljer som möjligt så tidigt som möjligt i "flödet". Det går ju alltid att avrunda innan man arkiverar / presenterar temperaturen.

/C

[Swech]

12 bitar x 625 (11 bitar) -> resultat 23 bitar innan skift.
Kan vara en utmaning i Assembler, men kul
Hojta om du kör fast....

(om du nu kör assembler)

Swech

[Croaton]

Haha, du har så rätt... men jag fuskar med C, jag försöker trots allt att få lite tid över till annat också

Jag insåg också att jag endast använder 10% av AT90USB128'ans flash, så jag kan gott kosta på mig att köra flyttal också :-D (Som vanligt så börjar man optimera innan det finns ett behov)

/C

[bearing]

Multiplicera med 16, så blir den höga byten heltalsdelen, och den låga byten decimaldelen. Blir som ett 16-bit fixed point tal.

[PaNiC]

Skulle trådskaparen vara intresserad av att dela med sig av koden för kommunikation med DS18B20?

[bearing]

Multiplicera med 16, så blir den höga byten heltalsdelen, och den låga byten decimaldelen. Blir som ett 16-bit fixed point tal.

Eller sampla givaren 16 gånger och summera värdena, för att få ett medelvärde vars decimaler faktiskt kan vara användbara.

Efter att ha läst höga byten (heltalsdelen), kan höga byten nollas. Multiplicera sedan resten med t.ex. 10, för att lägga första decimalen i höga delen, eller med 100 för att få de två första decimalerna.

[Croaton]

PaNiC: Absolut, ska bara se till att "libet" är komplett först. Just nu kör jag utan adressering och möjlighet att söka efter alla ROM's på 1-wire bussen.

bearing: Bra idé, skall testa det!

/Croaton