1-wire object has no way of talking to the configuration registers. Anybody kn
ElectricAye
Posts: 4,561
I've been using the object SpinOneWire.spin from the OBEX obex.parallax.com/objects/342/ and I've recently noticed that it has no method for writing to the Scratchpad memory, therefore the configuration registers can not be changed on a 1-wire device.
Specifically, what I'm trying to do is run a DS18B20 digital thermometer at lower bit resolution (9 or 10 bit) instead of its 12-bit default so I can get it to run at higher speed. I have attached the data sheet below.
Looking at pages 7 and 8 of the data sheet, I see that the "Write Scratchpad" command is 4EH, and to get the newly-set bit resolution to stay in the EEPROM of the DS18B20, a "Copy Scratchpad" (48H) command must be issued. The problem for me is that I don't understand what all the bit-banging procedures are doing in SpinOneWire. And I'm afraid if I try to learn this by trial and error, I'm going to get something stuck in the EEPROM of my DS18B20s and never get it out.
I feel like I'm on the hairy edge of understanding how to do this, but frozen with fear.
Anybody know how to make this work?
thanks,
Mark
Specifically, what I'm trying to do is run a DS18B20 digital thermometer at lower bit resolution (9 or 10 bit) instead of its 12-bit default so I can get it to run at higher speed. I have attached the data sheet below.
Looking at pages 7 and 8 of the data sheet, I see that the "Write Scratchpad" command is 4EH, and to get the newly-set bit resolution to stay in the EEPROM of the DS18B20, a "Copy Scratchpad" (48H) command must be issued. The problem for me is that I don't understand what all the bit-banging procedures are doing in SpinOneWire. And I'm afraid if I try to learn this by trial and error, I'm going to get something stuck in the EEPROM of my DS18B20s and never get it out.
I feel like I'm on the hairy edge of understanding how to do this, but frozen with fear.Anybody know how to make this work?
thanks,
Mark
Comments
Oh yeah? ....Watch THIS! (Cue footage of thousands of people screaming and running for their lives, flames raining down from the moon, whole city blocks crashing to the panic-stricken streets below, the earth yawning open into a demon-filled abyss...)
I knew you were going to say that. Now I have to sit down and learn something again. Uggg...
Best quote [noparse]:)[/noparse]
Post Edited (JonnyMac) : 8/20/2009 7:22:51 PM GMT
Thanks, Mac!
I'll look this over tonight... after I pave over the demon-filled abyss outside my window.
Don't want to jump into the forum to see a post from you titled:
" Sorry folks I've just caused a black hole in the Earth's core. "
(You're at least wearing safety goggles?)
<G>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What I did in the Arduino version of my code (delays removed for the sake of brevity):
present = ds.reset(); ds.select(addr); ds.write(0x4E,1); // CMD: Write to Scratchpad ds.write(0x78,1); // Temp High setpoint ds.write(0x01,1); // Temp Low setpoint ds.write(0x3F,1); // Write 1 byte present = ds.reset(); ds.select(addr); ds.write(0x48,1); // CMD: Copy Scratchpad to EEPROMI've had problems getting the translated version of this code (or the 1-Wire tests) working on my Propeller. I've not had the time to figure out if there is a problem in the library, or what the deal is. Using the same wired-up breadboard with three devices on the 1-Wire bus on both the Arduino and the Propeller- two DS18B20-PAR and a DS1904. *shrug*
Aaron
You have to send those bytes in a very specific order. Also, there are occasions when the device is busy and you need to wait. My DS1822 code (above) works and demonstrates how to correctly set the TH, TL, and configuration bytes, as well as how to wait on the DS1822 when it's busy.
Aaron,
your problem might be in using the PAR (parasitic) version of the DS18B20. For some reason they do NOT work with the SpinOneWire object as far as I can tell. I do not know enough about all this bit banging to understand why. My friend, the D18B20 datasheet, does not specify any difference between the PAR and normal versions of the chip, so I'm confused about why the PARs don't work. Could it be that their configuration registers need changing somehow??? Or maybe the PAR version needs more time for conversions??? I'm clueless as to why it happens.
If the device is being used in parasite power mode, within 10us (max) after this command is issued the master must enable a strong pullup on the 1-Wire bus for at least 10ms as described in the POWERING THE DS1822 section.
This would in fact require a change to the one-wire libraries as the 10us turn-around to put power on the 1-Wire buss could not be accommodated in Spin
That certainly goes a long way toward explaining the problem. However, I have tried to run a DS18B20 PAR version wired like a non-parasitic version and it still does not work. I don't see anything in the data sheet that explains how a PAR chip version might be different from a normal version (I'm not talking about the external wiring, of course), so I just presumed that the PAR tag was a marketing thing and not indicative of any real difference in devices. I'm guessing they might load something into EEPROM that's different between PAR and non-PAR. But that's just a wild guess. In fact, I don't even see the PAR nametag anywhere on the datasheet.
No it can't do 10uS but I've got a SPIN one wire parasitic driver that works in practice. You just need to get that pin high as fast as you possibly can after the command is issued. I wrote it before I got my scope, and I've been meaning to measure it to see how fast it does actually raise the pin, but it does work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Using a stiffer 1-Wire pull-up might be helpful as well.
On any bus longer than about a foot, or having more than one parasite device I use a prop pin to trigger a 2N7000 which in turn switches on a generic PNP transistor for the hard pullup to +5V. This works a treat. I use 3 pins. A data input pin with a 10k resistor. The pull-up circuit and a 2N7000 for pull down. I have no problems at all driving 10 devices on telephone wire with a SPIN driver.
I count poll CRC / timeout errors and I see very, very few over 1,000,000 poll cycles in an electrically noisy marine environment with unshielded cable. I'd probably see less if I used an assembly driver but then I'd lose another cog.
<edit> Now, this prompted me to break out the CRO. While this method works for me (and works well, I might add) it allows the DS1820 to pull the bus down *badly* for 14.75uS, so it is _well_ outside the specification. Incidentally, the 1820 is waiting 17.4uS from the end of the last bit until it really hits the bus for current so the total time from stop bit end until the hard pullup is enabled is actually 32.15uS. Having said that, it works in the field. I'd not build a product based on it though [noparse]:)[/noparse]
Now I'm geared up for it I'm going to have a crack and see if I can build a spin write routine to bring it within spec. I honestly believe it can be done with a little bit of fiddling of the timings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Post Edited (BradC) : 8/21/2009 7:25:02 AM GMT
@:
There are actually two datasheets, one each for the DS18B20 and DS18B20-PAR:
http://datasheets.maxim-ic.com/en/ds/DS18B20.pdf
http://datasheets.maxim-ic.com/en/ds/DS18B20-PAR.pdf
As far as I can tell, the only difference is that one can use an external power supply while the other can't. The -PAR suffix denotes that that part can *only* be used with parasite power, rather than it being a part with parasite power ability added.
I originally was using a 10K pull-up, but I also tried a 4.7K per the datasheet. I was getting a returned value, but it was always the same, never wavering. Which does suggest a timing issue in the library. Is there any reason to believe that the -PAR devices have some more problems because of 3.3V? Are longer charging delays needed? My problem isn't attributable to config registers needing to be changed- like I said, the board is all ready to go. The only things that change are the Vcc, GND, and Data lines moving between different dev boards.
There have been other problems with 1-Wire on the Prop for me, though I've not had the time to discover why. That is, if I have the following on a breadboarded 1-Wire bus I do get them enumerated with on my Arduino, but not my Propeller:
1. DS18B20-PAR
2. DS28EC20
3. DS1904
Now I feel like a total idiot. I wonder why I never noticed that before?
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Watching the world pass me by, one photon at a time.