DS18B20, 16F88 problem

[DynamoBen]

I have the DS18B20 connected to my pic on portB. Everything checks out electrically. However I always get a reading of 74F even when I throw the PIC into the fridge.

I have weak pullups enabled on portB and am not using parasite power. (I tried a 4.7K resistor already)

Thoughts???

The Code:

Show_Temp:
OWOut PORTB.6,1,[$CC,$44] ' Skip ROM search & do temp conversion

Wait_Temp:
OWIn PORTB.6,4,[Stat] ' Read busy-bit
IF Stat=0 Then Wait_Temp

OWOut PORTB.6,1,[$CC,$BE] ' Skip ROM search & read scratchpad memory
OWIn PORTB.6,2,[temperature.Lowbyte,temperature.Highbyte]' Read two bytes / end comms

temperature=((((temperature>>4)+50)*9)/5)-58

value = temperature/100
LCDOut $FE,LCDLine1+7,dec value,Deg,"F"
Return

[Darrel Taylor]

Ben,

Did you set the AN inputs to Digital?
ANSEL = 0, or at least ANSEL.5 = 0 (RB6 = AN5)

The way it is now, when temperature = 65535, you get 74degF. So it's reading the DS18B20 as all HIGH bits.

And the conversion is direct to deg F, so you shouldn't have to divide by 100 before displaying to the LCD.

<br>

[DynamoBen]

I already have ansel=0.

I will try updating my calculations. I was using the example off of the rentron site. http://www.rentron.com/PicBasic/one-wire2.htm

[DynamoBen]

After the calculation update I'm coming up with 0F.

Here are my defines:

@ DEVICE pic16F88, HS_OSC ' System Clock Options
@ DEVICE pic16F88, WDT_ON ' Watchdog Timer
@ DEVICE pic16F88, PWRT_ON ' Power-On Timer
@ DEVICE pic16F88, BOD_ON ' Brown-Out Detect
@ DEVICE pic16F88, MCLR_ON ' Master Clear Options (OFF=Internal/ON=External via resistor)
@ DEVICE pic16F88, LVP_OFF ' Low-Voltage Programming
@ DEVICE pic16F88, CPD_OFF ' Data Memory Code Protect
@ DEVICE pic16F88, PROTECT_OFF ' Program Code Protection

' // Fuses/Crystal Setup //
DEFINE OSC 20 ' 20mhz XTAL (change notes above)
FLAGS=0 ' Reset all flags
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' force RB6 and RB7 digital (16F88 only)
ADCON0=%00000000
TRISA=%11100000 ' PORTA set to Output/Input
TRISB=%00000000 ' PORTB all set to Input
OPTION_REG.7=0 ' 0=Enable Weak Pull-Ups on PortB
INTCON=%11000000 ' enable global and peripheral interrupts (11000000)

' // USART Intiz/Setup //
DEFINE HSER_BAUD 9600 ' 9600 Baud USART
DEFINE HSER_RCSTA 90h ' Enable USART RX
DEFINE HSER_TXSTA 24h ' Enable USART TX
DEFINE HSER_CLROERR 1 ' Clear all USART errors as they happen

' // I2C Intiz/Setup //
DEFINE I2C_SLOW 1 ' Compenstate for 20mhz clock when writing to DS1307
SCL VAR PORTB.4 ' I2C clock location
SDA VAR PORTB.1 ' I2C data location

temperature VAR WORD ' Temperature byte array
Stat VAR BIT ' Busy or not bit

' // Port Settings //
DQ VAR PORTB.6 ' One-wire data pin "DQ" on PortB.6

[Darrel Taylor]

I'm trying to figure out how you got that result, and I can't find anyway to make it come up with 0Fh.

Backtracking a bit, originally you said that you were getting a reading of 74ºF.
With this formula temperature=((((temperature>>4)+50)*9)/5)-58 temperature would have to be greater that 65500 to get 74ºF.

((((65535>>4)+50)*9)/5)-58 = 7403
Then dividing by 100 before displaying on the LCD will give you 74

That's why I think you're recieving all 1's (no response) from the DS18B20.

If you removed the /100, you should get 7403 instead of 0Fh. So This is really wierd. What changes did you make?

A few things to check...
What is the actual data being received? 65535?

How many loops are executed waiting for the conversion in Wait_Temp:? My guess here is that NO loops are performed because it receives a 1, apparently indicating that the conversion is complete, even though it's not working at all.

While the program is running, ground out the data pin. Does the reading change?

The OWIN/OUT portions of the program are fine, and should work. So there's got to be something going on with the hardware.

[DynamoBen]

How many loops are executed waiting for the conversion in Wait_Temp:? My guess here is that NO loops are performed because it receives a 1, apparently indicating that the conversion is complete, even though it's not working at all.

While the program is running, ground out the data pin. Does the reading change?

I put some serial debug messages in...as expected it never actually loops at the wait. If I ground DQ out PIC processor reboots.

I have gone thru that section of the prototype and found nothing wrong with the wiring. Very Odd.