The problem is, there are still a few things that do not work properly in kernel 4.x yet. Or at least the last I heard. It’s always worked fine for me, but I’m a hobbyist experimenter . . .
Thanks for the tip.
I tried correcting that line first to:
gpios = <&gpio1 13 0>;
and then to
Probably not. At minimum, not without modifications. The problem I have here is that I have no one wire devices to test all this stuff I’m suggesting to you. Otherwise I’d have a fix for you already.
Hi Matt!
A year ago I started with those sensors and I didn’t have trouble to connect them by the w1 kernel driver. But I don’t remember what I did that time, because I dropped that solution. The kernel driver doesn’t support broadcast messages and the sensors are triggered one after the other. I use eight sensors to control a solar system and there’s more than five seconds between the first and the last measurement. Too much for my appliction.
That’s why I made my own W1-PRU driver using a GPIO pin (no additional hardware). Now all sensors get triggered by a broadcast message, the measurements are at the same time and values are available in less than a second, which increases the speed of my controller loop. For development I implemented a feature that logs the state of the data line at 1 MHz. Those data may help you to understand what’s going on on the bus.
Unfortunately I didn’t find time to document and publish the project jet. The driver is based on libpruio (for pinmuxing). If you’re interested let me know where to send that (undocumented) code (FreeBASIC & PRU-ASM).
BR
Hi TJF,
Now that is really interesting. I was just thinking about using the PRU’s for the job.
In the end I gave up and connected an mbed microcontroller and did the job.
However, that revealed an issue that could be the clue as to why I could not get the 1 wire to work with the BBB.
I interfaced the mbed to the BBB via uart 1. At first I wired it up fairly directly. I got nothing – even though I could
get the BBB usarts to talk to each other.
An oscilloscope revevealed that while the mbed’s tx was connected to the bbb’s rx, the voltage never
went low enough to register the signal (pullup resister too strong?). So I put an optocoupler in line – and it works
perfectly.
Now, in my ignorance, I’m wondering if I should try an optocoupler between the ds18b20 and the BBB.
What do you think? Maybe I don’t need the mbed after all.
Kind regards
Matt
Hi Matthew!
I’ve not really had a lot of trouble getting my One Wire temperature sensor to function. But there have been lots of stumbles and I’m still confused in a lot of places. Let’s start with what I’m running on a BBB RevB with the OS on a 16GB MicroSD card.
uname -a for all shows:
Linux beaglebone 4.1.4-ti-r8 #1 SMP PREEMPT Thu Aug 6 21:01:16 UTC 2015 armv7l GNU/Linux
I’ve configured w1.dts and used dtc to create the w1-00A0.dto which is in /lib/firmware
Now here is where it starts to get complicated mostly because of the OS changes I believe.
First of all I’ve got my DS1822 (1 wire with +/-2C resolution with 22- code) wired through a connector onto the SparkFun prototype cape. The EEROM on the cape is not yet programmed with anything so it’s not in the list. A
cat $SLOTS
shows:
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
5: P-O-L- 0 Override Board Name,00A0,Override Manuf,w1
Notice that neither the HDMI nor the eMMC show up like they do on all the various examples on the web. I’m using the MicroSD card since the BBB has only 2GB. I’m operating headless with Ethernet and puTTY s there’s nothing on the USB nor HDMI connector. Perhaps because nothing’s using them?
This is an example from https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/21
$ cat /sys/devices/bone_capemgr.*/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
And to get the One wire W1 virtual cape installed I’ve copied
sudo sh -c “echo w1 > /sys/devices/platform/bone_capemgr/slots”
Again, this is where it’s interesting. After a restart this Debian Jesse image installs the
https://github.com/cdsteinkuehler/beaglebone-universal-io
cat $SLOTS
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,cape-universaln
To load the virtual One Wire I first have to remove the cape-universaln because it’s already claimed the P8-11 pin I’m using for the DS1822. That’s pretty easy once we know the virtual cape #
sudo sh -c “echo ‘-4’ > /sys/devices/platform/bone_capemgr/slots”
One other thing that’s different from the various forum examples is the location of the slots file.
cat /sys/devices/bone_capemgr.*/slots
The newer Debian image now adds ‘platform’ after devices and has trashed the .x after bone_capemgr. No more .7 or .9
And thenthe web documentation appears to get rather sparse.
- I can’t find where from the cape-universal.dtbo is loaded and which script puts it into the slots file.
- There are several different copies of the cape-universaln.dts so which one is the correct one?
- Is there a way to disable the pin used by the W1.dts so the SparkFun EEROM can be programmed with the information in the w1.dts file? Without recompiling the cape-univesal.dts file with the reference to the W1 pin removed?
Here’s where my system has the various .dts files. Which one is loaded? beaglebone- or bb.org-overlays?
sudo find -name cape-universal*
./sys/firmware/devicetree/base/ocp/cape-universal
./opt/source/beaglebone-universal-io/cape-universal-00A0.dts
./opt/source/beaglebone-universal-io/cape-universala-00A0.dts
./opt/source/beaglebone-universal-io/cape-universaln-00A0.dts
./opt/source/bb.org-overlays/src/arm/cape-universal-00A0.dts
./opt/source/bb.org-overlays/src/arm/cape-universaln-00A0.dts
./lib/firmware/cape-universal-00A0.dtbo
./lib/firmware/cape-universaln-00A0.dtbo
Thanks
John