Adding a 2nd w1 GPIO

[johnshields]

I have Raspberry Pi2 Model B and have several DS18B20s (1-wire temperature sensors) and when they are connected to GPIO4, the system sees them i.e. I can see them in /sys/bus/w1/devices (I am using a current Linux raspberrypi 4.1.19-v7+ ).

From reading around, I believe that GPIO24 is 'free' and so I modified /boot/config.txt to add:

dtoverlay=w1-gpio-pullup # as there is an external pullup of 4.7K to 3.3v; I also tried w1-gpio but it made no difference
dtparam=gpiopin=24
dtparam=gpiopin=4

and have rebooted but, for some reason, GPIO24 does not behave as GPIO4 does.

Where am I going wrong?

Slainte,

John

[joan]

As far as I am aware the Pi only supports one 1-wire bus.

[PhilE]

1) The README info for the w1-gpio-pullup overlay says:

Code: Select all

[email protected]:~$ dtoverlay -h w1-gpio-pullup
Name:   w1-gpio-pullup

Info:   Configures the w1-gpio Onewire interface module.
        Use this overlay if you *do* need a GPIO to drive an external pullup.

...

This means that you are dedicating a GPIO (5 by default) to be permanently high so you can use it to drive a pull-up resistor. Since you are using a 3.3v source you don't need this, so use the w1-gpio overlay instead.

2) These three sequences are equivalent:

Code: Select all

dtoverlay=w1-gpio
dtparam=gpiopin=24
dtparam=gpiopin=4

dtoverlay=w1-gpio,gpiopin=24,gpiopin=4

dtoverlay=w1-gpio,gpiopin=4

The effect of the parameters is to patch the overlay before it is applied. If you use the same parameter multiple times only the last value will persist.

3) Joan is at least partially correct - it isn't easy to get the Pi to support multiple w1-gpio busses, and even if you can it may not work very well since the pins are bit-bashed by the CPU (the BCM283x family doesn't have hardware Onewire support); at those data rates it might not be a problem, but it might.

If you did want to try, make a copy of the existing w1-gpio-overlay.dts, call it something like w1-gpio-2-overlay.dts, and change the line that says "w1: [email protected] {" to read "w1: [email protected] {". You could also change the default pin assignment ("brcm,pins = <4>;"). Then type:

Code: Select all

dtc [email protected] -I dts -O dtb -o w1-gpio-2.dtbo w1-gpio-2-overlay.dts
sudo cp w1-gpio-2.dtbo /boot/overlays

Now change your config.txt to say:

Code: Select all

dtoverlay=w1-gpio,gpiopin=4
dtoverlay=w1-gpio-2,gpiopin=24

All being well you should get a second w1 bus after a reboot.

Note that you could try loading the overlay at runtime instead. After compiling it as above, try this:

Code: Select all

sudo dtoverlay w1-gpio-2 gpiopin=24

[johnshields]

Thanks for the explanation of pull-up and GPIO5.

Will try as you suggest and thanks for that.

Kind Regards,

John

[johnshields]

the mechamism/method outlined by PhilE works.

Slainte,

John

[pstolarz]

@johnshields if you are still interested in setting w1 on multiple buses check out my w1-gpio alternative:
https://github.com/pstolarz/w1-gpio-cl

No DT patching, kernel ver dependencies or other nuisance. Simply insmod and wroks. Full parasire power support w/o any touch of DT.

Enjoy

[ruminantalpha]

Hi

Does anyone know where the .dts files live in Linux?

I have looked all over and even left my pi searching overnight for *.dts.

Thanks
James

[PhilE]

The .dts files live in the kernel source tree under arch/arm/boot/dts (.../overlays for the overlays).

I've just updated the w1-gpio overlay source to set the "reg" property to the gpiopin value. When the next firmware release goes out - any day now - it will detect updates to "reg" and change the node name to match, which will allow several w1-gpio overlays to be loaded at once all using w1-gpio.

[PhilE]

This feature is now in the rpi-update firmware - give it a try:

Code: Select all

dtoverlay=w1-gpio,gpiopin=4
dtoverlay=w1-gpio,gpiopin=5

[dikva]

I have probably too much ds18b20 hanging on a too long (40m) UTP, some of them started to behave unstable after adding 2 to the final amount of 9. I will play around to change the wiring (now its a daisy chain), but I think the solution will be to separate them on different GPIO's - now I am using only GPIO 4.
Founding this thread and your solution, I updated my RPI3 to the latest firmware and tried with:

dtoverlay=w1-gpio
dtparam=gpiopin=4
dtparam=gpiopin=17

but it didn't work. What am I doing wrong?

[texy]

I have probably too much ds18b20 hanging on a too long (40m) UTP, some of them started to behave unstable after adding 2 to the final amount of 9. I will play around to change the wiring (now its a daisy chain), but I think the solution will be to separate them on different GPIO's - now I am using only GPIO 4.
Founding this thread and your solution, I updated my RPI3 to the latest firmware and tried with:

dtoverlay=w1-gpio
dtparam=gpiopin=4
dtparam=gpiopin=17

but it didn't work. What am I doing wrong?

Hi and welcome to the forum.
You didn't use Phil's advice correctly. Try this :

Code: Select all

dtparam=w1-gpio,gpiopin=4
dtparam=w1-gpio,gpiopin=17

Texy

[PhilE]

That's understandable, since my example was wrong - ahem. I've corrected it now:

Code: Select all

dtoverlay=w1-gpio,gpiopin=4
dtoverlay=w1-gpio,gpiopin=5

The "dtoverlay" command loads an overlay and puts its parameters in scope. When a parameter is used, either on the same line separated by commas, or on later lines with the "dtparam" command, the current overlay's parameters are checked first, followed by parameters exposed by the base DTB. Loading a new overlay (or reaching the end of the config file) ends the scope of the previous overlay - it is at that point that the overlay is applied.

This means that my example could have been written like this:

Code: Select all

dtoverlay=w1-gpio
dtparam=gpiopin=4
dtoverlay=w1-gpio
dtparam=gpiopin=5

but not like this:

Code: Select all

# This is wrong - it is equivalent to dtoverlay=w1-gpio,gpiopin=5
dtoverlay=w1-gpio
dtparam=gpiopin=4
dtparam=gpiopin=5

[dikva]

Thanks! but it seems i still miss something. I made an update and upgrade of my Jessie Lite to ver. 4.4.50-v7+ #970, using apt-get dist-upgrade.
I tried with your config.txt changes, but after a reboot the ds's are not recognized any more.

[PhilE]

I said to run rpi-update - that change hasn't made it into a Raspbian package yet.

[dikva]

sorry, I was blind...

Yes, now it works, even with the old wiring on gpio4 all ds's behave stable. Probably also other improvements have been made in the update.

Thanks again for your fast help!

[fishfinger]

@PhilE - thanks for the (work on this) and the explanation, much easier than kernel patching.

I now have a /boot/config.txt with the following contents:

Code: Select all

dtoverlay=w1-gpio
dtparam=gpiopin=22
dtoverlay=w1-gpio
dtparam=gpiopin=23
dtoverlay=w1-gpio
dtparam=gpiopin=24

A rpi-update and a reboot later:

Code: Select all

[email protected]:/sys/bus/w1/devices $ ls -o
total 0
lrwxrwxrwx 1 root 0 Apr 16 00:10 10-0008028a785f -> ../../../devices/w1_bus_master2/10-0008028a785f
lrwxrwxrwx 1 root 0 Apr 16 00:10 10-0008028a8cf9 -> ../../../devices/w1_bus_master3/10-0008028a8cf9
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000451f186 -> ../../../devices/w1_bus_master1/28-00000451f186
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000452c2c7 -> ../../../devices/w1_bus_master1/28-00000452c2c7
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000452c778 -> ../../../devices/w1_bus_master1/28-00000452c778
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000452d63f -> ../../../devices/w1_bus_master1/28-00000452d63f
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000452ee23 -> ../../../devices/w1_bus_master3/28-00000452ee23
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000452efef -> ../../../devices/w1_bus_master1/28-00000452efef
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-0000045310b4 -> ../../../devices/w1_bus_master1/28-0000045310b4
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000484d5bb -> ../../../devices/w1_bus_master1/28-00000484d5bb
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000484f06f -> ../../../devices/w1_bus_master1/28-00000484f06f
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000484f396 -> ../../../devices/w1_bus_master3/28-00000484f396
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-000004851799 -> ../../../devices/w1_bus_master1/28-000004851799
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-000004853efd -> ../../../devices/w1_bus_master2/28-000004853efd
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-000004854766 -> ../../../devices/w1_bus_master2/28-000004854766
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-000004854853 -> ../../../devices/w1_bus_master2/28-000004854853
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000485637a -> ../../../devices/w1_bus_master2/28-00000485637a
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000485d487 -> ../../../devices/w1_bus_master1/28-00000485d487
lrwxrwxrwx 1 root 0 Apr 16 00:10 28-00000485d5cb -> ../../../devices/w1_bus_master3/28-00000485d5cb
lrwxrwxrwx 1 root 0 Apr 16 00:10 w1_bus_master1 -> ../../../devices/w1_bus_master1
lrwxrwxrwx 1 root 0 Apr 16 00:10 w1_bus_master2 -> ../../../devices/w1_bus_master2
lrwxrwxrwx 1 root 0 Apr 16 00:10 w1_bus_master3 -> ../../../devices/w1_bus_master3

Mild surprise at the order of w1 bus master assignment being the reverse of the config.txt order
ie. w1_bus_master1 == (gpiopin=24) and w1_bus_master3 == (gpiopin=22) other than that it.

It works like a charm!

[PhilE]

Thanks for the feedback. Just so you know, you could shorten that down to:

Code: Select all

dtoverlay=w1-gpio,gpiopin=22
dtoverlay=w1-gpio,gpiopin=23
dtoverlay=w1-gpio,gpiopin=24

The order reversal is surprising - I don't know what would cause that. The device tree is processed in order, and that usually results in device objects being created in the same order, but there are no guarantees about that.

[dmilton]

This works well!
But two questions regarding the order of the bus master assignment:

1. As a previous post noted, the order of the w1 bus master assignment appears to be the reverse of the config.txt order. Is that ordering reliable? Or is it random?

2. With a given bus master, e.g., w1_bus_master2, is it possible to determine (via software, by looking at some system file) which GPIO pin it is 'attached' to?

Thanks!!

[PhilE]

I think the reordering is caused by parallelism in the device instantiation mechanism, which is good because it reduces loading times.

I'm not aware of any way of linking the w1_bus_master devices with the GPIOs they are using. However, if it is an issue for you then you may be able to use a workaround.
1. Remove the dtoverlay=w1-gpio lines from config.txt.
2. Create a file containing this shell script:

Code: Select all

#!/bin/sh
dtoverlay w1-gpio gpiopin=22
dtoverlay w1-gpio gpiopin=23
dtoverlay w1-gpio gpiopin=24

3. Make the script executable - "chmod a+x /path/to/script" (substituting the path and name of your script).
4. Call this from one of the startup scripts, e.g. /etc/rc.local:

Code: Select all

...

+/path/to/script
+
exit 0

(N.B. The '+' symbols show inserted lines, and shouldn't appear in the resulting file).

These commands are run in the order listed and create the w1_bus_master devices in that same order.

[dmilton]

Thanks, much appreciated, that should work! It does seem strange, though, that there isn't some configuration file someplace that identifies what is attached to which GPIO pin.

[PhilE]

It does seem strange, though, that there isn't some configuration file someplace that identifies what is attached to which GPIO pin.

There is, but it doesn't contain the information we want:

Code: Select all

$ sudo sh -c "cat /sys/kernel/debug/pinctrl/*.gpio/pinmux-pins"
...
pin 21 (gpio21): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 22 (gpio22): 16.onewire pinctrl-bcm2835:22 function gpio_in group gpio22
pin 23 (gpio23): 17.onewire pinctrl-bcm2835:23 function gpio_in group gpio23
pin 24 (gpio24): 18.onewire pinctrl-bcm2835:24 function gpio_in group gpio24
pin 25 (gpio25): (MUX UNCLAIMED) (GPIO UNCLAIMED)
...

The identifier is the name of the device node including the "address" (which in this case is the GPIO pin). This is allocated before the ID mapping, which is strictly on a first-come, first served basis, starting at 1. To cap it all, the function that allocates a w1 bus master doesn't include any form of identifier for the provider of the bus, so you can't go the other way either.

I get the feeling that multiple w1 buses isn't very common, and that you aren't supposed to care which bus the devices appear on.

[dmilton]

Interesting. The reason I'm asking is this:

The facility we're building will have 20 (or so) pieces of similar equipment (called 'frames'), each with several 1-wire temperature sensors placed in the same relative position on each frame. Each frame is attached to its own Rpi, which is responsible for reporting out the temperatures. It would be nice to avoid having to configure each Rpi (and reconfigure on reboot) to know which sensor is in which position. By having each sensor on its own bus wired to its own GPIO pin, we can know that. It would be a bit easier if there were a configuration file someplace that mapped the w1 bus masters to their pins, but your suggestion in your earlier post (using a startup script, rather than config.txt) will solve the problem.

Thanks again!