One Wire Temperature sensor (DS1820) to PC interface.

[GrahamG]

Multi-Drop DS18B20

Pommie

I am reading with GR8 interest your project (and Mike KL8H) regarding multi-drop DS18B20 temperature sensors as I have searched the internet for some ASM programs for the PIC but only find plenty of C programs.

I took the Dallas AN187 and AN162 flow diagrams and tried to code in ASM for a PIC18F2620 but all it finds is the familiy code of 0x28 for all of the three sensors I am using. The rest of the data is junk, or at least appears to be.

I am using 3 x DS18B20 to measure "inside", "outside" and "pool" temperatures on a single PIC port pin. The rest are used for other functions. I could have gone the PIC18F4620 route but wanted to keep the project small as 4620's are too big and too many I/O's for my app.

As there are 4-pages of thread on your project but where can I find the full edited and re-edited source code for the 12F609 project that you have completed?

Anticipating you answer as the thread was January 2009 and perhaps no more input from anyone.

Graham
Durban
ZS5MG

 

[Pommie]

I think Mike KL8H posted an up to date version in this post.

If you have problems with it then let me know and I'll dig out my latest version.

Mike.

 

[GrahamG]

DS18B20 multi-drop

Pommie

Many thanks for the prompt reply. Sometime in these forums old posts seem to get forgotten. I will look at the link you have given and revert back if I have a problem.

I am comparing your original 12F509 code to my adaption of the Maxim AN162/187 flow chart to see why my coding wont work

If I need to contact you do I do it through the forum or private email ?

Regards
GrahamG

 

[Pommie]

I prefer that any communication is through the forum.

Mike.

 

[GrahamG]

Multi-Drop DS18B20

Pommie

I see that your routine is for parasitic powered devices, my devices are cabled as 3-wire (Vdd, DQ and Vss) and thus non-parasitic, but you do seem not to have any port pin defined for the the Mosfet power pull-up.

If I modify your code for the :
movlw DataHIGH ;release data line
tris GPIO ;by setting to input
;parasitic power devices

do you think the code will still work ?

 

[Pommie]

If you want to power your devices non parasitically then go ahead. You will have to issue read slots to work out when the conversion has finished. Your suggested modification won't work.

Mike.

 

[rezaify]

Tank you vvv.

 

[GrahamG]

Porting to 18F2620

Pommie

I sucessfully ported your code to suit a 12F629 with parasitic DS18B20's as you suggested. Works like a dream - well done on the code. I tried K8LH's version but wouldn't work the way it was supposed to.

Now I am getting a weird result, keeping your code intact and modyfying for
18F2620 with 3-parasite sensors:

ROMBuffer[8] has had to start at 0x20 so I modified one line of your 12F code accordingly.

FF000000FFFF0000 FFFFFFFFFFFFFFFFFF
FF000000FFFF0000 FFFFFFFFFFFFFFFFFF
00000000FFFF0000 FFFFFFFFFFFFFFFFFF - then it repeats the same three
FF000000FFFF0000 FFFFFFFFFFFFFFFFFF
FF000000FFFF0000 FFFFFFFFFFFFFFFFFF
00000000FFFF0000 FFFFFFFFFFFFFFFFFF

It is almost like I have a timing issue, sensors have been double checked on your 12F version.

I have enclosed your code, modified for 18F, under the name OW_MW_2620.asm that I hope you can peruse for me. A challenge of note but seemingly a simple answer that I cannot find.

 

[Pommie]

Your problem with the 18 series is the line in red,

Continue	movlw	OWReadScratchPad
		call	OWWriteByte
		call	SendSpace
		movlw	0x100-9
		[COLOR="Red"]movwf	FSR0L		;very dodgey - relies on unused bits being 1[/COLOR]
ReadLoop	call	OWReadByte	;but no choice as out of RAM!!
		swapf	OWByte,w
		call	SendNibble	; GG, think this is DATA

This was used due to there only being 16 bytes of ram and is dodgey because it relies on FSR being only 5 bits but on the 18 series it is 8 bits. You can change it to another location as it is just used as a loop counter. You will have to load it with 9 and use decfsz.

I'm pretty sure there are other "optimizations" in the code that will fall over on an 18 series.

I think I have very similar code in C for the 18 series if it's any use.

Mike.

 

[GrahamG]

DS18B20 multi-drop for 18F

Pommie

Thanks for your answer. Point taken. I changed it to:

;MW(1)	movlw	0x100-9
;MW(1)	movwf	FSR0L		;very dodgey - relies on unused bits being 1
		movlw	.9
		movwf	DSCounter
ReadLoop	call		OWReadByte	;but no choice as out of RAM!!
		swapf	OWByte,w
		call		SendNibble	; GG, think this is DATA
		movf		OWByte,w
		call		SendNibble
;MW(1)	incfsz	FSR0L,F		
		decfsz	DSCounter,F
		goto		ReadLoop

but same result. The problem must lie somewhere else. I have tried timing changes, i've changed DS's, checked the DS port pin, checked the TRIS on the debug. Just FF's and 00" all over the place. Hair definately turning grey

I wanted the ASM file as it forms part of a system that is written in ASM. I could compile a C program routine and then copy the compiled asm across but seems crazy as I have got your 12F529 program working.....

 

[Pommie]

I'm busy tomorrow but I may get time to play with this on Thursday. I have a 2620 on a breadboard and so could play around with it. I'll also check as I think I have this code for a 16F88 that would not have the FSR problems.

Mike.

 

[GrahamG]

DS18B20 multi-drop for 18F

Pommie

Thanks. I would appreciate it if you do check on the 2620 as it is super code.

Do you really think it is an FSR problem and not a timing issue changing from 12F to 18F, as having made the FSR change from 0x10 to 0x20 on the 12F509/629 from your original code the rest of the code should work. It seems to work detecting the three DS's I am using, just the data that is cockeyed.

 

[Pommie]

Hi Graham,

Finally got around to looking at the code and found the problem. The problem is this bit of code,

		movwf	OWCount
		bsf	STATUS,C
GetBitLoop
		rlcf	OWTemp,F	; will clear the carry bit
		decf	OWCount,F
		btfss	OWCount,7
		goto	GetBitLoop

On the 10 & 16 series chips decf does not effect the carry flag, on 18 series it does.

The solution is to add,

		movwf	OWCount
		bsf	STATUS,C
GetBitLoop
		rlcf	OWTemp,F	; will clear the carry bit
		decf	OWCount,F
		[COLOR="Red"]bcf	STATUS,C[/COLOR]
		btfss	OWCount,7
		goto	GetBitLoop

I haven't checked all the code but did confirm that I got the 3 correct rom IDs from my DS1820s. Have fun.

Mike.

 

[GrahamG]

DS18B20 multi-drop for 18F

Pommie

Well done and thank you very much. I will try it just now and report back

The fact that DECF does not affect the STATUS:C bit is something that I didn't know about so you have taught me a lesson.

Graham
Durban (cold and wet)

 

[GrahamG]

DS18B20 multi-drop for 18F

Pommie

Well done. The output from the 3 x parasitic sensors running on the PIC18F2620 is:

8E000001C8915D28 2D014B467FFF0310
F0000001C89A2428 3E014B467FFF0210
4A000001C8C57628 47014B467FFF0910
8E000001C8915D28 2E014B467FFF0210 - repeats from here
F0000001C89A2428 3E014B467FFF0210
4A000001C8C57628 46014B467FFF0A10

All I need to do know is save the three sensor data in EEPROM and set them all to 9-bit, if they are not already, and then try the convertions as per normal.

This is a very useful routine and is the first I have seen written in assembler as all the others are in C.

Well done indeed and thankyou for your efforts.

 

[birdman0_o]

Hey Pommie, I will write code for the 16f628A over the next few days. Its a shame there isnt any code for the 18b20 and pic16f family in ASM on the net!

 

[GrahamG]

DS18B20 multi-drop for 18F

Birdman - Rather than re-write the code for the 16F628A why don't you just use Pommie's code as it works for 10F,12F,16F and now for 18F ?

Pommie - not that I am suggesting you do it but it would be nice to be able, now that one has identified what the ROM codes are on the multi-drop bus, to be selective with the codes and allocate them to positions on the bus. An idea here is my inside-outside-pool temperature project where a display on an LCD of specific positions would be an advantage. Almost like an RS485 addressed device basis. Also if one was monitoring various temperatures inside you PC for instance. Nice to know where each sensor was exactly.

An idea would be to get the PIC into a "learn" mode with one sensor connected at a time and save the ROM codes in each learn sequence in EEPROM. A bit of juggling of the MATCH ROM code is necessary once one has "learn't" a ROM code but could be possible.

 

[Pommie]

I have been considering rewriting it to make it more modular. At the moment it is very spaghetti like due to the 12F508 having a stack that can only hold 2 addresses. On the 16 series it could be a series of subroutines that just get called. This would make it much easier for people to customize it to their own needs. I'll try and find time to play in the next couple of days, unless Boo beats me to it.

Mike.

 

[GrahamG]

DS18B20 multi-drop for 18F

Pommie

The ideas you have are somewhat similar to Mike's (K8LH) version where he had defined all the subroutines in the first section and then just called them when required. The disadvantage of his code is that he uses two port pins for the DS one for data, the other for strong pull-up, whereas yours uses just one.

It is neat that your code fits in a 10F/12F etc and show how powerful that device is. Some people say that it is a glorified 555 timer but I have used the 629/675 on many projects and it works so so well. The disadvantage is that you can't run it in debug mode.

Looking forward to your "modified" version as it can then be used as a "plug-in" assembler for all apps using 1-Wire and LCD and .....

 

[sccs]

Hi guys.

im just getting started in pic programing.
my goal is to replicate what you guys have done here in a 16f628 if possible.

my goal is to have a circuit that will read the temps from upto 8 ds18b20's and output them via rs232

i see in the post above GrahamG says pommie's code works on the 16f series.

if anyone can point me in the direction of code that will work with my pic then i would be grateful.


thanks.