How to use the One Wire (1-Wire) object in the Obex
ElectricAye
Posts: 4,561
EDIT: if you read farther down on this thread, you will see that JonnyMac has a good fix for the problem I first stated here.
I'm trying to debug a problem that seems to appear in Micah Dowty's Spin One Wire object when it's used with a number of DS18B20 temperature sensors running on one wire above about 150 degrees F. Instead of using Micah Dowty's Spin One Wire object, which Micah said might have some timing inaccuracies, I would like to try Cam Thompson's version of One Wire to see if the glitches happen with it, too. Problem is, I can't figure out how to interface with Cam Thompson's code. In particular, I can't see how to feed in the ROM addresses that call to a specific DS18B20 temperature sensor. These are 64 bit ROM addresses, and I don't understand how Micah Dowty's system feeds those into the wire - I think he uses some PASM to bang the bits around, and I go blind whenever I encounter either PASM or bit banging, so I'm especially lost when it comes to this.
Micah's code allows me to extract the 64-bit ROM addresses and display them on my VGA no problem, but I just can't figure out how to plug those ROM addresses into Cam's routines. What I need is some code to provide a plug-and-chug, easy-to-follow "entrance ramp" to Cam's 1-wire object. If anyone has some example codes for how they do this, that would probably reduce my impending headache from 1st degree to 2nd. Thanks.
Cam Thompson's object:
http://obex.parallax.com/objects/18/
Micah Dowty's object:
http://obex.parallax.com/objects/342/
Previous historical discussions about the DS18B20 glitch mentioned above:
http://forums.parallax.com/showthread.php?135523-ds18b20-sensor-fails-at-high-temperature
I'm trying to debug a problem that seems to appear in Micah Dowty's Spin One Wire object when it's used with a number of DS18B20 temperature sensors running on one wire above about 150 degrees F. Instead of using Micah Dowty's Spin One Wire object, which Micah said might have some timing inaccuracies, I would like to try Cam Thompson's version of One Wire to see if the glitches happen with it, too. Problem is, I can't figure out how to interface with Cam Thompson's code. In particular, I can't see how to feed in the ROM addresses that call to a specific DS18B20 temperature sensor. These are 64 bit ROM addresses, and I don't understand how Micah Dowty's system feeds those into the wire - I think he uses some PASM to bang the bits around, and I go blind whenever I encounter either PASM or bit banging, so I'm especially lost when it comes to this.
Micah's code allows me to extract the 64-bit ROM addresses and display them on my VGA no problem, but I just can't figure out how to plug those ROM addresses into Cam's routines. What I need is some code to provide a plug-and-chug, easy-to-follow "entrance ramp" to Cam's 1-wire object. If anyone has some example codes for how they do this, that would probably reduce my impending headache from 1st degree to 2nd. Thanks.
Cam Thompson's object:
http://obex.parallax.com/objects/18/
Micah Dowty's object:
http://obex.parallax.com/objects/342/
Previous historical discussions about the DS18B20 glitch mentioned above:
http://forums.parallax.com/showthread.php?135523-ds18b20-sensor-fails-at-high-temperature
Comments
I've also attached my DS1822 code (don't have same device as you) in the hopes that it's helpful. The demo shows how to extract the serial number of a device and then use it to "talk" to that device (see the read_tca method).
FWIW: I lifted Cam's PASM CRC and Micah's Spin CRC code for my 1W object (both provide the same result).
Jon,
Awesome. I'll give this a try and see what happens. Thanks very much!
EDIT: FYI, the data sheet for the DS1822 says it is software compatible with the DS18B20, so I'm sure that will help a lot.
Jon,
with just a few modifications, I got your 1-wire code to operate four DS18B20's on a single line. With all of them operating at the same time, I heated one of them up to 250 F (the sensor's spec limit) and saw no glitches whatsoever. Contrast that to Micah Dowty's Spin One Wire object in the OBEX, which almost certainly starts freaking out by 180 F.
Obviously there's a software problem with Micah Dowty's Spin One Wire object in the OBEX. Is there any way somebody can place a caveat on it? It makes me wonder what other types of glitches might appear with other 1-wire devices using Dowty's code.
Thanks for helping me with this.
Yes, I can do that. I'm in the process of cleaning up the random bits of crazy code I had injected into it and putting some comments into it so I won't forget how it works in a few months. JonnyMac's code is a godsend. I hope he doesn't mind if I post what is essentially his code in a repackaged form. I've also been rewriting it so it works on my VGA display.
Another beautiful thing about JonnyMac's code is that it does a CRC check, which provides lots of confidence in the sensor numbers. Thank you, JonnyMac!
I'm attaching the code I've derived from JonnyMac's code mentioned above. Note that his code works on a terminal whereas mine has been modified to work with a VGA. I hope you will excuse my unconventional use of commenting tags, etc. And I'm sure a lot of forum members will be appalled at the way I write software, but hopefully this will help you get started. I'm sure my parts of the code still have plenty of bugs in them and I think my CRC treatment still says everything looks good even if some sensors become disconnected, so I need to work on that.
From what I've read on the data sheets, the DS18B20 is interchangeable with the DS1822.
To get started, you will want to wire up only one DS18B20 at a time and run DS18B20jmReadROM1a.spin to get each serial number, then you will have to manually type the serial numbers into the software that runs more than one of the sensors at the same time, using DS18B20jm1d.spin.
Please let me know if there are any freakish or fatal errors.
I don't as long as you take my name off any program you modify (you may use "based on code by Jon McPhalen" in comments). Most of the code that I write is for public consumption or clients, so I'm very careful with style, formatting, etc -- so comments like this:
... are what cause me to insist that my name be removed from modified programs. Fair? I get myself into enough trouble, I don't need help!
Okay, so does that mean you want me to modify how I attributed you in the code I posted? I wasn't sure how to do that without offending one way or the other. On one hand I wanted to be sure you got credit but on the other hand I knew I had mangled much of what you had done. I'll be happy to re-write it anyway you want, or totally remove the post if that's best. Last thing I want to do is irk somebody for helping me out. Just let me know.
I am using JonnyMac's code from OBEX and have also attached it.
Thanks for the help!
_README_.txtjm_1-wire.spinjm_ds1820_demo.spinjm_ds1822_demo.spinjm_txserial.spin.
(DS2480B is serial to 1-wire chip, the DS2482-series are I2C-to-1-wire. One of them even has 8 1-wire channels... )
Well that would be fine, JonnyMac already did a wonderful coding everything for the 18B20 and I have one of those as well. Even if I did use the 2482 series, I would still need to write a bunch of code to be able to use it. For the purpose of learning this correctly, I would like to try and modify the code so that I can use the 18B20 with 12-bit resolution.
Elkin,
I've been using JonnyMac's code and I don't think I ever changed the bit resolution on the sensors, and I've never had any problems with it so far. I've had my readings output to a VGA, though, so I'm not sure about the PST routines. Unfortunately, I don't know how to program in assembly, so I'm not even sure how JonnyMac's code works. Somewhere I think I have a bit of code somebody gave me to change the sensor resolution. I can probably find that for you if you actually want to change the sensor resolution to see if that helps. Keep in mind that the higher the resolution on these sensors, the slower it takes for them to take a reading. If I remember correctly, the full 12 bit operation takes about 750 msec per sensor, so if you are using more than one sensor on a wire, the time is going to add up to something over 1 second.
-- http://datasheets.maxim-ic.com/en/ds/DS18B20.pdf
The bits of the configuration register are explained on page 8. What you need to do is use the Read Scratchpad ($BE) and read back the first five bytes; the fifth is the configuration register. Modify bits 6 and 5 per your resolution requirement and then use Write Scratchpad ($4E) to send back the third, fourth, and fifth bytes (you would have captured them in a byte array). Now use the Copy Scratchpad ($4E) command to save the configuration register to the device's EEPROM.
None of this is difficult, it just takes a bit of code.
I wish I could say the same.
Here is what I have done, I have no idea if it is even close.
pub main | status, temp, crc term.init(30, 115_200) waitcnt(clkfreq / 10 + cnt) term.str(string(CLS, "DS1820 Demo", CR)) ow.init(0) ' DS1820 on P0 status := ow.reset ' check for device if (status == %10) ' good 1W reset readsn(@snum) ' read the serial # showsn(@snum) ' show it crc := ow.crc8(@snum, 7) ' calculate CRC if (crc <> snum[7]) ' compare with CRC in SN term.str(string(" ")) term.hex(crc, 2) term.str(string(" - bad CRC")) repeat else setres(@config) ' set correct bit resolution repeat temp := readtc ' read the temperature term.str(string(HOME, LF, LF, LF)) showc(temp) ' display in °C showf(temp) ' display in °F else case status %00 : term.str(string("-- Buss short")) %01 : term.str(string("-- Buss interference")) %11 : term.str(string("-- No device")) repeat PUB setres(pntr)| b 'Modifies bits 6 and 5 of configuration register to change resolution ' -- stores in an aray at pntr ow.reset ow.write(RD_SPAD) repeat 4 byte[pntr++]:=ow.read 'read the first 5 bytes into the config buffer repeat 1 ow.write(b) 'modify bits 6 and 5 ow.write(WR_SPAD) repeat 2 byte[pntr++]:= ow.write(b) 'write bits 3, 4 and 5 back to scratchpad ow.write(COPY_SPAD) 'write scratchpad to EEPROMI don't even know if I am on the right track with this. I do understand what you are saying, but I have no idea how to code that.
Sorry it took so long for me to find this code; it was on another computer of mine.
I think JonnyMac's DS1822 Demo code has a method for changing bit resolution in it. I've attached a stripped down version of it, which I've used in the past, but I don't understand how it does what it does. However, it does seem to work okay, from what I can see. I hope that helps.
Thanks for that code. I was able to change the resolution on the sensor and the values look a whole lot better now. I tried to work it into the 1820 code but then I realized that you need only to program it once and it works fine thereafter. So I didn't bother trying to do that.
If you are interested, the code that you posted there works by reading the scratchpad until it gets to the control registers and then writes the new bits in to set the resolution. if you notice in the code the cfg 9, 10, 11, 12 are only different in the last 3 bits. (or at least how I see it. These are the registers and the temperature alarms. You can see this clearly on the data sheet that JonnyMac posted. I think after seeing the code I understand it a whole lot better!
Cheers
Someone was asking me about a DS18B20 Propeller Object that works. I pointed him to the jm_ds1822_demo object on the "new" Obex here:
http://obex.parallax.com/object/306
I then looked at the jm_ds1822_demo object at the link above only to find it is the V1.0 object from 04 August 2009. Not the updated object in this thread (which with luck I was able to dig-up the URL).
Is it possible to push the 2011 jm_ds1822_demo objects in this thread to Obex as an update?
I'm not sure what the differences are between the 2009 jm_ds1822_demo and the 2011 jm_ds1822_demo are, but I have used the newer version with success with 18B20 sensors.
I know many have reservations about Obex (as I do). But that's where many (if not most) go to look for a solution.