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.
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 ?
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
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.
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.
Your problem with the 18 series is the line in red,
Code:
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.
Thanks for your answer. Point taken. I changed it to:
Code:
;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.....
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.
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.
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.
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!
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.
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.
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 .....