Number 2: "We want... Information"
On Wed, 30 Nov 2016 20:03:21 -0800 (PST), Sebastián Sáez
<otrab86@gmail.com> declaimed the following:
I want to read temp with a ds18b20 sensor. I try with a few tutorial
without luck.
What does "without luck" mean?
Program aborts with segfault?
Program runs but reports unrealistic values?
Program hangs up -- and if it does, on what statement (sample of your
code would be useful, along with some description of how you have the
sensor wired).
Hi Dennis,
I attach my circuit. It’s connected to P9_22 with a pullup 4.7K resistor. Now I’m trying with BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb
I try with this module from this tutorial:
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";`part-number = “BB-W1”;```version = "00A0";
/* state the resources this cape uses */`exclusive-use =```/* the pin header uses */
"P9.22",`/* the hardware IP uses */```"gpio0_2";
fragment@0 {`target = <&am33xx_pinmux>;```__overlay__ {
dallas_w1_pins: pinmux_dallas_w1_pins {`pinctrl-single,pins = < 0x150 0x37 >;```};
};`};`
fragment@1 {`target = <&ocp>;```__overlay__ {
onewire@0 {`compatible = “w1-gpio”;```pinctrl-names = "default";
pinctrl-0 = <&dallas_w1_pins>;`status = “okay”;`
gpios = <&gpio1 2 0>;`};```};
```};};`
I notice that the bone_capemgr from /sys/devices/bone_capemgr.9/slots to /sys/devices/platform/bone_capemgr/slots
I can’t found the w1 kernel module at /sys/bus/w1/devices/DEVICE_ID/w1_slave
regards,
Sebastián
You device tree file is wrong. First lets look at this compared to your
file:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L25-L27
exclusive-use =
/* the pin header uses */
"P9.22",
/* the hardware IP uses */
"gpio0_2";
should be:
exclusive-use =
/* the pin header uses */
"P9.22";
The comment is also wrong, but whatever, it shouldn't hurt anything.
Second:
fragment@1 {
target = <&ocp>;
__overlay__ {
onewire@0 {
compatible = "w1-gpio";
pinctrl-names = "default";
pinctrl-0 = <&dallas_w1_pins>;
status = "okay";
*gpios = <&gpio1 2 0>;*
};
The code in bold is wrong. The gpio bank for this pin is bank0:
*gpios = <&gpio0 2 0>; *would be the correct assignment.
Lastly, your overlay "compatible" assignment is wrong for your board. It
should look like this:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L18
Another problem I’m seeing with your “wiring diagram”. You’re powering the sensor via 3v3, but you still have the parasitic power resistor in place. It is my understanding if you’re wanting to power the DS18B20 from the dataline. In whcih case the resistor would be between Vdd, and DQ pins (pins 2 and 3 ). HOWEVER keep in mind that I’m pretty sure you can not power the DS18B20 from the beaglebone’s GPIO pins.
Anyway, I just happen to have a DS18B20 in hand at this very moment. So I’ll hook up some jumper wires from the P9 headers for ground, 3v3, or 5v, and a data pin to give it a test. I’ll even write, or more correctly modify the existing 1-wire dtb i linked to earlier to match your exact needs.
As it just so happens I have to get 1-wire working myself. As I’m in the process of designing my own 1-wire slave devices.
1-wire workflow:
Hardware setup:
Everything is directly connected via jumper wires, with no additional components.
DS18B20 PIN1 connected to Beaglebone P9.1 (ground)
DS18B20 PIN2 connected to Beaglebone P9.22 (1-wire data)
DS18B20 PIN3 connected to Beaglebone P9.5 (Vdd 5v)
Remove any currently loaded overlays that might be using P9_22, then reboot.
Install git if need be:
william@beaglebone:~/dev$ sudo apt-get install git
git clone the bb.org-overlays repo:
william@beaglebone:~/dev$ git clone https://github.com/beagleboard/bb.org-overlays
Move into the source directory:
william@beaglebone:~/dev$ cd ./bb.org-overlays/src/arm
Find the file we’re looking for:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ ls |grep W1
BB-W1-P9.12-00A0.dts
Make a copy of the file while renaming it in one go:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ cp BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts
Edit copied 1-wire overlay source to suit our needs:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ diff BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts
4c4
< * Virtual cape for onewire on connector pin P9.12
I should probably note that when I connected everything up. I had the beaglebone powered down, and completely disconnected from everything.
That’s it !, Many thanks Williams
It works perfect
sorry Williams but now I have another problem with this.
My temperature sensor work fine but when I load our overlay the Mraa module stop working. I think our overlay replace this overlay “univ-bbgw”
root@beaglebone:/firmware# python test.py
Traceback (most recent call last):
File “test.py”, line 4, in
pir = mraa.Gpio(73)
File “/usr/lib/python2.7/dist-packages/mraa.py”, line 912, in init
this = _mraa.new_Gpio(pin, owner, raw)
ValueError: Invalid GPIO pin specified
test.py
import mraa
import time
pir = mraa.Gpio(73)
pir.dir(mraa.DIR_IN)
while True:
print (pir.read())
time.sleep(1)
regards,
Sebastián
Is that safe? I'd think the 5V would influence the swing of the data
line, and I thought the BBB is supposed to only have 3.3V on the inputs.
You know, it ran over night no problems, the sensor still working fine. I
was however under the impression that I/O on the DQ pin was 3v3. Then my
buddy saw your post and said " You know thats probably not good, I'm pretty
sure there is no I/O regulation on the data pin . . ."
So, I moved the Vdd jumper wire to P9.3 ( 3v3 ).
So yeah just goes to show when it comes to the physical aspects of
electronics . . . I'm about good enough to be dangerous 
In the future
you see me talking about the physical characteristics of electronics . .
.don't take my word on it ! I'm really not an EE.
Wouldn't it be nice if I could edit my exact steps guide to reflect my
mistake here ?
Tried your workflow today without success. Everything is OK up to the lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel expert, so I don’t know how to troubleshoot why the other entries aren’t showing up.
I didn’t see any activity on the oscilloscope either.
Then, you must be using a 3.8.x kernel. Right ? But here are the modules
needed at least on a 4.x kernel:
william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
w1_therm 4886 0
w1_gpio 3764 0
wire 35398 2 w1_gpio,w1_therm
All three of those need to be loaded in order for the DS18B20 to work. So,
try manually loading those via modprobe. SO let's take a look at a rPI
blogpost:
https://www.modmypi.com/blog/ds18b20-one-wire-digital-temperature-sensor-and-the-raspberry-pi
Much of this blog post is going to be RaspberryPI centric. *dtoverlay=w1-gpio,
*/boot/config.txt, etc. However if you scroll down to the *"Programming" *part
of the blog post. This person talks about loading the required kernel
modules( also note that kernel version is 3.6.11 ) Using modprobe. So if
you run those two modprobe commands, and then list the contents of
/sys/bus/w1/devices:
*william@beaglebone:~$* ls /sys/bus/w1/devices/
28-00000647ddf6 w1_bus_master1
And you get output like the above. 1-wire *is* working, and the 1-wire
master ( beaglebone ) has detected a 1-wire slave device. It's working.
However, if you load both the above 1-wire kernel modules, and there is
nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at
this point, if you do not get an error about a missing module, that you
have your pin muxed incorrectly, or not properly connected to the pin.
Now if you get an error on the command line from trying to load either of
those two 1-wire modules. Chances are pretty good you haven't compiled in
the given proper 1-wire support. In fact, I do believe there is a whole
section in menu-config for 1-wire devices. You may actually have to
recompile your kernel with support for the DS18B20 1-wire device . . .
Another issues between 4.x, and 3.8.x kernels is that device enumeration
was different for some devices. So . . . It is entirely possible, in your
overlay, that the GPIO bank you're passing in as parameters is off by one.
How can be test for this ? On 4.x kernels . . .
*william@beaglebone:~$* ls /sys/devices/platform/ocp
40300000.ocmcram 48042000.timer 480ca000.spinlock
49800000.tptc driver_override
40302000.ocmcram_nocache 48044000.timer 4819c000.i2c
49900000.tptc modalias
44e07000.gpio 48046000.timer 481ac000.gpio
49a00000.tptc ocp:l4_wkup@44c00000
44e09000.serial 48048000.timer 481ae000.gpio
4a100000.ethernet of_node
44e0b000.i2c 4804a000.timer 481d8000.mmc
4c000000.emif power
44e35000.wdt 4804c000.gpio 48200000.interrupt-controller
53100000.sham subsystem
44e3e000.rtc 48060000.mmc 48310000.rng
53500000.aes uevent
47400000.usb 480c8000.mailbox 49000000.edma
56000000.sgx
*william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/
gpiochip0
And the very first gpio address entry in this case was the lowest gpio
bank. So, if you investigate the equivalent directory in 3.8.x, you should
be able to check all gpio banks, to see what the actual lowest gpio bank
is. Do also keep in mind that /sys/devices/platform/ocp/ will be different
in 3.8.x. So you'll have to poke around a bit. Unless someone else posts
here and gives you the proper path. I don't remember what it is.
Anyway, there is another option. You can upgrade your kernel to a newer
version. Which, yes, will probably mean you'll also have to either flash a
newer image, or run a newer image from sdcard.
Actually the last bit probably wont work because:
william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/
/sys/devices/platform/ocp/44e07000.gpio/gpio/:
gpiochip0
/sys/devices/platform/ocp/4804c000.gpio/gpio/:
gpiochip32
/sys/devices/platform/ocp/481ac000.gpio/gpio/:
gpiochip64
/sys/devices/platform/ocp/481ae000.gpio/gpio/:
gpiochip96
You wont get an actual gpio bank number. Just the bank offset. So going by this beaglebone blogpost: http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
gpios = <&gpio2 13 0>; /* P8.11*/
I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x, for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio banks start at gpio1, and I know for a fact that gpio banks in 4.x start at gpio0.
Anyway, very good chance your overlay file is slightly wrong. Based on off by one gpio bank.
Nope, actually that persons overlay file is wrong. So yeah I don;t know time to learn Linux and start troubleshooting your problems
Thanks William. I’ll try out your suggestions when I get to the office.