Raspberry Pi 1-Wire tests, DS2482-800

Bit bangling

When I bought my brand new Raspberry Pi in 2012 (model B, version 2.0 with 512MB of RAM), then I needed a stable 1-wire bus for my home automation. Firstly I was testing it with w1-gpio kernel module which is emulating a 1-wire bus master using a bit-bangling (software) method:


As a result I had a plenty of errors when communicating with slave devices. Then I connected it with additional 101 meters of cable at the beginning of the bus:


The result was even worse: with 8 slaves I had about 1/3 communication errors, while with 22 sensors all of them was returning 0xFF as a read values.
I also have to note that the CPU usage using this bit-bangling method was high.

Using dedicated 8 channel 1-Wire master (DS2482-800)

The previous results shown that bit bangling method is not bad but only for several slaves and short connections.
The Raspberry Pi has a hardware i2c bus – and this was what I was looking for, so my next step was testing dedicated i2c <-> 1-Wire bus master chip. I ordered the DS2482-800 and created a PCB with 8 buses:

Connecting to the Raspberry Pi was as easy as connecting those four pins:

DS2482-800 Raspberry Pi GPIO header
VCC Pin 1 (3.3V)
SDA Pin 3 (SDA)
SCL Pin 5 (SCL)
GND Pin 9 (GND)

Before I connected it to the RPi, I unloaded the w1-gpio and typed:

modprobe i2c-bcm2708

as a result kernel dmesg shows this:

[ 27.431490] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79)
[ 27.556912] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79)
[ 44.040315] i2c /dev entries driver

To be sure I detected devices on i2c:

root@raspberrypi:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Correct – no device so far. Then I connected the DS2482-800 and redo the detection:

root@raspberrypi:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Great – a device on 0x18 address. Now I was ready to load the ds2482 module with:

modprobe ds2482

then I had to associate i2c device with this module typing:

echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-1/new_device

and in dmesg I’ve got:

[ 1260.473311] i2c i2c-1: new_device: Instantiated device ds2482 at 0x18

As a result I’ve got 8 bus masters at:
/sys/bus/w1/devices/w1_bus_masterX, where X is the bus number

To be able to use more slave devices I had to modprobe the wire module with max_slave_count parameter, like this:

modprobe wire max_slave_count=30

After I have the bus master working I did a test with two buses connected to the master using short cables:


The result was great – the CPU usage was nearly zero and no communication errors.
It was a time to check this using longer cables: I connected several cables with a total length of 45.2m and 22 slave devices (mixed in the middle and also at the end of the bus):

Results? None of communication errors! All was working really stable even with this bus length 🙂

After all slaves on buses are detected, then it’s also worth (when you have static configuration) to disable scanning for new devices. It was locking communication with my slave devices on regular intervals and searching for new devices. I’ve disabled searching with the following commands:

echo 0 > /sys/bus/w1/devices/w1_bus_master1/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master2/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master3/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master4/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master5/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master6/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master7/w1_master_search
echo 0 > /sys/bus/w1/devices/w1_bus_master8/w1_master_search

Conclusions

Maybe the conclusion was obvious to you – but for the record:
If you are playing with 1-wire and use it for small amount of slave devices and with short length – a w1-gpio module and bit-bangling should be sufficient. If you will be using it with lengthy buses (maybe even more then single one) and more slave devices – better use a dedicated DS2482 i2c bus master for this 🙂

Comments

  1. Hi,
    Thank you very much. I did not know about the searching for new slave devices. I will try it out on my network.

    You have been using the bus-master with 3.3v. Is this sufficient even over long distances? I have been using i2c bridges to connect my 3.3v ALIX to 5v DS2482 system. If you have made good experiences, I will switch to 3.3v too.

    Thanks. BR

    1. Hi,
      I currently have in my production system several buses starting from one point (bus master) and going to different places of the whole house.
      So a single bus is roughly up to 20 meters long. On each bus I have several DS2413’s, DS1820’s and sometimes DS2408 or DS2438.
      The bus master (DS2482) is powered only from my Raspberry Pi 3.3V power pin and I am not noticing any problems with it (besides some garbage/crc errors on the 1wire bus when some noisy tools/motors are powered; but this is rare, and I believe it is caused because I wrongly installed the buses – parallel to the power cables).
      As I pointed in the article, the longest bus I’ve tested, was 45m (this was on my development desk, not in real home-environment).

      Just curious: And you? How long bus(es) have connected to the DS2482? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *