DS18B20, 16F88 problem

[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.

[DynamoBen]

Okay I'm stupid. The data sheet shows what I thought was a top image of the TO92 package...its actually a BOTTOM image. I have +5 and Gnd flipped. I'm allowed one mistake every once in a while.

Now that the hardware problem is corrected I'm getting a reading of zero again. I wouldn't think swapping 5V and Gnd would kill the sensor, would it?

[Bruce]

I have fried Dallas 1-wire parts before inserting them backwards for only a few seconds.

Try something super simple like reading & displaying the raw temp value returned. If that doesn't work, it's probably toast.

[Darrel Taylor]

In engineering, you're allowed to make lots of mistakes, as long as the next EC (engineering change) solves the problem.