DS18B20 one-wire temp sensors

Anybody run multiple units of DS18B20, say 10, with only two wires (gnd and data)? What did your code look like?

--
 Thanks, 
    - Win
Reply to
Winfield Hill
Loading thread data ...

Not 10 but just one device, a RTC clock. The 1-wire protocol is very time sensitive, no interrupts just straight bit banging while adhearing to the timeing spec. I'd imaging multiple addressed devices would be similar, with an added address.

Cheers

Reply to
Martin Riddle

You need to send a Search ROM command to find all the devices.

Cheers

Reply to
Martin Riddle

Hey, thanks Martin, no I didn't know about that. 158 pages of good stuff!

--
 Thanks, 
    - Win
Reply to
Winfield Hill

It's not complex. First thing is to identify all the devices on the wire. The one wire bus in open collector so when a query command is sent all the devices start to reply at once (I think with their 64 bit serial number). As each bit is sent each device checks to see whether the bit on the bus m atches itself. If not it stops transmitting. Only one device will see it' s own number by the end of the transmission and has now been identified. It will not reply on subsequent queries until the bus is reset. The query is repeated until no further devices reply. At that point all devices have b een enumerated and you can address each one directly.

If you need code I should have some around I can share, but there are lots of programs to do this available on the web. You just need to do a Google search.

Rick C.

Reply to
gnuarm.deletethisbit

I came very close (in my one-wire implementation) to implementing the enumeration. It is essentially a binary tree search of a sparse 64-level tree. You ask "has anyone here got an ID that starts with a 0? How 'bout a 1?" Then if you get a positive answer to either, you do the same thing again for the next bit, "anyone start with 00, 01, 10, 11?", etc until you've enumerated all devices on the wire.

So with just one device, it takes 128 probes. With two devices, between 128 and 256. For N devices, it's guaranteed to be no more than than N*128.

That might sound slow, but at least it's linear not exponential.

Clifford Heath.

Reply to
Clifford Heath

My house uses multiple 1wire thermostats with 1wire serial numbers to detect button presses; that's five devices per bus and four busses. I put an old C++ version of the search code here:

formatting link

(the latest version is written in assembler - R8C assembler. There's a copy in the firmware posted here (good luck ;):

formatting link

Reply to
DJ Delorie

I had a system system to monitor 12 freezers for my business, I used someone's old wonderful program that they no longer supported. It was called Lampomittari, it had a wonderful display, that I could take a quick glance at with my morning coffee and see all was well. I had it working since 2009, most of it got blown away in the hurricane.

Mikek

--
This email has been checked for viruses by Avast antivirus software. 
https://www.avast.com/antivirus
Reply to
amdx

But, you will not know 'where' the device is located. Unless you train it somehow.

Cheers

Reply to
Martin Riddle

ds.

You must not have read my post where I describe the search algorithm. The master doesn't have to do anything other than issue the command and read th e response. The slaves are pulling down with open collector paralleled out puts on a resistor pullup bus. ALL slaves start to reply with their ID num ber. On each bit anyone responding with a zero will cause a zero to show u p on the bus while all responders will have to output a one in order for th e bus to show a one. Any device that does not see what they are outputting will end its response. By the time the end of the reply message is receiv ed only one responder remains on the bus and it has successfully transmitte d its ID code. Once a slave has successfully transmitted its ID it will no t reply to the identify command again until reset.

This only has to be repeated N+1 times to identify N slaves on the bus.

Rick C.

Reply to
gnuarm.deletethisbit

The Maxim/Dallas devices I've used have part of the serial# etched on the outside. Assuming you wrote that down, then when the controller enumerates them, you'll know which is where.

Clifford Heath.

Reply to
Clifford Heath

Thanks. Glad I didn't need to go ahead and implement it. This was in 2005, so perhaps I mis-remembered, or perhaps I misunderstood it at the time. Good to know, anyhow.

Clifford Heath.

Reply to
Clifford Heath

Ahhh. Your (earlier) message showed up here hours late, after I'd posted mine. Thanks again.

Reply to
Clifford Heath

:

re. The one wire bus in open collector so when a query command is sent all the devices start to reply at once (I think with their 64 bit serial numbe r). As each bit is sent each device checks to see whether the bit on the b us matches itself. If not it stops transmitting. Only one device will see it's own number by the end of the transmission and has now been identified . It will not reply on subsequent queries until the bus is reset. The quer y is repeated until no further devices reply. At that point all devices ha ve been enumerated and you can address each one directly.

ots of programs to do this available on the web. You just need to do a Goo gle search.

Yeah, that's the way usenet is sometimes.

My first job working for myself was to build some DSP boards with an audio and telephony interface. I used the temperature sensor to provide a unique serial number. I was paying someone to write the software and still have that somewhere. He wrote a general purpose interface that was 90% enumerat ion and building the database of devices. The rest was very simple and sho rt.

Rick C.

Reply to
gnuarm.deletethisbit

Yes, but it was a /long/ time ago. My code looked like COP8 assembly - you wouldn't like it!

You need to be sure you have a good supply to these devices - they take a bit of current for the measurement. If you have a traditional one-wire setup with a microcontroller pin in open-drain configuration and a resistor pull-up (5K, IIRC) to VCC, then the line will droop badly if you have multiple devices measuring temperature at once.

The way we handled this at first was to send the message to all the sensors to measure temperature, then immediately drive the microcontroller output high. That provided enough current for good measurements. After waiting long enough, we then switched back to open-drain for reading the values.

For a more advanced network with more sensors, we used brown-out reset devices as boosters (the devices were aimed at microcontrollers with active high reset lines). When these see the line rising towards VCC, they provide a short-term hard pullup, which gives better rise times and more current for big one-wire buses.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.