# One Wire Temp Sensor



## Phishfry (Dec 12, 2016)

Been looking at tutorials and source for One Wire gpio and I am wondering if anybody else is using this work?
I bought a dozen DS18B20 temp sensors to mess with.

The source notes for  /sys/dev/ow/owll_if.m has to be the most elaborate source documentation ever.

Bravo Warner Losh


----------



## sidetone (Dec 12, 2016)

That's an RTD (Resistance Temperature Detector).

Other types of temperature measuring devices are thermocouples, and thermistors. A thermopile, is just a bunch of thermocouples.


----------



## Phishfry (Dec 18, 2016)

How much wire length can I run to each detector?
Might do multiple sensors and power in one CAT6 run for 3 detectors.


----------



## pwr2srv (Dec 18, 2016)

Decades ago, in college, when the class studied such things as RTD's, Thermocouples, etc., the textbook was an Omega Engineering catalog.  Looking on their web site I found this which might be helpful:

http://www.omega.com/techref/


----------



## chrbr (Dec 18, 2016)

The chip is not just a passive device. Here is the data sheet. http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf. I found some information about maximum speed but nothing about minimum speed. About power supply see the options in figure6 and figure7. At least the parasite power supply gives a limit with respect to slow timing since the chip must be powered from a capacitor or so during data transmission. The application notes on page 17 should give reliable information.


----------



## Phishfry (Dec 18, 2016)

This was helpful for general one wire communications.. FreeBSD's one wire implementation does not support parasitic power for DS18B20.
https://www.maximintegrated.com/en/app-notes/index.mvp/id/148


----------



## chrbr (Dec 18, 2016)

Thank you for seeking the application note. It is an excellent document. By the way, I have not expected that the bus is suitable for more than 100m. This is good to know.


----------



## Phishfry (Dec 27, 2016)

Got this working today on RPi2.

```
root@rpi2:~ # sysctl dev.ow
dev.ow.0.%parent: owc0
dev.ow.0.%pnpinfo:
dev.ow.0.%location:
dev.ow.0.%driver: ow
dev.ow.0.%desc: 1 Wire Bus
dev.ow.%parent:
root@rpi2:~ # sysctl dev.owc
dev.owc.0.%parent: gpiobus0
dev.owc.0.%pnpinfo: name=onewire compat=w1-gpio
dev.owc.0.%location: pin=4
dev.owc.0.%driver: owc
dev.owc.0.%desc: FDT GPIO attached one-wire bus
dev.owc.%parent:
root@rpi2:~ # sysctl dev.ow_temp
dev.ow_temp.0.parasite: 0
dev.ow_temp.0.reading_interval: 1000
dev.ow_temp.0.badread: 0
dev.ow_temp.0.badcrc: 0
dev.ow_temp.0.temperature: 23.500C
dev.ow_temp.0.%parent: ow0
dev.ow_temp.0.%pnpinfo: romid=28:ee:04:0c:1d:16:02:89
dev.ow_temp.0.%location:
dev.ow_temp.0.%driver: ow_temp
dev.ow_temp.0.%desc: Advanced One Wire Temperature
dev.ow_temp.%parent:
```


----------



## Phishfry (Dec 27, 2016)

I really wanted 3 temperature detectors so here is what I ended up with:

```
root@rpi2:~ # sysctl dev.ow
dev.ow.2.%parent: owc2
dev.ow.2.%pnpinfo:
dev.ow.2.%location:
dev.ow.2.%driver: ow
dev.ow.2.%desc: 1 Wire Bus
dev.ow.1.%parent: owc1
dev.ow.1.%pnpinfo:
dev.ow.1.%location:
dev.ow.1.%driver: ow
dev.ow.1.%desc: 1 Wire Bus
dev.ow.0.%parent: owc0
dev.ow.0.%pnpinfo:
dev.ow.0.%location:
dev.ow.0.%driver: ow
dev.ow.0.%desc: 1 Wire Bus
dev.ow.%parent:
root@rpi2:~ # sysctl dev.owc
dev.owc.2.%parent: gpiobus0
dev.owc.2.%pnpinfo: name=onewire2 compat=w1-gpio
dev.owc.2.%location: pin=22
dev.owc.2.%driver: owc
dev.owc.2.%desc: FDT GPIO attached one-wire bus
dev.owc.1.%parent: gpiobus0
dev.owc.1.%pnpinfo: name=onewire1 compat=w1-gpio
dev.owc.1.%location: pin=27
dev.owc.1.%driver: owc
dev.owc.1.%desc: FDT GPIO attached one-wire bus
dev.owc.0.%parent: gpiobus0
dev.owc.0.%pnpinfo: name=onewire0 compat=w1-gpio
dev.owc.0.%location: pin=17
dev.owc.0.%driver: owc
dev.owc.0.%desc: FDT GPIO attached one-wire bus
dev.owc.%parent:
root@rpi2:~ # sysctl dev.ow_temp
dev.ow_temp.2.parasite: 0
dev.ow_temp.2.reading_interval: 1000
dev.ow_temp.2.badread: 0
dev.ow_temp.2.badcrc: 15
dev.ow_temp.2.temperature: 22.875C
dev.ow_temp.2.%parent: ow2
dev.ow_temp.2.%pnpinfo: romid=28:ee:6c:0c:20:16:01:8a
dev.ow_temp.2.%location:
dev.ow_temp.2.%driver: ow_temp
dev.ow_temp.2.%desc: Advanced One Wire Temperature
dev.ow_temp.1.parasite: 0
dev.ow_temp.1.reading_interval: 1000
dev.ow_temp.1.badread: 0
dev.ow_temp.1.badcrc: 23
dev.ow_temp.1.temperature: 22.687C
dev.ow_temp.1.%parent: ow1
dev.ow_temp.1.%pnpinfo: romid=28:ee:a3:1c:20:16:01:ff
dev.ow_temp.1.%location:
dev.ow_temp.1.%driver: ow_temp
dev.ow_temp.1.%desc: Advanced One Wire Temperature
dev.ow_temp.0.parasite: 0
dev.ow_temp.0.reading_interval: 1000
dev.ow_temp.0.badread: 0
dev.ow_temp.0.badcrc: 19
dev.ow_temp.0.temperature: 23.062C
dev.ow_temp.0.%parent: ow0
dev.ow_temp.0.%pnpinfo: romid=28:ee:e0:02:1d:16:02:59
dev.ow_temp.0.%location:
dev.ow_temp.0.%driver: ow_temp
dev.ow_temp.0.%desc: Advanced One Wire Temperature
dev.ow_temp.%parent:
```


----------



## Phishfry (Dec 27, 2016)

Vadims website was what I used to get this running:
https://vzaigrin.wordpress.com/2016/01/12/one-wire-on-raspberry-pi-with-freebsd-11/

To add extra sensors I had to guess, improvise and glance at Linux.
So I just appended on a number to create separate owc buses in the rpi2.dtb:


```
};

   onewire0 {
       compatible = "w1-gpio";
       gpios = <&gpio 17 1>;
 
   };

   onewire1 {
       compatible = "w1-gpio";
       gpios = <&gpio 27 1>;

   };

   onewire2 {
       compatible = "w1-gpio";
       gpios = <&gpio 22 1>;
 
   };
```

So I have 2 sensors powered by the 5V pins and one powered by the 3.3v pin.
I also have the DS3231 RTC working on the same board.


----------



## tingo (Dec 30, 2016)

Nice progress - thanks for sharing!


----------



## Phishfry (Dec 30, 2016)

It is not necessary to actually create separate OWC bus's but I prefered the method. This works too on a single bus:

```
};

   onewire {
       compatible = "w1-gpio";
       gpios = <&gpio 17 1>,<&gpio 27 1>,<&gpio 22 1>;

   };
```
This turns Pins 17,27,22 to onewire compatible and turns the pins ON.

Raspberry Pi header pin 11=17
Raspberry Pi header pin 13=27
Raspberry Pi header pin 15=22

I had to use other pins than the tutorial as I wanted to maintain the DS3231  RTC on Pi header pins 1,3,5,7,9

I am planning on running 3 CAT5 lines with each on its own bus with several sensors on each line.

The 4.7k resistor is a must as well or the bus errors out.
The resistors are also directional. They only work in one direction.


----------



## tingo (Dec 30, 2016)

Phishfry said:


> The resistors are also directional. They only work in one direction.


Excuse me? I understand that you will want to put a resistor the correct way to be able to read the markings in the correct order, but other than that resistors are not directional. In an electrical circuit, they will work no matter which way they are connected.


----------



## aribi (Jan 31, 2017)

Phishfry said:


> How much wire length can I run to each detector?


We use one-wire setups in a 500+ units lab security system and have tested length up to 100m with no problems. Even tried looping it around the spark-plug of a running engine - no problems. Twisted/untwisted is not relevant since one-wire does not use current loop. Plain standard 4wire telephone wire works just as well.


----------



## Phishfry (Feb 1, 2017)

What sensor are you using if you don't mind me asking. I am interested in any OW sensors as they work so well. Mine on Pi have been up over a month now. I am planning on using phone wire already installed for temp sensors myself.
You using ultrasonic sensors for security? How about petite 3-wire like AWG30. Very minimal milliamp usage.


----------



## aribi (Feb 1, 2017)

We use std ds1820 with parasite power for ambient temperatures; but not more then 10 on a single wire.
For the -80degC freezers we use ds2450 with real power on wire-3 connected to thermocouple.
For binary io we use ds2408 - also with dedicated power.
All of our cabling is 4wire untwisted telephone cable with 4p4c modular connectors.


----------



## Phishfry (Feb 3, 2017)

The 4p4c connectors are a good way to go I think. I am now thinking about making a onewire hub//pi-hat using RJ9 Jacks.
It does seem telephone cable is more robust than needed but it is cheap.

I guess there is a standard 4P wiring layout you use? Black-Ground and Red-Power and Green data/signal or Yellow line?


----------



## aribi (Feb 5, 2017)

Off Topic, but might be usefull: DalSemi uses six wires in RJ11 config. Don't know of a standard for RJ9. It's best to keep compatibility if only using 4 wires:

```
RJ11  Signal  RJ9 wire colour
1     VCC     -
2     GND     1    black
3     1Wdata  2    red
4     1Wgnd   3    green
5     NC      4    yellow
6     WAKE    -
```
Thus cable can be used in RJ11 socket using parasite power. We use RJ9-pin4-yellow for VCC; Not connected in RJ11 - so no problem.


----------



## Phishfry (Feb 5, 2017)

I bought 40 thru-hole mount RJ9 jacks so I have some experimenting to do. Also bought 1000ft. AWG28/4 phone cable.
I have been using the DS18b20 circuit cards with resistors onboard like these. Would be nice to use a RJ9 jack on these too.

I see someone makes a Pi board-hat already. Only one connector is my beef.
https://www.abelectronics.co.uk/p/60/1-Wire-Pi-Plus


----------



## ralphbsz (Mar 31, 2017)

From painful experience: parasite power, Cat5 cable, no termination at the end, no pullup resistor, and long runs (80 or 100 feet) will not work.  At least not reliably.  The quality of the "initiator" matters; I have some long runs that work so-so with the commercial HA7Net as a host, but don't work with anything else.  Bit-banging a parallel port is the most marginal; the USB based DS9490 is considerably better.  The Dallas (now Maxim) app notes are really helpful in designing 1-wire runs that work reliably.


----------



## Phishfry (Apr 4, 2017)

My Pi2 has been very reliable. Good uptime and all sensors are reading.  I do get spurious interrupt messages in the log.
My crochet image at p6.


```
FreeBSD 11.0-RELEASE-p6 (RPI2) #0 r308093M: Wed Jan  4 19:31:07 EST 2017

Welcome to FreeBSD!

root@rpi2:~ # uptime
 9:34PM  up 43 days, 14:58, 1 users, load averages: 0.01, 0.03, 0.00
```


----------



## Phishfry (Apr 4, 2017)

Realtime-clock hanging in there too(first time I have checked it since setup):


```
root@rpi2:~ # ntpdate ntp.org
 4 Apr 21:38:12 ntpdate[31062]: step time server 128.4.24.98 offset -14.882408 sec
```
 15 seconds in 3 months is acceptable to me.

This is from the DS3231 RTC module on the GPIO pins.
root@rpi2:~ # dmesg |grep ds3231
ds32310: <Maxim DS3231 RTC> at addr 0xd0 on iicbus1


----------



## Phishfry (Apr 4, 2017)

Been working on my C.


```
root@rpi2:~/1wire # ./get_owtemp
OneWire Temperature Sensor #0= 24C
OneWire Temperature Sensor #1= 24C
OneWire Temperature Sensor #2= 26C
OneWire Temperature Sensor #3= 24C
OneWire Temperature Sensor #4= 24C
OneWire Temperature Sensor #5= -273C
```


----------



## Phishfry (Apr 18, 2017)

Been building a prototype and it has been enjoyable to learn electronics.
I have built 4 boards for the PiHats and several sensor boards. Just starting to etch some parts to test.


----------



## Phishfry (Apr 18, 2017)

Prototype board with DS18B20


----------



## Phishfry (Apr 18, 2017)

Pi-Hat with 40 pin connector and 4 jacks


----------



## Phishfry (Apr 18, 2017)

I tried a sharpie but the board material I bought was 3oz. so that was dumb for my first go. So I tried to reinforce the marker with nail polish.
One on top I might add a GPIO Pin to the board since I am using only 3 wires. Why do some designs have an 'data ground'? These should work OK with 3 wires right? I am aiming for less then 10 sensors per bus/line.
I was thinking of doing a passthrough versions with a RJ9 jack on each end and some power protection.


----------



## Phishfry (Apr 20, 2017)

Mockup of board with resistor and DS18B20


----------



## Phishfry (Apr 20, 2017)

Not bad for my first attempt.


----------



## ralphbsz (Apr 24, 2017)

Well, my Raspberry Pi 3 is basically functioning (see other thread about some minor quibbles), I have a proto board for a hat already (not even unpacked it yet).  I have a few dozen leftover DS1820 and DS1822 variants sitting around, and I just ordered a 1-wire humidity sensor (those are not cheap).  I'll start testing 1-wire communication hopefully late this week; that will be my first exploration of GPIO.


----------



## ralphbsz (Apr 27, 2017)

Proto hat has been soldered up.  Basic GPIO works, tested using the gpioctl command: I can turn a LED off and on, and I can sense a switch connected to a GPIO pin (all wired with sensible current-limiting and pull-up resistors).  Also soldered two Dallas temperature sensors on there, one DS18B20 and one DS1822 (those were the first two I found in my random parts bin), each with their data pin on a separate GPIO pin (again, pull-ups and current limiting resistors).

Now comes the software side.  All documentation I can find for ow(4)(), owc(4)() and ow_temp(4)() says I have to now go into the kernel source, edit the pin assignment into my DTS file, add those four modules to the device list in another file, and rebuild everything.  Unfortunately, I have not built a *BSD kernel in 6 or 8 years, and in particular not for on a Raspberry Pi.

I don't actually know what the correct question to ask at this point is.  A few of them might include:

Can someone point me to a guide for getting and compiling the correct kernel source (which is clearly a bit tricky, given that the Raspberry Pi 3 needs to run 12-current but with packages from 11) ?
How do I best build the kernel, on my other FreeBSD machine (which is "only" a 1 GHz x86), or directly on the Pi?  Cross-compiles are always rumored to be extra difficult.
Are there good general reasons to compile your own kernels?  In the last few years I've come to rely completely on pre-built installs and packages, and only compile home-brew software.
Is there an easier way to configure the three ow... modules without a rebuild?
Is there an easier way to access one-wire devices via the Raspberry's GPIO without having to go through the sysctl/ow layer?  I know about the "owfs" package, and don't like it (but it might be a quick alternative).


----------



## Phishfry (Apr 27, 2017)

ralphbsz said:


> How do I best build the kernel, on my other FreeBSD machine


Crochet is the best. Edit your source files and run crochet script and write image and test.



ralphbsz said:


> Is there an easier way to configure the three ow... modules without a rebuild?


The RPi3 uses a newer method for adding devices. Instead of dts you add devices to dto(device tree overlay) in root directory.
You still need to compile in the ow_temp driver.


----------



## Phishfry (Apr 27, 2017)

ralphbsz said:


> says I have to now go into the kernel source, edit the pin assignment into my DTS file, add those four modules to the device list in another file, and rebuild everything.


Yes this is all you need. Edit the dts (or use the dto method for Pi3) and add your "ow" modules to RPi's kernconf.
The FreeBSD source is the same for all versions(amd64/i386/arm).
Don't let the lack of a FreeBSD12-ARM package repository distract you. Not so long ago there was no official ARM repository.
All versions pull from the same ports tree anyway.



ralphbsz said:


> Are there good general reasons to compile your own kernels


Any accessory you want to work you need to compile in support. Even a Real Time Clock module.
There is no Plug and Play. It's all static with FDT..
https://wiki.freebsd.org/FlattenedDeviceTree

My method is do the dts edits and add modules to kernconf and use crochet to crosscompile.

I have been learning NanoBSD for building embedded Pi2 images. Much harder but more customized.


----------



## Phishfry (Apr 27, 2017)

Doing a Pi Hat mock up on a board that didn't etch so nice .My nail polish was not cured and the etch undermined alot.


----------



## ralphbsz (Apr 27, 2017)

Well, that's one ugly PC board.  But you knew that.  I'm quite happy that I spent a few $ on the Adafruit proto hat.  Really good quality PC board, makes soldering up prototypes like this really fast.  But in the long run, surface-mounted chips will be necessary, and I'll have to have PC boards made (big pain).

EDITed to add: Last night I had another bad thought.  In the long run, I'll have to drive 1-wire devices that absolutely need 5V supply (the DS18xx sensors can function on 3.3V, but humidity sensors can not).  That is guaranteed to cause trouble with the 3.3V GPIO ports on the RPi, and dirty hacks with resistors and zener diodes will probably kill the reliability of the 1-wire protocol.  So I fear a DS2482 or DS2483 1-wire master is in my future anyhow, which means giving up on the built-in ow_temp driver and going over I2C instead.  To some extent, that's good: using a big CPU and a GPIO pin to drive waveforms with tight timing, voltage, and slew rate requirements has always been insane (even if it kinda sorta functions).  But it is extra work to put yet another chip on the PC board (and it will be an SMD chip).

I had only a little bit of time yesterday and today, and spent 5 minutes finding documentation for crochet, not much luck yet.  Thanks for the explanations of why custom kernels are a necessity in the case of the embedded hardware.


----------



## Phishfry (Apr 28, 2017)

Well here are my RPI2 instructions:

```
pkg install git u-boot-rpi2
git clone https://www.github.com/freebsd/crochet /crochet
cd /crochet
./crochet.sh -b RaspberryPi2  /*The first time run takes many hours */
cd /crochet/work
dd if=<your image name> of=/dev/<your device>
```

Crochet tells you the image name at the end of the build.


----------



## RickyTerzis (Jul 28, 2017)

Hi...as per my knowledge about power supply you should see the options in figure6 and figure7 of manual provided. At least the parasite power supply gives a limit with respect to slow timing since the chip must be powered from a capacitor or so during data transmission. The application notes on page 17 should give reliable information.

percentage calculator


----------



## serjsk8 (Jul 7, 2019)

Phishfry said:


> Yes this is all you need. Edit the dts (or use the dto method for Pi3) and add your "ow" modules to RPi's kernconf.
> The FreeBSD source is the same for all versions(amd64/i386/arm).
> Don't let the lack of a FreeBSD12-ARM package repository distract you. Not so long ago there was no official ARM repository.
> All versions pull from the same ports tree anyway.
> ...



Hello,
So it's not enough to load modules "ow" with `kldload`
I have to recompile the entire Kernel and add them to Kernel, right?
I'm on FreeBSD12-RELEASE


----------



## Phishfry (Jul 8, 2019)

No you don't have to recompile to run them. kldload will work and to make that stick add settings to /boot/loader.conf
ow_load="YES"
owc_load="YES"
ow_temp_load="YES"

The problem comes with the device tree. You have to add the appropriate settings there.
You can create your own OneWire 'Device Tree Overlay' also loaded from /boot/loader.conf.
Another way you can add in OW entries to the DeviceTreeBinary by de-compile DTB, modification of the resulting DTS and recompile back in modifications with the Device Tree Compiler.

I could not get OneWire working with RPi3 or on either GPIO supported x86 platform, MBM or APU.
There is no X86 support for OpenFirmware that Arm boards use. I would like to see these modules multi-platform.


----------



## serjsk8 (Jul 8, 2019)

Phishfry said:


> I could not get OneWire working with RPi3 or on either GPIO supported x86 platform, MBM or APU.


OK, Thank you
I found your thread
onewire-on-raspberrypi3


----------



## Phishfry (Nov 14, 2022)

Late follow up but I have OneWire working on Minnowboard Max and Turbot.
On x86 platforms there is no FDT so everything goes into the loader.

/boot/loader.conf

```
bytgpio_load="YES"
hint.owc.0.at=gpiobus0
#hint.owc.0.pin_list="0x003E ; 0x003F"
hint.owc.0.pin_list="62"
ow_load="YES"
owc_load="YES"
ow_temp_load="YES"
```

Notice my commented out line.
I was trying in vain to add a second pin for OneWire support but couldn't get it working. Neither decimal or hex.

`dmesg`

```
owc0: <GPIO one-wire bus> at pin 62 on gpiobus0
ow0: <1 Wire Bus> on owc0
ow_temp0: <Advanced One Wire Temperature> romid 28:ff:4d:83:70:16:05:8a on ow0
ow_temp1: <Advanced One Wire Temperature> romid 28:ff:2d:04:71:16:04:31 on ow0
ow_temp0: Running in parasitic mode unsupported
ow_temp2: <Advanced One Wire Temperature> romid 28:ff:47:56:70:16:05:b7 on ow0
ow_temp1: Running in parasitic mode unsupported
```

`grep ow_temp | grep temperature`

```
dev.ow_temp.2.temperature: 24.125C
dev.ow_temp.1.temperature: 24.125C
dev.ow_temp.0.temperature: 23.250C
```


----------



## serjsk8 (Nov 15, 2022)

Thank you Phishfry for update!

I have only one OneWire sensor on RPi3.
But with FreeBSD 13 these days it's easy to make and connect a sensor.
`dev.ow_temp.0.temperature: 26.625C`


----------



## Andriy (Nov 16, 2022)

Phishfry said:


> I was trying in vain to add a second pin for OneWire support but couldn't get it working. Neither decimal or hex.


One-wire works over, well, one wire, so it uses a single pin. Why did you want to give it another pin?


----------



## ralphbsz (Nov 16, 2022)

Maybe he wants multiple independent 1-wire networks?


----------



## drhowarddrfine (Nov 16, 2022)

Phishfry said:


> Why do some designs have an 'data ground'?


When a circuit has both analog and data, it's sometimes a good idea to keep data ground separate to keep any possible noise out of the other.


----------



## Phishfry (Nov 17, 2022)

Andriy said:


> Why did you want to give it another pin?


I have a project of twelve DS1820 sensors I want to monitor. Any more than 10 devices per pin gives me trouble..
Using FDT it is possible to have multiple OW pins.
Probably going to use BBB for this project but glad to have OneWire working on amd64.


----------



## Phishfry (Nov 17, 2022)

The manual for gpio(4) seems to indicate that multiple pins are OK

_hint.driver.unit.pin___list_


> The numbers can be decimal or    hexa-decimal    with 0x    prefix.
> Any non-digit character can be used as a separator.
> For example,
> it can be a comma, a slash or a    space.    The
> ...



I was hoping the same for this setting:
"hint.owc.0.pin_list="


----------



## Andriy (Nov 17, 2022)

Phishfry said:


> The manual for gpio(4) seems to indicate that multiple pins are OK
> 
> _hint.driver.unit.pin___list_
> 
> ...


Multiple pins are supported in general, e.g. I2C bit banging requires two pins.
But what do you want to achieve with multiple pins for _one_-wire protocol? That was my question.


----------



## Phishfry (Nov 18, 2022)

Andriy said:


> But what do you want to achieve with multiple pins for _one_-wire protocol? That was my question.


I am using ow_temp with one group of sensors inside with another group of ds1820 sensors outdoors.
Due to length of run to outdoor group I want to separate them.

I want to use a 16x2 LCD for displaying temps.


----------



## Andriy (Nov 18, 2022)

Ah, you want to have more than one 1-wire bus? Then you need to configure several owc instances, each with its own I/O pin.


----------



## Phishfry (Nov 19, 2022)

So just declare additional owc buses? I will have to try that.

hint.owc.0.at=gpiobus0
hint.owc.0.pin_list="62"
hint.owc.1.at=gpiobus0
hint.owc.1.pin_list="63"


----------



## Phishfry (Nov 30, 2022)

I have been using this method on Arm boards too.
`uname`

```
FreeBSD Hummingboard 12.4-RC2 FreeBSD 12.4-RC2 r372725 GENERIC  arm
```

The hints method is much easier than compiling an overlay for each pin.
`devinfo`

```
[SNIP]
     simplebus1
        simplebus2
          uart0
        gpio0
          gpiobus0
          gpioc0
        gpio1
          gpiobus1
          gpioc1
        gpio2
          gpiobus2
            owc0
              ow0
                ow_temp0
            owc1
              ow1
                ow_temp1
                ow_temp2
                ow_temp3
          gpioc2
        gpio3
```

/boot/loader.conf

```
ow_load="YES"
owc_load="YES"
ow_temp_load="YES"
hint.owc.0.at=gpiobus2
hint.owc.0.pin_list=9
hint.owc.1.at=gpiobus2
hint.owc.1.pin_list=7
```


----------



## Phishfry (Nov 30, 2022)

Like I mentioned I want to use 2 distinct gpio pins and busses.
One of the reasons is the outside group is on a long wire and that line seems to need less than a 4K7 resistor.

I saw some interesting reading where people put a capacitor at the end of their onewire bus wire on long runs.
It acts as a terminator for the string.
These ds1820 sensors are very versatile. In combination with the dht22 sensors I can really have some deluxe temperature and humidity monitoring.

The drawback of the dht11/22 is each one requires a gpio pin whereas onewire allows daisy-chaining.
The positives are the addition of humidity readings.






						DS18B20 decoupling capacitor - adafruit industries
					






					forums.adafruit.com
				











						Problem with DS18B20 OneWire and long cables
					

I tried to build a temperature sensor with a few DS 18B20 distributed in the house. So I build the needed 4k7 resistor on a breadboard and connected the 3 required cables to a RJ45 patch panel, using pins 1=5V, 2=Data, 6=GND.  This works perfect when the sensors are "near" the arduino. A few...




					forum.arduino.cc


----------



## ice051 (Dec 9, 2022)

My hardware is RPI-4B.
ow, owc and ow_temp were added to the kernel, and the kernel was recompiled and loaded.

uname -a



> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0: Sat Dec  3 20:32:12 UTC 2022     root@generic:/usr/obj/usr/src/arm64.aarch64/sys/MYKERNEL arm64




devinfo



> nexus0
> ofwbus0
> psci0
> simplebus0
> ...



  dmesg | grep "ow_temp"



> module_register: cannot register ow/ow_temp from kernel; already loaded from ow_temp.ko
> Module ow/ow_temp failed to register: 17



What should I do?


----------



## Phishfry (Dec 10, 2022)

There is no need to add the onewire modules to the kernel. They are already built in.
Just load them on bootup in /boot/loader.conf
ow_load="YES"
owc_load="YES"
ow_temp_load="YES"


----------



## Phishfry (Dec 10, 2022)

ice051 said:


> What should I do?


If you build them into the kernel there is no need to load them in /boot/loader.conf
That is the error you are seeing.
You are trying to double load the module:


> cannot register ow/ow_temp from kernel; already loaded


----------



## Phishfry (Dec 10, 2022)

In my opinion the handbook is a little wonky in this regard.
It acts like you must rebuild kernel and include the modules.
Then gives directions on loading the module in /boot/loader.conf
.
The module is available as a loadable driver versus compiling the onewire driver into the kernel.


----------



## ice051 (Dec 10, 2022)

thank you,Phishfry.

When I restore the kernel to the default kernel, comment out the relevant content in /boot/msdoc/config.txt.

Add a few things like #52 and it works.


----------

