So I found a bit more time to work on things, and as usual I get more confused. I connected up a couple DS18S20 therm devices. The are in small proto board so the temps should be real close. Unfortunately they don't appear to be.
So I do a (240) to scan the bus and I find them both
1-WIRE> (240)
SEARCH (0xF0)
Macro 1WIRE address
1.0x28 0x60 0x54 0x02 0x02 0x00 0x00 0x1F
*DS18B20 Prog Res Dig Therm
2.0x28 0xC8 0x88 0x8F 0x02 0x00 0x00 0xD9
*DS18B20 Prog Res Dig Therm
Device IDs are available by MACRO, see (0).
1-WIRE>
So far so good. Then I tell each to convert the current temp and read back the scratch pad.
This appears to me to be the right sequence
{ 0x55 (1) 0x44 %:1000 { 0x55 (1) 0xbe r:9
or
{ 0x55 (2) 0x44 %:1000 { 0x55 (2) 0xbe r:9
But the temps I get back seem way to far apart, device (2) gives me 0x7 0xff , and device (1) gives me 0x5 0x50 that is a huge difference as I read the spec. Can anyone point out what I am doing wrong, or where I should look?
1-WIRE> { 0x55 (2) 0x44 %:1000 { 0x55 (2) 0xbe r:9
BUS RESET OKWRITE: 0x55
ADDRESS MACRO 2: 0x28 0xC8 0x88 0x8F 0x02 0x00 0x00 0xD9
WRITE: 0x44
DELAY 232ms
BUS RESET OKWRITE: 0x55
ADDRESS MACRO 2: 0x28 0xC8 0x88 0x8F 0x02 0x00 0x00 0xD9
WRITE: 0xBE
READ: 0xFF 0x07 0x4B 0x46 0x7F 0xFF 0x01 0x10 0x2F
1-WIRE> { 0x55 (1) 0x44 %:1000 { 0x55 (1) 0xbe r:9
BUS RESET OKWRITE: 0x55
ADDRESS MACRO 1: 0x28 0x60 0x54 0x02 0x02 0x00 0x00 0x1F
WRITE: 0x44
DELAY 232ms
BUS RESET OKWRITE: 0x55
ADDRESS MACRO 1: 0x28 0x60 0x54 0x02 0x02 0x00 0x00 0x1F
WRITE: 0xBE
READ: 0x50 0x05 0x4B 0x46 0x7F 0xFF 0x0C 0x10 0x1C
1-WIRE>
If you put your finger on (both of) the sensor(s) does the returned value get different?
Just by looking at the value it looks like one of the sensors is broken (0x7ff is exactly 11bits).
Well today both are giving me the same number, but the value seems way off? So I am confused as usual. Today I get
both of them are sometimes returning 0x50, 0x05, but not consistently. One thing I notice is the amount of time I tell it to delay is not that time it reports, and it varies a lot.
So I have been poking some more and learn a couple of things
one if you say %:1000 it does not wait one second like you might assume, but 1000 mod 256 or 232 seconds. This I consider a bug. It should either throw an error or do the 1000. The same goes for &:1000.
Also I am still losing, but cause 550 hex is the max positive value reading which is the power on default, from my re-reading of the spec sheet so I either get the largest 12bit number 7ff or the max positive readings based on how long I wait for the convert to complete. So either reading tells me either the mode is not working with this device, or that I am doing something wrong still.
Any suggestions would be appreciated.
There is a howto for the ds1822 which is very simular. ( http://hackaday.com/2008/12/10/parts-1- ... or-ds1822/ (http://hackaday.com/2008/12/10/parts-1-wire-temperature-sensor-ds1822/) )
Some of the comments suggest to use a 1k5 resistor for the ds18b20 since it needs more power during conversion. The could explain why maximum values are returned (i.e. flag an error?). The buspirate got 2k as pullup for the onewire. Could you try it with an external pullup (1k5)?
Edit: Could you also try it with the 'regular' firmware? I think i just copy and pasted the original but an error is quickly made.
To things one I tried
"{ 55 (1) 0x44 - ^ %:250 %:250 %:250 %:250 {0x55 (1) 0xbe r:9"
to see if waiting a full second would make a difference, but it does not.
The spec says to hold the output hi for the wait interval.
I know the chips are good as my arduino can read them fine with the same resistance. In the same proto board. The 4.7K is directly from the manufactures spec sheet and sample circuits. I have used less and more before successfully.
Just for grins I tried a 1.8K resister, no change. also I tried using the macros (85) (1) %:100 (85) (1) 0xbe r:9 no luck either. still poking at it.
Found a 1.5K, and no change the problem is somewhere else.
Rich
So looking at the sources I see a few things that confuse me. 1) The one wire code appear to be in two files 1wire.c and m_1wire_213.c but I don't understand the separation. I would note that both have a copy of the crc table so you may have some space to reclaim.
2) In parasitic power mode, after send a command like convert, the data line must be set and kept high for a fixed period of time. That code I can not find? I am beginning to suspect this is the problem. The arduino write command on OneWire takes an additional argument to indicate parasitic power mode, leave the output enabled and high. From my quick read of the code, that is not present here, so it can't work. I am I wrong? Some other libs I have seen add a command to raise the pin hign and output it. Which is we I tried the - and - ^ commands, but from reading the code I see they are disabled.
Has this ever worked with parasitic devices like the 18X20? Or is this a new problem?
parasitic supply does work: how would the chip otherwise send his id? If this was the problem you get for id all 0s or 1s. the data returned is also 'random' (not all 0xff or 0x00).
As asked before could you try it with the regular firmware? I still suspect you need to clear or init something, perhaps the arduino does that automatically for you?
Parasitic power works for simple commands, but high current operators are what is not working, and they are the ones that need the data line held high for and extended period. Convert, and write on the Looking through the code I don't see that happening, but I could be missing something. I will try to get a logic analyzer out in the next few days and prove it one way or the other. I will find the regular firm ware and give it a try if a get a break at work today. With the arduino lib, the write call takes an additional arg to say whether the data line should revert to tri state, or be held high. I don't find that in the bus pirate code. (The methods that could do that are there, but they don't seem to be called in the write byte pathway. That is why I am beginning to believe this is the problem.
Okay Now I am more confused, but less unhappy? I tried the stock 4.2 firm ware. 2 comments, You can never go back! It was painful, and hard. It also did not work. Then I uploaded the build you made last night with the repeat fix in it, and with two of the 3 resister values I was using, it works with a 1 second delay????? So the 4.7K isn't working but 3 out of 4 times I am getting answer in the 27-28C range which is believable today? I am suspecting there still is a code issue, since it should not be failing this much, but something fixed it?
Also is there any difference between { 0x55 (1) 0x44 and (85) (1) 0x44?
1-WIRE> (85) (1) 0x44 %:1000 (85) (1) 0xbe r:9
BUS RESET OKMATCH ROM (0x55)
ADDRESS MACRO 1: 0x28 0xC8 0x88 0x8F 0x02 0x00 0x00 0xD9
WRITE: 0x44
DELAY 1000ms
BUS RESET OKMATCH ROM (0x55)
ADDRESS MACRO 1: 0x28 0xC8 0x88 0x8F 0x02 0x00 0x00 0xD9
WRITE: 0xBE
READ: 0x93 0x01 0x4B 0x46 0x7F 0xFF 0x0D 0x10 0x32
1-WIRE>
Ian, can you explain how 1-wire mode determines how it will leave the data line? From what I can see from the code I can not see how to tell it to leave it high, versus tristate. The later seems to be what it is trying to do, but will not work with parasitic power if the power is required for a lengthy command like temperature conversion? Any help here would be greatly appreciated.
leaving the line at hiz will connect the device directly through the resistor to vpu.
Are you using 3v3 or 5v as vpu? 5v gives more mA then 3v3.
Of course I was thinking side ways the pullup. Duh. I have tried both, but mostly 5v.
Hey guys - I'm missing notifications on some threads and have started using the 'show unread' link instead, I picked this one up. I didn't actually write the 1-wire code, it's the only part of the code from an outside author, under GPL (used in this public domain project with his explicit permission). I added it to my list and I'll take a look at it.
Goes the problem away when you wait longer? The buspirate does use its internal rc oscillator and is not very accurate.
What troubles did you got with 'downgrading' ? It should be easy and without any errors
@rhyde: does it work now or do you still having issues with 1wire?
Also what kind of trouble did you have with downgrading?
The old syntax, and command parser just drive me crazy
I though you had issues (like trouble flashing the old firmware) with downgrading, but that is not the problem if I understand you.
Do you still have trouble interfacing your 1wire device or not? Does it help when you increase the waittime?
With the right external resister, which is 1/4 what the manufactor says to use I can get it working now.
Yes my issues with downgrading is I got hooked on your fixes. Sump mode work now for me, with the 700ms patch.
i2c is still a mystery to me, but 1-wire can now be used.
I remember you had multiple chips connected to the bus. does it help if you only connect one device to the bus?
Also for future reference which value has that resistor?
lol I don't remember, I will do it again tonight. No if I can get it to work with one, it works with 2 or 3. Which is as it should be.
The resister value I ended up using was a 2.7K resister, but I got several lower values to work as well. Also I uploaded the lastest new term and I am playing around with that.
Here's the answer.
0550H is the power-on default, when you see it, that means the device didn't start converting temperature since it was reset.
I think 07FFH means the device started to convert temperature, but couldn't complete.
Assuming you are using parasitic power, it means your device(s) have insufficient power during the conversion phase. The solution is to either change to active power, or use a P-channel MOSFET to pull the bus voltage up during conversion.
To use a MOSFET, connect its SOURCE to VCC, DRAIN to your bus power/data wire, and GATE to the output pin which will be active LOW during the conversion interval.
One more thing to note - passive power without an active pullup circuit is good for only 1-2 devices on a bus. You want more devices - like the 8 I am testing right now: use a MOSFET.