• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

16F628A and DS18B20 temp sensors

Status
Not open for further replies.

Hakachukai

New Member
Does anyone know where I can find some asm source to read these sensors? I don't have a PIC basic compiler, but I do need to be able to read these sensors.

So far all the code I find on Google is in PIC basic. I do have the datasheet for the sensor... but I'd rather not have to spend a week reinventing the wheel.

Any help would be greatly appreciated.
 

Hakachukai

New Member
Thanks for the info. I've been reading over the datasheet a lot the past 12 hours or so. I definatly understand the concept of how it works, but that's still a lot of code to write / test. I was hoping that someone had already done it.

How would getting a compiler that supports a ds18b20 help? I've never heard of such a thing, but I'm trying to imagine how it would work.
 

Hakachukai

New Member
Oh... ok. So it's a module that contains prewritten routines for the specific chip, made to work with the DS18B20?

That makes sense... assuming that I'm thinking about it correctly
 

gaspode42

Member
Also check the MikroElectronica compiler(s) - free download (but with a code size limit)
 

Diver300

Well-Known Member
Most Helpful Member
This might help.

It is code I wrote some time ago to read a single DS18B20 using a pic16f628

You need to define the registers that it uses, and you need to call the routine many times to complete one temperature read. That is because of the big pause (about 1 second) involved in reading the temperature and I didn't want to hog the processor.

Before anyone comments, I now know how to do lookup tables.
 

Attachments

Hakachukai

New Member
Thanks Diver! I'll give it a shot.

Right now I'm only interesed in reading a single 18b20, so it should work just fine :)
 
This might help.

It is code I wrote some time ago to read a single DS18B20 using a pic16f628

You need to define the registers that it uses, and you need to call the routine many times to complete one temperature read. That is because of the big pause (about 1 second) involved in reading the temperature and I didn't want to hog the processor.

Before anyone comments, I now know how to do lookup tables.
If you scale down the resolution you can decrease the temperature reading time (from 750ms down to ~100ms).
 

Hakachukai

New Member
Yeah, I plan on doing that, because I really only need accuracy to 1/10th of a deg F.

I don't need super accuracy, but a little speed would be nice :)

I'm also working on figureing out how to adapt the code that diver gave me to just run straight through 1 time, every time.
 

Diver300

Well-Known Member
Most Helpful Member
Yeah, I plan on doing that, because I really only need accuracy to 1/10th of a deg F.

I don't need super accuracy, but a little speed would be nice :)

I'm also working on figureing out how to adapt the code that diver gave me to just run straight through 1 time, every time.
An accuracy of 1/10th deg F is better than a DS18b20 can manage. You need a maximum resolution to get a resolution of 1/10th deg F.

If you run my code repeatedly every 5ms until temp_count1 reaches 10, it should do what you want.
 

Hakachukai

New Member
Ok, I am happy to say that I have some code up and running. Currently I am successfully detecting and measuring the presence pulse.

Do I have to actually measure the pulse width and test it to make sure that it is within 60 to 240usec... or can I simply wait for the data line to flip its state and move on to the next step?

Thanks for all the help so far :)
 

blueroomelectronics

Well-Known Member
Run it through the MPLAB simulator and watch the I/O pin. Or if you have a PICkit2 or compatible programmer you can use the logic tool to see the 1wire data stream.
 

Hakachukai

New Member
How do I do either one those? They both sound sepremly useful!

So, you're saying that I can somehow use MPLAB as a logic analyzer?

Currently what I'm using is a bottom shelf JDM serial programmer. It has an ISCP header on it, but I really don't know how to use it yet.

Right now what I do is, I use ZIF sockets both in my JDM progger and on my breadboard. When I need to program the chip, I just remove it from the breadboard and stick it back in the programmer every time.

anyway... if I could come up with some simple/cheap way to make a logic analyzer.... or atleast a recorded O-scope reading... that would be the most useful thing ever! That would let me observe/trouble shoot time critical Tx/Rx transactions. :D
 

Pommie

Well-Known Member
Most Helpful Member
Hakuchukai,

If they're any use, here are my OW routines that run on a 8MHz pic. Note that all the variables are in bank1.
Code:
#define	OwPort	PORTA
#define	OwBit	4
#define	OwData	OwPort,OwBit

OwInit		bcf	OwData		;ensure zero for output
		bsf	STATUS,RP0	;bank1
		bsf	OwData		;set to input
		bcf	STATUS,RP0	;back to bank 0
		return

OwReset		bsf	STATUS,RP0	;bank 1
		bcf	OwData		;pull line low
		movlw	.750/4		;delay 750uS
		call	Wait8W
		bsf	OwData		;release line
		movlw	.68/4		;delay 68uS
		call	Wait8W
		bcf	STATUS,RP0	;bank 0
		bcf	b_OwPresent
		btfss	OwData		;pulled low?
		bsf	b_OwPresent	;yes so chip present
		movlw	.480/4		;delay 480uS
;fall through to wait routine

Wait8W		
; will delay W*8 cycles including the call/return
		addlw	0xff;		add -1 to W			1
		btfsc	STATUS,Z;	=zero?				1/2
		goto	DoneWait;	yes, better get out of here	2
		nop;			delay a bit			1
		goto	$+1;		delay a bit more		2
		goto	Wait8W;		go around again			2
DoneWait	return	;						2

OwWriteByte	bsf	STATUS,RP0	;bank 1
		movwf	OwByte		;store byte to write
		movlw	.8		;send 8 bits
		movwf	OwCount
OwWriteLoop	btfss	OwByte,0	;is bit 0
		call	OwSend0		;yes so send zero
		btfsc	OwByte,0	;is bit 1
		call	OwSend1		;yes, so send 1
		rrf	OwByte,f	;move next bit to bit 0
		decfsz	OwCount,F	;sent all bits
		goto	OwWriteLoop	;no, so loop
		bcf	STATUS,RP0	;bank 0
		return

OwReadByte	bsf	STATUS,RP0	;bank 1
		movlw	.8		;get 8 bits
		movwf	OwCount
OwReadByteLoop	call	OwReadBit	;returns bit in carry
		rrf	OwByte,F	;move carry into byte
		decfsz	OwCount,F	;finished?
		goto	OwReadByteLoop	;no, so carry on
		movfw	OwByte		;return byte in W
		bcf	STATUS,RP0	;bank 0
		return

OwBusy		bsf	STATUS,RP0	;bank 1
		call	OwReadBit	;get bit
		btfss	STATUS,C	;is it a zero
		goto	OwBusy		;yes, so wait
		bcf	STATUS,RP0	;bank 0
		return

OwSendCarry	btfss	STATUS,C	;is carry clear
		goto	OwSend0		;yes, so goto send zero
OwSend1		bcf	OwData		;pull line low
		movlw	4/4
		call	Wait8W		;wait 4uS
		bsf	OwData		;release for a 1 bit
		movlw	.60/4		;wait 60uS
		goto	Wait8W		;exit via wait sub in bank 1

OwSend0		bcf	OwData		;pull line low
		movlw	.60/4		;wait 60uS
		call	Wait8W
		bsf	OwData		;release
		movlw	4/4
		goto	Wait8W		;exit via wait sub in bank 1

OwReadBit	bcf	OwData		;pull line low
		movlw	.4/4		;wait 4uS
		call	Wait8W
		bsf	OwData		;release line
		movlw	.12/4		;Wait 12uS
		call	Wait8W
		movlw	1<<OwBit	;get the bit mask
		bcf	STATUS,RP0	;bank 0
		andwf	OwPort,W	;test the bit
		bsf	STATUS,RP0	;bank 1
		movwf	OwTemp		;save W
		movlw	.60/4		;Wait 60uS
		call	Wait8W
		movfw	OwTemp		;retrieve W
		addlw	.255		;carry will equal the received bit
		return
Mike.
 

Hakachukai

New Member
Thanks!

I'll definatly read through that and see what I can learn from it. I have no problems with asm language, but I really don't know anything about macro asm... so I have to figure those parts out.
 

Pommie

Well-Known Member
Most Helpful Member
There are no macros in that code. Maybe you mean the #defines.
Code:
#define	OwPort	PORTA
#define	OwBit	4
#define	OwData	OwPort,OwBit
These are just text substitutions to make the code more readable. It just means whenever you see,
Code:
	bcf	OwData
it is actually doing,
Code:
	bcf	PORTA,4
Mike.
 

Diver300

Well-Known Member
Most Helpful Member
Ok, I am happy to say that I have some code up and running. Currently I am successfully detecting and measuring the presence pulse.

Do I have to actually measure the pulse width and test it to make sure that it is within 60 to 240usec... or can I simply wait for the data line to flip its state and move on to the next step?

Thanks for all the help so far :)
You're welcome.

With the presence pulse, you don't have to detect it at all. You can just go ahead as if it were there. The danger is that you would see an absent sensor as 0xff so if you don't check the CRC, then that would appear as -1/16 deg C

If you want to detect the presence pulse, the usual thing to do is to wait about 120 µs after power on or a reset pulse. Then check that the wire is low, confirming the presence pulse. Then either wait for at least another 150 µs or until the wire goes back up before continuing.
 

Hakachukai

New Member
There are no macros in that code. Maybe you mean the #defines.
Code:
#define	OwPort	PORTA
#define	OwBit	4
#define	OwData	OwPort,OwBit
These are just text substitutions to make the code more readable. It just means whenever you see,
Code:
	bcf	OwData
it is actually doing,
Code:
	bcf	PORTA,4
Mike.
Yes, I do understand that much.

the lines that have me confused are the ones like this:

Code:
movlw .480/4
movlw .8
I have no idea what those do. Usually "/" means division... but since an instruction can only except an integer input... what would happen to the decimal portion?

and whats up with the "." ?
 
Last edited:

Pommie

Well-Known Member
Most Helpful Member
Any number that is preceded by a period is a decimal number and the / is divide. The fractional part gets lost. So movlw .480/4 is the same as movlw d'120' or movlw 0x78. It just makes the code more readable as you can easily see it is delaying 480uS.

Mike.
 
Status
Not open for further replies.

EE World Online Articles

Loading
Top