One Wire Temp Sensor

Pi-Hat with 40 pin connector and 4 jacks
 

Attachments

  • boards3.jpg
    boards3.jpg
    24.2 KB · Views: 491
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.
 

Attachments

  • boards4.jpg
    boards4.jpg
    45.7 KB · Views: 461
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.
 
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).
 
ralphbsz said:
How do I best build the kernel, on my other FreeBSD machine
Click to expand...
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?
Click to expand...
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.
 
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.
Click to expand...
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
Click to expand...
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.
 
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.
 

Attachments

  • boards9.jpg
    boards9.jpg
    45.5 KB · Views: 501
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.
 
Well here are my RPI2 instructions:
Code: 
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.
 
Last edited:
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
 
Last edited:
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.


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.
Click to expand...

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
 
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.
 
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
Code: 
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
Code: 
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
Code: 
dev.ow_temp.2.temperature: 24.125C
dev.ow_temp.1.temperature: 24.125C
dev.ow_temp.0.temperature: 23.250C
 
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 said:
Why did you want to give it another pin?
Click to expand...
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.
 
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
separator can be followed by any number of
space characters.
Click to expand...

I was hoping the same for this setting:
"hint.owc.0.pin_list="
 
Phishfry said:
The manual for gpio(4) seems to indicate that multiple pins are OK

hint.driver.unit.pin_list


I was hoping the same for this setting:
"hint.owc.0.pin_list="
Click to expand...
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.
 
Andriy said:
But what do you want to achieve with multiple pins for one-wire protocol? That was my question.
Click to expand...
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.
 
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.
 
You must log in or register to reply here.
Back
Top