DS18B20 connected to PIC16F628A

[Heckler]

Are you using a Pull-Up resistor on the onewire data line??

Here is an example project I wrote that is now located in the WIKI section under projects... It is also based on Bruce's code examples over at Rentron.


http://www.picbasic.co.uk/forum/cont...r-nine-of-them

It was written for a 16F690, so you may need to modify the configuration to fit your PIC.

There are two parts to my example...
The first is to read the serial numbers of the sensors.
The second to read one or more of the sensors connected to the SAME pin on your PIC.
(pay attention to the comments in the example code and it will tell you how to change the code to fit your number of sensors)

[lilimike]

Hi,
Yes I am using a 4.7k pull-up and I had seen your code, I had actually used the top part (modified for 16F628A)to read my device's 64 bit serial code and I used the bottom part and double-checked with the code on Bruce's website.
Unless the AnyPin is conflicting, I have a feeling my sensor is burned or something, I'm not sure why I can read its code and I get a reading of 85 degrees C but I will order some more and compare with new ones.

Thanks for replying.

Mike

[Darrel Taylor]

85 deg. C is the default power-on state of the temperature reading.
If you get 85 deg. then you are successfully reading the device.
If it stays at 85, then a conversion is not being performed.

Your program works here in the simulator, so it probably comes down to this.

Check the part number on the DS18B20.
If it is followed by a "P" or "PAR", then it's a parasitic power ONLY device.

A parasitic power only device will not perform a conversion if powered like a normal DS18B20.
You must drive the DQ line high for the duration of the conversion for it to complete.

[lilimike]

Wow!
I do have a P (In the part number that is)
So that is a different datasheet, difference in the code and different connection.
Pin 3 of DS18B20 originally presumed to be VDD is now NC so disconnected.
I modified the code as follow:

ReadSensor:
    OWOUT DQ, 1, [$55,str id\8,$44] 'instructs sensors to match[$55] this[ID] rom code and
                                    'initiates[$44] temperature conversion on matching sensor
    high DQ     ; added for parasite device
    pause 750   ; added for parasite device
    low DQ      ; added for parasite device
CkAgn:
    OWIN DQ, 4, [busy]              ' Check for still busy converting
    IF busy = 0 THEN ckagn          ' Still busy?, then loop
    owout dq,1,[$55,str id\8,$BE]   'instructs sensors to match[$55] this[ID] and start sending back scratchpad[$BE] 
    OWIN DQ, 2, [Raw.LOWBYTE,Raw.HIGHBYTE]' Read two temperature bytes, then end communications
    return

I should have used another port to drive an MOSFET but I don't have one right now and it still works by driving the DQ high.

So its all good now.

Thank you Darrel

Mike

[Darrel Taylor]

Great!

Since you are using 10-bit resolution, you only need to pause ~188mS.
Yes, it's still "<-- My favorite".

And it's probably best to release the pin instead of driving it low after the conversion.

    high DQ
    pause 188
    input DQ

[lilimike]

I changed the wait to 188 - tested ok
I was not aware that INPUT pin# was a way to release the pin and I kind of felt unsure as to why I set it low, I guess it was a psychological way of undoing the high.
Anyways looking in the PBP bible 5.41 it says that using TRISB.5 = 1 is a more efficient way, not sure if it is just because it is faster to write when setting all pins to input at once.
I figured not using anything might be even more efficient so I just removed the last line altogether and the reading is still good.

So do you think leaving it out is ok or is there a chance it might create issues?

Mike

[Darrel Taylor]

Anyways looking in the PBP bible 5.41 it says that using TRISB.5 = 1 is a more efficient way ...

It does say that, doesn't it?
Well, it's not entirely correct.

It would be more efficient than the first example in the manual INPUT 0, because it has to figure out what pin 0 refers to.
But there is no difference at all between INPUT PORTB.5 and TRISB.5 = 1. They both generate the exact same code.

I figured not using anything might be even more efficient so I just removed the last line altogether and the reading is still good.
So do you think leaving it out is ok or is there a chance it might create issues?

That should be OK too.
The following OW commands will control the TRIS bit and leave it in INPUT mode when it's finished.