Nybörjarhjälp för att hämta värden från DS18B20

[Oliver]

Jag med mina färska lekmannakunskaper generellt angående AVR och mikroprocessorer hoppas att någon mer lärd ska kunna förklara denna ack så simpla hantering av DS18B20.

Jag följer denna pdf om hur biblioteket är uppbyggt ganska slaviskt:
http://teslabs.com/openplayer/docs/docs ... 0_pre1.pdf


Men då jag inkluderar biblioteket förstår jag inte hur jag ska komma åt värdena som kommer från termometer i main- metoden.
Jag är inte intresserad av få ut värdet på en LCD display utan jag vill använda värdet senare som en parameter.

Så om jag nu ska komma åt värdet från termometern som en integer, säg int8_u.
Är det bara att kalla på metoden therm_read_temperature() då? Hur sparar jag värdet från den? Enligt metoden som jag förstår det är det uint8_t temperature[2] eller uint8_t digit jag är ute efter.

Ps. Vet inte om detta inlägg bör ligga under Programmeringstråden eller där den ligger nu. Ds.


Tacksam för hjälp/ enkelt exempel!

[sodjan]

Du får väl skriva om therm_read_temperature() så att den returnerar det format som du vill ha.
D.v.s skippa sprintf'en på slutet. Om det är digit eller decimal du vill ha vet jag inte, jag har
inte funderat så mycket på vad det är för format på dom. Men med hjälp av databladet
så borde man kunna lista ut vad de där skiftarna och maskningarna har för funktion.

[Klas-Kenny]

Just funktionen therm_read_temperature() i PDF'en tar ju en pekare till en strängvariabel (char-array) där den placerar resultatet i form av en sträng i denne variabel.

Du kan ju skriva om funktionen lite genom att tex. ändra funktionstyp till Double, ta bort argumentet och sprintf på slutet så att du inte gör om till en sträng, och sedan returnera digit+decimal.

Då kan du ju anropa funktionen sedan som tex. double temp = therm_read_temperature();
Eller om du istället vill ha resultatet som integer utan decimaler kan du ju istället sätta funktionstypen till int, och returnera endast digit.

Edit: Som komplement till Sodjan, det är enkelt att se vad av digit och decimal som är vad, bara kolla på formateringen av sprintf.

[jesse]

Jag har aldrig jobbat med DS18B20, men det verkar ju som om funktionen du hänvisar till, therm_read_temperature() omvandlar resultatet helt i onödan till textformat. Och det vill du ju inte.
(Nu hann både Sodjan och Klas-Kenny före mig... )
Så du ändrar lite i den funktionen så kan du ju få ut rådata direkt från DS18B20. Exakt hur formatet ser ut står ju på sidan 13, så då kan du ju plocka ut den information du behöver.

[sodjan]

Om det är "helt i onödan" beror ju på vad man vil ha.
Jag antar att man i exemplet ville ha just textformat.
Men så är det ju bara ett exempel...

[Al_Bundy]

Jag har jobbat mycket med DS18B20 och jag gillar den absolut inte.

[Zeela]

Vad har du emot den?
Jag tänkte mämligen börja använda den, så det kan vara intressant att veta om det finns nåt konstigt med den.

[Icecap]

Jag har jobbat (och jobbar) en hel del med DS1820, DS18S22 och DS18B20 och jag gillar dom skarpt! Fungerar bra, det är dock lite krångligt att få till programmet som läser dom om man vill ha fler på samma bus och deras lästider kan vara knepiga att få till om man inte vill köra med delay(), jag har dock lyckats köra näste helt utan delay()-funktioner och ha det hela interruptstyrd.

Slutresultatet är att systemet förvisso har en långsam (~1 sek) uppdatering av temperaturer men då de ändå ändrar sig ganska långsamt är det OK. Tidåtgången för programmet är minimalt då alla längre pauser är styrda av en timer-interrupt.

[Al_Bundy]

Vad har du emot den?
Jag tänkte mämligen börja använda den, så det kan vara intressant att veta om det finns nåt konstigt med den.

Jag skulle läsa av kod och helt plötsligt fick jag 85 och -127. Men när jag körde en annan kod som läser ut samma sensor på EXAKT samma sätt...då gick det. Alltså mitt fel var tydligen att kodar du för mycket så finns risken att den ej läser av. Jag vet inte vad det kan bero på. Något skumt var det.

Det kan vara en bugg.

[jako]

@Al
En bugg i sensorn eller i ditt program?

[sodjan]

DS18B20 har funnit länge så en bugg i *den* är inte speciellt sannolikt.

[Al_Bundy]

I mitt program så klart. Ibland tror man på spöken

[Oliver]

Löste sig fint det där! Tack för hjälpen!

@Icecap, av ren nyfikenhet. Varför vill man inte använda sig av delay() om man använder sig av flera komponenter på samma bus?
Är det bara att uppdateringen som blir långsammare samt att tidåtgången för programmet blir längre eller är det nåt annat som påverkas?

[robbie]

Är inte säker på det här men låser inte delay() processorn från att utföra annat parallellt?

[Icecap]

Oliver: delay() är generellt en styggelse! Om man (som jag) har en 32 bit µC som kör med 50MHz vill jag inte att ett delay() ska kasta bort 750ms (omvandlingstid för en DS1820) på att vänta!

Då är det mycket mer effektivt att ha en timer till att ge interrupt när det är dags och sedan köra vidare med annat under tiden. Och en enhet som ska ha 750ms för att omvandla är inte i desperat behov av att bli läst blixtsnabbt heller!

Det kan vara OK att använda delay() (liknande) funktion om det är mycket korta tider som ska vara exakta, annars är det alltid en timer-interrupt som gäller!

Sedan har jag det lite lätt då µC'n har ett antal timers som jag kan använda, t.ex. 4 st som uteslutande kan ge interrupt men som är helt utan kontakt med processor-pinnar osv.

I ett annat projekt med mer begränsad hårdvara läste/skrev jag en bit per interrupt och den interrupt körde var 100ms. Omvandlingen fick sedan ske vid att det räknades 8 st 100ms interrupts. Slutresultatet var att avläsningen tog sin lilla tid (men rikligt snabbt ändå) men att den använda väldigt lite processortid.