DS18B20.bas

Big Gaz · Post by **Big Gaz** » Thu May 26, 2011 9:27 pm

Hi Guys,

I need some help as I can't get an example program running and as I new to SF, I have properly made a newbie mistake.

The program below goes to the find function, but never comes back. I have proven this by forcing a true or false from within the DS18B20 module.

I'm using version 2.2.0.5 and ICC 1.1.5.5

Code: Select all

Device = 18F4620
Clock = 10

Include "usart.bas"
Include "DS18B20.bas"
Include "convert.bas"

Dim LED As PORTC.0 ' Status LED
Dim TempA As ShortInt ' Temp C from DS18B20
Dim TempB As Word ' Temp C from DS18B20
Dim tempf As Word ' Temp converted from C to F

SetBaudrate (br9600) ' Set serial port to 9600 baud
SetPin(PORTE.0) ' Assign pin RE0 to temperature probe

Low(LED) ' Set status LED to off
USART.Write ("Get Ready.....", 10, 13)

If Not Find Then ' Look for temperature probe
    USART.Write ("No temp probe", 10, 13)
Else ' Temperature probe found, process normally...

While true ' Do this loop forever
    High (LED) ' Turn ON LED to show activity
    Convert
    GetTemp(TempA, TempB)
    tempf = (TempA*1.8)+32
    USART.Write ("Temp = ", DecToStr(tempf), 10, 13)
    DelayMS (200)
    Low (LED)
    DelayMS (500)
Wend
EndIf

Jon Chandler · Post by **Jon Chandler** » Thu May 26, 2011 11:07 pm

A few possibilities come to mind:

1. Do you have an DS18B20? The DS1820 and DS18S20 don't work exactly the same and won't work the the DS18B20 module.

2. Is the DS18B20 a PAR (parasitic-power) or non-PAR version? Check the data sheets for proper connections for each variation. I believe either works as long as the connections are correct.

3. Do you have a 4k7 pullup resistor connected from the data line to +5v?

4. All the normal concerns about PICs apply:

1. 10k pullup on /MCLR

2. 0.1 bypass cap across the power pins.

3. ALL power pins connected.

4. Crystal with 22 pF caps to ground from each pin?

There are several articles at Digital-DIY about using the DS18B20.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 6:22 am

Thanks Jon,

I think the problem at my end is more a code issue, having the right chip and wiring is a side issue.

The example code is from a book and I'm assured the code has been tested, also I have tried two sensors which were not assembled by me but bought in factory wired units and connected to a dedicated header on a dev board.

That said, if no probe is found because of a faulty batch of probes or an assembly problem with the dev board, the find() function inside the module should return false aka no probe found.

At present the find() function just hangs and doesn't return true or false

I just need so pointers as to where to look

I know the DS18B20.bas code has several dependents, may be the problem is there. But I guess there are many users here that have had no problems with the code....

So is it a combination of modules code and hardware i.e. 18F4620 clocked at 10mhz

Code: Select all

If Not Find Then ' Look for temperature probe
     USART.Write ("No temp probe", 10, 13)
Else ' Temperature probe found, process normally...

Jon Chandler · Post by **Jon Chandler** » Fri May 27, 2011 6:42 am

Big Gaz wrote:Thanks Jon,

...having the right chip and wiring is a side issue....

Ummm....the right chip and correct wiring are far from a side issue. If there's a problem with these, perfect code isn't going to work.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 6:55 am

Hi Jon,

I might not be getting the point across very well and and I not knocking all the effort that goes in to writing these modules for us newbies to use and abuse.

The hardware I'm using functions for other code examples so I'm happy the CPU is functional and the code is in fact running. I have even added serial out messages to the code just before the find() function to ensure the code is running up to that point.

My point is that without a probe connected i.e. Port E.0 in this case. The find() function should return 'false' aka no probe found.

What appears to be happening, is the code is hanging somewhere in the DS18B20 module or one of it's dependent's. As the find() function is not returning 'false' or 'true'

I can put a debug serial out directly after the find() function and it never gets to that point.

I guess i'm going to have to work my way into the DS18B20 module and see whereabouts the code is hanging..

Just woundered if anyone else was having trouble with the combination of

PIC18F4620 running at 10mhz and the DS18B20 module before I dig deeper.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 7:01 am

Hi All,

Just in case I have done something stupid at my end....

The SF version I'm using is a standard install of SF (not SE), IDE version 2.2.0.5 and ICC 1.1.5.5.

On a Win7 64bit machine

And a standard install of MPLAB 8.70

All are in there standard directories....

Please tell me they are all compatible and I don't have to tweak any of them

Jerry Messina · Post by **Jerry Messina** » Fri May 27, 2011 10:30 am

On the 4620, pin RE0 is also analog input AN5.

Add a call to SetAllDigital() (found in utils.bas) before the SetPin() call. The default version of SetAllDigital should work ok for this chip from what I can tell.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 12:55 pm

Thanks Jerry,

The issue is no the fact that the module can't read the sensor, but the fact that the software module is hanging and not returning a true/false to indicate a temp sensor is fitted.

The code doesn't work even when I have no temp sensor connected, irrespective of how the port is set up.

Just as a test I did include the 'utils.bas' module and all the 'SetAllDigital', to eliminate the port, and I still have the same problem.

The code hangs at the find() function.

I will drill into the module code and try and isolate where it or one of it's dependents is hanging

Thx

Garry

Jerry Messina · Post by **Jerry Messina** » Fri May 27, 2011 1:56 pm

Yeh Garry, you mentioned that.

I've never used the OW module, but I can see where Find() could get hung up if the hardware's not functioning.

I could be wrong (and haven't actually checked this), but the outer 'repeat... until (LastDiscrepancy = 0)' in OW.Search() looks like it'll hang if the pin reads 0 constantly.

It would do that if the pin's set to analog mode, or if the pin's shorted to GND, or possibly if the pullup resistor connected to the data line's not present.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 2:01 pm

Thanks Jerry,

Thats a good starting point.

I will quickly re run the code, with a pull up resistor and with the SetAllDigital function call.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 2:33 pm

Ok, hands up I made a newbie mistake and didn't check to obvious first....

The example code I was using is not a direct match for the hardware I'm using, so the temp probe is hardwired to pin E1 and not E0 for which the program was written doh!

That has cleared up why we can't see the temp probe. What it doesn't do is tell us why the find() function is not reporting a missing probe and hanging.

I did run the code with the SetAllDigital and with a pull up (there is a 4k7 already on the board) and the probe when not connected causes the the find() function to hang still.

I guess we still have some investigation to do

Jerry Messina · Post by **Jerry Messina** » Fri May 27, 2011 3:25 pm

I'm running it with a different chip (and no sensor), but as long as I specify a port pin that has a pullup and shut off the analog function for that pin, then ds18b20.find() returns false as it should.

If I specify an unused analog or floating pin, then it hangs.

Big Gaz · Post by **Big Gaz** » Fri May 27, 2011 3:40 pm

Thanks Jerry

I was just about to post the same, I took the code back to the raw code in the book and simply included the 'Utils.bas' module and called the 'SetAllDigital' before the SetPin function and all works, false is reported when no probe is fitted and temp is read if probe is fitted.

Without the inclusion of the above and setting the pins to digital the code hangs.

Lessons learnt....

Read the datasheet, even if the code has been tested
Go back to basics when all fails

PS is there away to mark this post as closed or answered?

Thanks for everyones help, much appreciated

Jerry Messina · Post by **Jerry Messina** » Fri May 27, 2011 4:03 pm

Glad it's all making some sense.

Read the datasheet, even if the code has been tested

You may find this with a number of libraries. There are so many different chips out there it would be a full-time job just trying to keep up with all of them. While most of them are pretty similar, it seems Mchip just can't resist making subtle changes, so it's always a good idea to check. At least you have all the source code to everything and can change it if need be, which is one of the things I really like about SF.

Certainly you didn't have anything better to do than read the 400 page datasheet line by line to find the 'gotcha'?

PS is there away to mark this post as closed or answered?

Naw... it'll just sink into oblivion until next time.