Thanks William. I'll try out your suggestions when I get to the office. On Monday, December 5, 2016 at 8:51:37 PM UTC-7, William Hermans wrote: > > Nope, actually that persons overlay file is wrong. So yeah I don;t know > time to learn Linux and start troubleshooting your problems ;) > > On Mon, Dec 5, 2016 at 8:47 PM, William Hermans <[email protected] > <javascript:>> wrote: > >> 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. >> >> On Mon, Dec 5, 2016 at 8:28 PM, William Hermans <[email protected] >> <javascript:>> wrote: >> >>> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead <[email protected] >>> <javascript:>> wrote: >>> >>>> 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. >>> >> >> >
-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a7326276-9b37-49e0-8382-d16fcf1ed0c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
