Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-06 Thread acheesehead
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  > 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 = < 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 > > wrote:
>>
>>> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead >> > 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_therm4886  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-0647ddf6  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
>>> 4030.ocmcram  48042000.timer
>>> 480ca000.spinlock  4980.tptc  driver_override
>>> 40302000.ocmcram_nocache  48044000.timer
>>> 4819c000.i2c   4990.tptc  modalias
>>> 44e07000.gpio 48046000.timer
>>> 481ac000.gpio  49a0.tptc  ocp:l4_wkup@44c0
>>> 44e09000.serial   48048000.timer
>>> 481ae000.gpio  4a10.ethernet  of_node
>>> 44e0b000.i2c  4804a000.timer
>>> 481d8000.mmc   4c00.emif  power
>>> 44e35000.wdt  4804c000.gpio 
>>> 4820.interrupt-controller  5310.sham  subsystem
>>> 44e3e000.rtc  4806.mmc  
>>> 4831.rng   5350.aes   uevent
>>> 4740.usb  

Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread William Hermans
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  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 = < 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  wrote:
>
>> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead 
>> 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_therm4886  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-temper
>> ature-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-0647ddf6  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
>> 4030.ocmcram  48042000.timer
>> 480ca000.spinlock  4980.tptc  driver_override
>> 40302000.ocmcram_nocache  48044000.timer
>> 4819c000.i2c   4990.tptc  modalias
>> 44e07000.gpio 48046000.timer
>> 481ac000.gpio  49a0.tptc  ocp:l4_wkup@44c0
>> 44e09000.serial   48048000.timer
>> 481ae000.gpio  4a10.ethernet  of_node
>> 44e0b000.i2c  4804a000.timer
>> 481d8000.mmc   4c00.emif  power
>> 44e35000.wdt  4804c000.gpio
>> 4820.interrupt-controller  5310.sham  subsystem
>> 44e3e000.rtc  4806.mmc
>> 4831.rng   5350.aes   uevent
>> 4740.usb  480c8000.mailbox
>> 4900.edma  5600.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 

Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread William Hermans
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 = < 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  wrote:

> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead  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_therm4886  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-0647ddf6  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
> 4030.ocmcram  48042000.timer480ca000.spinlock
> 4980.tptc  driver_override
> 40302000.ocmcram_nocache  48044000.timer4819c000.i2c
> 4990.tptc  modalias
> 44e07000.gpio 48046000.timer481ac000.gpio
> 49a0.tptc  ocp:l4_wkup@44c0
> 44e09000.serial   48048000.timer481ae000.gpio
> 4a10.ethernet  of_node
> 44e0b000.i2c  4804a000.timer481d8000.mmc
> 4c00.emif  power
> 44e35000.wdt  4804c000.gpio 4820.interrupt-controller
> 5310.sham  subsystem
> 44e3e000.rtc  4806.mmc  4831.rng
> 5350.aes   uevent
> 4740.usb  480c8000.mailbox  4900.edma
> 5600.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 

Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread William Hermans
On Mon, Dec 5, 2016 at 7:30 PM, acheesehead  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_therm4886  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-0647ddf6  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
4030.ocmcram  48042000.timer480ca000.spinlock
4980.tptc  driver_override
40302000.ocmcram_nocache  48044000.timer4819c000.i2c
4990.tptc  modalias
44e07000.gpio 48046000.timer481ac000.gpio
49a0.tptc  ocp:l4_wkup@44c0
44e09000.serial   48048000.timer481ae000.gpio
4a10.ethernet  of_node
44e0b000.i2c  4804a000.timer481d8000.mmc
4c00.emif  power
44e35000.wdt  4804c000.gpio 4820.interrupt-controller
5310.sham  subsystem
44e3e000.rtc  4806.mmc  4831.rng
5350.aes   uevent
4740.usb  480c8000.mailbox  4900.edma
5600.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqTRB%3D%2BsAjP81PvqSyZ2xid8Z58rgzzC_3ZtBAG0CK1Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread acheesehead
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.

On Thursday, December 1, 2016 at 10:28:16 PM UTC-7, William Hermans wrote:
>
> *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
> ---
> >  * Virtual cape for onewire on connector pin P9.22
> 21c21
> <   part-number = "BB-W1-P9.12";
> ---
> >   part-number = "BB-W1-P9.22";
> 27c27
> <   "P9.12";
> ---
> >   "P9.22";
> 35c35
> <   BONE_P9_12 0x37
> ---
> >   BONE_P9_22 0x37
> 51c51
> <   gpios = < 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> Backout to the base path:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..
>
> Build our newly created overlay:
> william@beaglebone:~/dev/bb.org-overlays$ make 
> ./src/arm/BB-W1-P9.22-00A0.dtbo
>
> "Install" our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo cp 
> ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/
>
> Load our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' > 
> /sys/devices/platform/bone_capemgr/slots"
>
> Check if the overlay loaded:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22
>
>  william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
> [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', 
> version 'N/A'
> [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-W1-P9.22'
> [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0
>
> Check to make sure kernel modules loaded or not:
> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
> w1_therm4886  0
> w1_gpio 3764  0
> wire   35398  2 w1_gpio,w1_therm
>
> Check sysfs:
> william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
> 28-0647ddf6  w1_bus_master1
>
> Read from our sensor:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/bus/w1/devices/28-0647ddf6/w1_slave
> 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
> 16 01 4b 46 7f ff 0a 10 98 t=17375
>
> Pat self on back for job well done !
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3529e32e-5edd-4e1f-add2-80832ac19715%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread William Hermans
*OR* P8.26 . . . *smacks hardware designer / buddy . . .

*william@beaglebone:~/dev/bb.org-overlays$* diff
src/arm/BB-W1-P8.26-00A0.dts src/arm/BB-W1-P8.14-00A0.dts
4c4
<  * Virtual cape for onewire on connector pin P8.26
---
>  * Virtual cape for onewire on connector pin P8.14
21c21
<   part-number = "BB-W1-P8.26";
---
>   part-number = "BB-W1-P8.14";
27c27
<   "P8.26";
---
>   "P8.14";
35c35
<   BONE_P8_26 0x37
---
>   BONE_P8_14 0x37
51c51
<   gpios = < 29 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 26 GPIO_ACTIVE_HIGH>;
*william@beaglebone:~$* cd dev/bb.org-overlays/
william@beaglebone:~/dev/bb.org-overlays$ make
./src/arm/BB-W1-P8.26-00A0.dtbo
  DTC src/arm/BB-W1-P8.26-00A0.dtbo
*william@beaglebone:~/dev/bb.org-overlays*$ sudo cp
./src/arm/BB-W1-P8.26-00A0.dtbo /lib/firmware/
*william@beaglebone:~/dev/bb.org-overlays*$ cat
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
*william@beaglebone:~/dev/bb.org-overlays$* sudo sh -c "echo 'BB-W1-P8.26'
> /sys/devices/platform/bone_capemgr/slots"
*william@beaglebone:~/dev/bb.org-overlays$* cat
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P8.26
*william@beaglebone:~/dev/bb.org-overlays$* dmesg |grep W1
[  210.416201] bone_capemgr bone_capemgr: part_number 'BB-W1-P8.26',
version 'N/A'
[  210.416276] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-W1-P8.26'
[  210.430251] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #0
*william@beaglebone:~/dev/bb.org-overlays$* ls /sys/bus/w1/devices/
28-0647ddf6  w1_bus_master1
*william@beaglebone:~/dev/bb.org-overlays$* cat
/sys/bus/w1/devices/28-0647ddf6/w1_slave
19 01 4b 46 7f ff 07 10 eb : crc=eb YES
19 01 4b 46 7f ff 07 10 eb t=17562


Anyway, dead horse . . . point made?

On Mon, Dec 5, 2016 at 6:41 PM, William Hermans  wrote:

> I repeated this process for P8.14, and it works fine. This is just to let
> others who may not be aware that you can use 1-wire on any gpio pin that is
> not already in use by the system. Again, double check the pins in the
> schematic, to make sure they're not being used by somethign like HDMI(
> which you can disable hdmi audio and video if you do not need it. ), or
> i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change
> the overlay to reflect the pin you need to use.
>
> *william@beaglebone:~$* diff 
> ./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts
> ./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts
> 1c1,2
> < /*
> ---
> >
> >  /*
> 4c5
> <  * Virtual cape for onewire on connector pin P8.14
> ---
> >  * Virtual cape for onewire on connector pin P9.12
> 21c22
> <   part-number = "BB-W1-P8.14";
> ---
> >   part-number = "BB-W1-P9.12";
> 27c28
> <   "P8.14";
> ---
> >   "P9.12";
> 35c36
> <   BONE_P8_14 0x37
> ---
> >   BONE_P9_12 0x37
> 51c52
> <   gpios = < 26 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 28 GPIO_ACTIVE_HIGH>;
>
>
>
>
> On Sat, Dec 3, 2016 at 3:11 PM, William Hermans  wrote:
>
>> @ Sebastian
>>
>> Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .
>>
>> *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
>> #cmdline=coherent_pool=1M quiet cape_universal=enable
>> video=HDMI-A-1:1024x768@60e
>> #cape_disable=capemgr.disable_partno=
>> #cape_enable=capemgr.enable_partno=
>> #cape_disable=bone_capemgr.disable_partno=
>>
>> cape_enable=capemgr.enable_partno= is the way to go. You
>> can assign multiple cape overlays with this feature, but I do not remember
>> if they are space, or comma separated. I'm thinking comma separated, but
>> may be wrong.
>>
>> That's the first step.
>>
>> The second step would be to . . .
>>
>> Copy all your required overlays into /lib/firmware, which you've
>> probably already done.
>>
>> *william@beaglebone:~$* cd /opt/scripts/
>> *william@beaglebone:/opt/scripts$* git pull
>> *william@beaglebone:/opt/scripts$* cd tools/developers/
>> *william@beaglebone:/opt/scripts/tools/developers$* sudo
>> ./update_initrd.sh
>>
>> What this does, is notes what's in uEnv.txt in the way of enabled capes,
>> then which overlays you have in /lib/firmware, and "injects" these overlays
>> into the initramfs. This is important, and if not done, your overlays will
>> not load at boot using this method. But the upside is that once done, this
>> will load your overlays at boot faster than any other method. Near
>> instantly at boot, 1-2 seconds tops.
>>
>> Anyway, this method is fairly easy, and is actually the best way 

Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-05 Thread William Hermans
I repeated this process for P8.14, and it works fine. This is just to let
others who may not be aware that you can use 1-wire on any gpio pin that is
not already in use by the system. Again, double check the pins in the
schematic, to make sure they're not being used by somethign like HDMI(
which you can disable hdmi audio and video if you do not need it. ), or
i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change
the overlay to reflect the pin you need to use.

*william@beaglebone:~$* diff
./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts
./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts
1c1,2
< /*
---
>
>  /*
4c5
<  * Virtual cape for onewire on connector pin P8.14
---
>  * Virtual cape for onewire on connector pin P9.12
21c22
<   part-number = "BB-W1-P8.14";
---
>   part-number = "BB-W1-P9.12";
27c28
<   "P8.14";
---
>   "P9.12";
35c36
<   BONE_P8_14 0x37
---
>   BONE_P9_12 0x37
51c52
<   gpios = < 26 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 28 GPIO_ACTIVE_HIGH>;




On Sat, Dec 3, 2016 at 3:11 PM, William Hermans  wrote:

> @ Sebastian
>
> Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .
>
> *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
> #cmdline=coherent_pool=1M quiet cape_universal=enable
> video=HDMI-A-1:1024x768@60e
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
> #cape_disable=bone_capemgr.disable_partno=
>
> cape_enable=capemgr.enable_partno= is the way to go. You
> can assign multiple cape overlays with this feature, but I do not remember
> if they are space, or comma separated. I'm thinking comma separated, but
> may be wrong.
>
> That's the first step.
>
> The second step would be to . . .
>
> Copy all your required overlays into /lib/firmware, which you've probably
> already done.
>
> *william@beaglebone:~$* cd /opt/scripts/
> *william@beaglebone:/opt/scripts$* git pull
> *william@beaglebone:/opt/scripts$* cd tools/developers/
> *william@beaglebone:/opt/scripts/tools/developers$* sudo
> ./update_initrd.sh
>
> What this does, is notes what's in uEnv.txt in the way of enabled capes,
> then which overlays you have in /lib/firmware, and "injects" these overlays
> into the initramfs. This is important, and if not done, your overlays will
> not load at boot using this method. But the upside is that once done, this
> will load your overlays at boot faster than any other method. Near
> instantly at boot, 1-2 seconds tops.
>
> Anyway, this method is fairly easy, and is actually the best way to go.
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoxQyVm4q56JLaCWZYhncAHEm7u_7Hoq-nZCj5V3pFaXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-03 Thread William Hermans
@ Sebastian

Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .

*william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
#cmdline=coherent_pool=1M quiet cape_universal=enable
video=HDMI-A-1:1024x768@60e
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=
#cape_disable=bone_capemgr.disable_partno=

cape_enable=capemgr.enable_partno= is the way to go. You can
assign multiple cape overlays with this feature, but I do not remember if
they are space, or comma separated. I'm thinking comma separated, but may
be wrong.

That's the first step.

The second step would be to . . .

Copy all your required overlays into /lib/firmware, which you've probably
already done.

*william@beaglebone:~$* cd /opt/scripts/
*william@beaglebone:/opt/scripts$* git pull
*william@beaglebone:/opt/scripts$* cd tools/developers/
*william@beaglebone:/opt/scripts/tools/developers$* sudo ./update_initrd.sh

What this does, is notes what's in uEnv.txt in the way of enabled capes,
then which overlays you have in /lib/firmware, and "injects" these overlays
into the initramfs. This is important, and if not done, your overlays will
not load at boot using this method. But the upside is that once done, this
will load your overlays at boot faster than any other method. Near
instantly at boot, 1-2 seconds tops.

Anyway, this method is fairly easy, and is actually the best way to go.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoZOwrQ4DYG-NMXnMHCZpzCMAuPzRPFC4idCmLcenu_5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-03 Thread William Hermans
On Sat, Dec 3, 2016 at 10:52 AM, Sebastián Sáez  wrote:

> Again, thanks Williams... that was it.
>
> I commented everything about P9.22 in ./bb.org-overlays/src/arm/
> univ-bbgw-00A0.dts
> Then build and install with your instruccions :)
>
> Which is an elegant way to mount the w1 overlay automatically after reboot?
>

There are a few different ways. Pretty much you can google search for
"debian boot script", and find around 3 different ways, that I can think of
off the top of my head.


   1. write a script that's called by rc.local
   2. write a startup service, there are two ways to do this.
   3. create a one time at boot cron job.

In my mind, using Debian Jessie, creating a systemd service is the correct
way to go about this. But in case that turns out to be too difficult, or
cumbersome for your needs. Technically LSB sysv type services are also
possible in Jessie. These are also rather hard to understand at first too.
So writing a script, and then calling it from rc.local is probably the
easiest way - Initially.

Cron jobs, in my mind are not  really the right way to go. Because again,
in my mind, cron jobs are meant to run something repeatable. Meaning
running something multiple times. Once a day at a specific time, Once every
hour, minute, whatever you like. However, it is possible to run a cron job
once every reboot. . . .


I would however recommend that you read up on systemd services, and use
that method.


>
> By the way, I switched my VCC to 3.3V
>

>
> regards,
> Sebatián
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORop5%3DmL3ESQiXnk06ibUmpY138YVCWXM%2BLmLouJEegQsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-03 Thread Sebastián Sáez
Again, thanks Williams... that was it.

I commented everything about P9.22 in 
./bb.org-overlays/src/arm/univ-bbgw-00A0.dts
Then build and install with your instruccions :)

Which is an elegant way to mount the w1 overlay automatically after reboot?

By the way, I switched my VCC to 3.3V


regards,
Sebatián

On Friday, December 2, 2016 at 5:39:38 PM UTC-8, William Hermans wrote:
>
> Sebastián,
>
> I do not know what to say. You possibly have a pin conflict in one of your 
> overlays somewhere. I'd check through all the source file for the dtbo's 
> you're using, and make sure there are no P9.22 references in an of them. 
> Except the 1-wire overlay file.
>
> On Fri, Dec 2, 2016 at 6:37 PM, William Hermans  > wrote:
>
>> By the way, for informational purposes. The board file I'm loading( 
>> am335x-boneblack-emmc-overlay.dtb 
>> ) for my BBB should also work with BBG's too. At least I've used it with 
>> several Greens, and have had zero problems with it. Now, when I say 
>> "several" think in the range of 40-50 different boards . . .
>>
>> On Fri, Dec 2, 2016 at 6:33 PM, William Hermans > > wrote:
>>
>>>
>>> On Fri, Dec 2, 2016 at 2:37 PM, acheesehead >> > wrote:
>>>
 Thanks William. I'll try out your instructions on Mon.

>>>
>>> One thing I did not mention last night was that I did all this one a 
>>> beaglebone black running . . .
>>>
>>> william@beaglebone:~$ cat /etc/dogtag
>>> BeagleBoard.org Debian Image 2016-10-30
>>> william@beaglebone:~$ uname -r
>>> 4.4.27-ti-r62
>>>
>>> So, someone mentioned in the last couple of days ( I think ) that 
>>> they're using a 3.8.x kernel. A couple of concerns with this is that a) the 
>>> overlays as described by me may not work the same. Meaning, I do not recall 
>>> if 3.8.x overlays are slightly different or not. Through the source, or in 
>>> how dtc compiles the source into "binaries". b) The sysfs file entries are 
>>> possibly going to be different.
>>>
>>> Honestly, I could not say for sure, because last night was the very 
>>> first time I've setup 1-wire on the beaglebone. I just know / knew how to 
>>> modify the overlay's source in order for it to be proper. How to wire up 
>>> the sensor through a buddy of mine( someone with 35+ years electronics 
>>> design experience ). Here, see everyone on the web is saying to run a 4.7k 
>>> resistor between Vdd, and DQ on the sensor. Even if you're externally 
>>> powering the sensor. Where I've been told this is not necessary, and that 
>>> the resistor is only needed if you're going to parasitically power the 
>>> sensor through the DQ pin. Which my buddy does not seem convinced that this 
>>> sensor can be powered through a Beaglebone GPIO. So "erroring" on the side 
>>> of caution least I burn out a GPIO pin, or worse yet the processor. I opted 
>>> to power via an external power source. Also reading the datasheet I noticed 
>>> the input voltage range for the sensor is something like 2v8 to 5v6 ish . . 
>>> . I just powered the sensor straight off P9.5( 5v ). Indeed, in the end, it 
>>> seems to work perfectly fine this way. But I did not double check the temp 
>>> output to make sure it was accurate. I am however reasonably convinced it's 
>>> fine. I'll double check later with another kind of temperature sensor that 
>>> I know is accurate within a degree or two. Close enough for me . . . we 
>>> even have some K-type thermocouplers here( MAX31855 ) that are very 
>>> accurate if it ever comes to that. I haven't done SPI on the beaglebone yet 
>>> though . . . Anyway . . .
>>>
>>> The image I'm using is the one Robert says is the latest Jessie 
>>> "release" image that will be shipping with the BBGW's soon( I believe ). 
>>> Everything else as far as I can remember is pretty stock. Except I've 
>>> installed a few Debian packages that should have no bearing on this subject 
>>> at all ( build-essential, git, nfs-client. acpid, maybe i2c-tools, etc ).
>>>
>>> Wait, one thing I did change in /boot/uEnv.txt:
>>>
>>> ##BeagleBone Black: HDMI (Audio/Video) disabled:
>>> dtb=am335x-boneblack-emmc-overlay.dtb
>>>
>>> I do not think this overlay is loaded by default on the stock image. For 
>>> the pin I chose, I do no think it's related to hdmi at all. But if you're 
>>> going ot use a different pin, you should double check to make the pin does 
>>> not conflict with the hdmi pins. Or some other board function. Picking 
>>> I2C0, or I2C2 pins would also not work out very good. As well as the eMMC 
>>> pins, if you're running off the eMMC . . . standard double check everything.
>>>
>>>
>>>
>>>
>>>
>>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread William Hermans
On Fri, Dec 2, 2016 at 8:10 PM, Dennis Lee Bieber 
wrote:

> 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 ?

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoVppN95-2cp-D1-1wCLsJW5yGHtXfxA7K2A%3DxP1Gr-mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread William Hermans
Sebastián,

I do not know what to say. You possibly have a pin conflict in one of your
overlays somewhere. I'd check through all the source file for the dtbo's
you're using, and make sure there are no P9.22 references in an of them.
Except the 1-wire overlay file.

On Fri, Dec 2, 2016 at 6:37 PM, William Hermans  wrote:

> By the way, for informational purposes. The board file I'm loading(
> am335x-boneblack-emmc-overlay.dtb ) for my BBB should also work with
> BBG's too. At least I've used it with several Greens, and have had zero
> problems with it. Now, when I say "several" think in the range of 40-50
> different boards . . .
>
> On Fri, Dec 2, 2016 at 6:33 PM, William Hermans  wrote:
>
>>
>> On Fri, Dec 2, 2016 at 2:37 PM, acheesehead 
>> wrote:
>>
>>> Thanks William. I'll try out your instructions on Mon.
>>>
>>
>> One thing I did not mention last night was that I did all this one a
>> beaglebone black running . . .
>>
>> william@beaglebone:~$ cat /etc/dogtag
>> BeagleBoard.org Debian Image 2016-10-30
>> william@beaglebone:~$ uname -r
>> 4.4.27-ti-r62
>>
>> So, someone mentioned in the last couple of days ( I think ) that they're
>> using a 3.8.x kernel. A couple of concerns with this is that a) the
>> overlays as described by me may not work the same. Meaning, I do not recall
>> if 3.8.x overlays are slightly different or not. Through the source, or in
>> how dtc compiles the source into "binaries". b) The sysfs file entries are
>> possibly going to be different.
>>
>> Honestly, I could not say for sure, because last night was the very first
>> time I've setup 1-wire on the beaglebone. I just know / knew how to modify
>> the overlay's source in order for it to be proper. How to wire up the
>> sensor through a buddy of mine( someone with 35+ years electronics design
>> experience ). Here, see everyone on the web is saying to run a 4.7k
>> resistor between Vdd, and DQ on the sensor. Even if you're externally
>> powering the sensor. Where I've been told this is not necessary, and that
>> the resistor is only needed if you're going to parasitically power the
>> sensor through the DQ pin. Which my buddy does not seem convinced that this
>> sensor can be powered through a Beaglebone GPIO. So "erroring" on the side
>> of caution least I burn out a GPIO pin, or worse yet the processor. I opted
>> to power via an external power source. Also reading the datasheet I noticed
>> the input voltage range for the sensor is something like 2v8 to 5v6 ish . .
>> . I just powered the sensor straight off P9.5( 5v ). Indeed, in the end, it
>> seems to work perfectly fine this way. But I did not double check the temp
>> output to make sure it was accurate. I am however reasonably convinced it's
>> fine. I'll double check later with another kind of temperature sensor that
>> I know is accurate within a degree or two. Close enough for me . . . we
>> even have some K-type thermocouplers here( MAX31855 ) that are very
>> accurate if it ever comes to that. I haven't done SPI on the beaglebone yet
>> though . . . Anyway . . .
>>
>> The image I'm using is the one Robert says is the latest Jessie "release"
>> image that will be shipping with the BBGW's soon( I believe ). Everything
>> else as far as I can remember is pretty stock. Except I've installed a few
>> Debian packages that should have no bearing on this subject at all (
>> build-essential, git, nfs-client. acpid, maybe i2c-tools, etc ).
>>
>> Wait, one thing I did change in /boot/uEnv.txt:
>>
>> ##BeagleBone Black: HDMI (Audio/Video) disabled:
>> dtb=am335x-boneblack-emmc-overlay.dtb
>>
>> I do not think this overlay is loaded by default on the stock image. For
>> the pin I chose, I do no think it's related to hdmi at all. But if you're
>> going ot use a different pin, you should double check to make the pin does
>> not conflict with the hdmi pins. Or some other board function. Picking
>> I2C0, or I2C2 pins would also not work out very good. As well as the eMMC
>> pins, if you're running off the eMMC . . . standard double check everything.
>>
>>
>>
>>
>>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpi82nBc2kc-%3D6doFwp7w2DXKg4RA9TJEZzpj%3DvZi0k3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread William Hermans
By the way, for informational purposes. The board file I'm loading(
am335x-boneblack-emmc-overlay.dtb ) for my BBB should also work with BBG's
too. At least I've used it with several Greens, and have had zero problems
with it. Now, when I say "several" think in the range of 40-50 different
boards . . .

On Fri, Dec 2, 2016 at 6:33 PM, William Hermans  wrote:

>
> On Fri, Dec 2, 2016 at 2:37 PM, acheesehead  wrote:
>
>> Thanks William. I'll try out your instructions on Mon.
>>
>
> One thing I did not mention last night was that I did all this one a
> beaglebone black running . . .
>
> william@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-10-30
> william@beaglebone:~$ uname -r
> 4.4.27-ti-r62
>
> So, someone mentioned in the last couple of days ( I think ) that they're
> using a 3.8.x kernel. A couple of concerns with this is that a) the
> overlays as described by me may not work the same. Meaning, I do not recall
> if 3.8.x overlays are slightly different or not. Through the source, or in
> how dtc compiles the source into "binaries". b) The sysfs file entries are
> possibly going to be different.
>
> Honestly, I could not say for sure, because last night was the very first
> time I've setup 1-wire on the beaglebone. I just know / knew how to modify
> the overlay's source in order for it to be proper. How to wire up the
> sensor through a buddy of mine( someone with 35+ years electronics design
> experience ). Here, see everyone on the web is saying to run a 4.7k
> resistor between Vdd, and DQ on the sensor. Even if you're externally
> powering the sensor. Where I've been told this is not necessary, and that
> the resistor is only needed if you're going to parasitically power the
> sensor through the DQ pin. Which my buddy does not seem convinced that this
> sensor can be powered through a Beaglebone GPIO. So "erroring" on the side
> of caution least I burn out a GPIO pin, or worse yet the processor. I opted
> to power via an external power source. Also reading the datasheet I noticed
> the input voltage range for the sensor is something like 2v8 to 5v6 ish . .
> . I just powered the sensor straight off P9.5( 5v ). Indeed, in the end, it
> seems to work perfectly fine this way. But I did not double check the temp
> output to make sure it was accurate. I am however reasonably convinced it's
> fine. I'll double check later with another kind of temperature sensor that
> I know is accurate within a degree or two. Close enough for me . . . we
> even have some K-type thermocouplers here( MAX31855 ) that are very
> accurate if it ever comes to that. I haven't done SPI on the beaglebone yet
> though . . . Anyway . . .
>
> The image I'm using is the one Robert says is the latest Jessie "release"
> image that will be shipping with the BBGW's soon( I believe ). Everything
> else as far as I can remember is pretty stock. Except I've installed a few
> Debian packages that should have no bearing on this subject at all (
> build-essential, git, nfs-client. acpid, maybe i2c-tools, etc ).
>
> Wait, one thing I did change in /boot/uEnv.txt:
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> dtb=am335x-boneblack-emmc-overlay.dtb
>
> I do not think this overlay is loaded by default on the stock image. For
> the pin I chose, I do no think it's related to hdmi at all. But if you're
> going ot use a different pin, you should double check to make the pin does
> not conflict with the hdmi pins. Or some other board function. Picking
> I2C0, or I2C2 pins would also not work out very good. As well as the eMMC
> pins, if you're running off the eMMC . . . standard double check everything.
>
>
>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORotw5bW3_ghKFgfjarRa%3DYbyycro6VFvwT9NHAofGn9%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread William Hermans
On Fri, Dec 2, 2016 at 2:37 PM, acheesehead  wrote:

> Thanks William. I'll try out your instructions on Mon.
>

One thing I did not mention last night was that I did all this one a
beaglebone black running . . .

william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-10-30
william@beaglebone:~$ uname -r
4.4.27-ti-r62

So, someone mentioned in the last couple of days ( I think ) that they're
using a 3.8.x kernel. A couple of concerns with this is that a) the
overlays as described by me may not work the same. Meaning, I do not recall
if 3.8.x overlays are slightly different or not. Through the source, or in
how dtc compiles the source into "binaries". b) The sysfs file entries are
possibly going to be different.

Honestly, I could not say for sure, because last night was the very first
time I've setup 1-wire on the beaglebone. I just know / knew how to modify
the overlay's source in order for it to be proper. How to wire up the
sensor through a buddy of mine( someone with 35+ years electronics design
experience ). Here, see everyone on the web is saying to run a 4.7k
resistor between Vdd, and DQ on the sensor. Even if you're externally
powering the sensor. Where I've been told this is not necessary, and that
the resistor is only needed if you're going to parasitically power the
sensor through the DQ pin. Which my buddy does not seem convinced that this
sensor can be powered through a Beaglebone GPIO. So "erroring" on the side
of caution least I burn out a GPIO pin, or worse yet the processor. I opted
to power via an external power source. Also reading the datasheet I noticed
the input voltage range for the sensor is something like 2v8 to 5v6 ish . .
. I just powered the sensor straight off P9.5( 5v ). Indeed, in the end, it
seems to work perfectly fine this way. But I did not double check the temp
output to make sure it was accurate. I am however reasonably convinced it's
fine. I'll double check later with another kind of temperature sensor that
I know is accurate within a degree or two. Close enough for me . . . we
even have some K-type thermocouplers here( MAX31855 ) that are very
accurate if it ever comes to that. I haven't done SPI on the beaglebone yet
though . . . Anyway . . .

The image I'm using is the one Robert says is the latest Jessie "release"
image that will be shipping with the BBGW's soon( I believe ). Everything
else as far as I can remember is pretty stock. Except I've installed a few
Debian packages that should have no bearing on this subject at all (
build-essential, git, nfs-client. acpid, maybe i2c-tools, etc ).

Wait, one thing I did change in /boot/uEnv.txt:

##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb

I do not think this overlay is loaded by default on the stock image. For
the pin I chose, I do no think it's related to hdmi at all. But if you're
going ot use a different pin, you should double check to make the pin does
not conflict with the hdmi pins. Or some other board function. Picking
I2C0, or I2C2 pins would also not work out very good. As well as the eMMC
pins, if you're running off the eMMC . . . standard double check everything.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORocN_O4KkgnykkWDy-h9%3DYoc%2BxhtWH52-ysaM7_-%2BLN1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread Sebastián Sáez
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 



On Friday, December 2, 2016 at 10:49:56 AM UTC-8, Sebastián Sáez wrote:
>
> That's it !, Many thanks Williams
> It works perfect
>
> On Thursday, December 1, 2016 at 9:28:16 PM UTC-8, William Hermans wrote:
>>
>> *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
>> ---
>> >  * Virtual cape for onewire on connector pin P9.22
>> 21c21
>> <   part-number = "BB-W1-P9.12";
>> ---
>> >   part-number = "BB-W1-P9.22";
>> 27c27
>> <   "P9.12";
>> ---
>> >   "P9.22";
>> 35c35
>> <   BONE_P9_12 0x37
>> ---
>> >   BONE_P9_22 0x37
>> 51c51
>> <   gpios = < 28 GPIO_ACTIVE_HIGH>;
>> ---
>> >   gpios = < 2 GPIO_ACTIVE_HIGH>;
>>
>> Backout to the base path:
>> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..
>>
>> Build our newly created overlay:
>> william@beaglebone:~/dev/bb.org-overlays$ make 
>> ./src/arm/BB-W1-P9.22-00A0.dtbo
>>
>> "Install" our overlay:
>> william@beaglebone:~/dev/bb.org-overlays$ sudo cp 
>> ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/
>>
>> Load our overlay:
>> william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' 
>> > /sys/devices/platform/bone_capemgr/slots"
>>
>> Check if the overlay loaded:
>> william@beaglebone:~/dev/bb.org-overlays$ cat 
>> /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22
>>
>>  william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
>> [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', 
>> version 'N/A'
>> [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board 
>> Name,00A0,Override Manuf,BB-W1-P9.22'
>> [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo 
>> 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0
>>
>> Check to make sure kernel modules loaded or not:
>> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
>> w1_therm4886  0
>> w1_gpio 3764  0
>> wire   35398  2 w1_gpio,w1_therm
>>
>> Check sysfs:
>> william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
>> 28-0647ddf6  w1_bus_master1
>>
>> Read from our sensor:
>> william@beaglebone:~/dev/bb.org-overlays$ cat 
>> /sys/bus/w1/devices/28-0647ddf6/w1_slave
>> 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
>> 16 01 4b 46 7f ff 0a 10 98 t=17375
>>
>> Pat self on back for job well done !
>>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/76d4f799-b58b-4ae9-ba01-4630aba45467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread acheesehead
Thanks William. I'll try out your instructions on Mon.

On Thursday, December 1, 2016 at 10:50:19 PM UTC-7, William Hermans wrote:
>
>
> On Thu, Dec 1, 2016 at 10:39 PM, acheesehead  > wrote:
>
>> In all of the examples that I have seen, the P9.x -> GPIO bank.port 
>> translates to GPIO (bank +1).port between lines in the overlay script.
>>
>
> That's incorrect if I understand what you're trying to say. the P8/P9 
> header values for the pins have absolutely no correlation to the kernel pin 
> values. These values can be gleaned from the schematics. But I typically 
> use something like the attached file( in pdf format ) that lists all the 
> important data I need.
>
> For example P9.22 has a kernel gpio value of gpio0_2. What this means is 
> that the pin is on gpio bank0 ( bank zero ), and is pin 2 of that gpio 
> bank. Note, that on the beaglebone there are 4 GPIO banks. gpio0-gpio3. Now 
> with this in mind. to figure out the sysfs gpio number you would . ..
>
> gpio_bank * 32 + pin number. So, for the sysfs file entry for the P9.22 
> pin. Our pin would be gpio2. But for example, and arguments sake. If this 
> pin were on gpio_bank 1, then the sysfs entry for this pin would be gpio34. 
> gpio_bank 1 * 32 + 2.
>
> Irregardless, I just gave you a step by step, exact steps recipe to 
> success. That I wrote as I figured it out for the first time myself. 
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/75641c91-5759-4515-9e74-9bb6e4540346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-02 Thread Sebastián Sáez
That's it !, Many thanks Williams
It works perfect

On Thursday, December 1, 2016 at 9:28:16 PM UTC-8, William Hermans wrote:
>
> *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
> ---
> >  * Virtual cape for onewire on connector pin P9.22
> 21c21
> <   part-number = "BB-W1-P9.12";
> ---
> >   part-number = "BB-W1-P9.22";
> 27c27
> <   "P9.12";
> ---
> >   "P9.22";
> 35c35
> <   BONE_P9_12 0x37
> ---
> >   BONE_P9_22 0x37
> 51c51
> <   gpios = < 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> Backout to the base path:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..
>
> Build our newly created overlay:
> william@beaglebone:~/dev/bb.org-overlays$ make 
> ./src/arm/BB-W1-P9.22-00A0.dtbo
>
> "Install" our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo cp 
> ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/
>
> Load our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' > 
> /sys/devices/platform/bone_capemgr/slots"
>
> Check if the overlay loaded:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22
>
>  william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
> [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', 
> version 'N/A'
> [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-W1-P9.22'
> [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0
>
> Check to make sure kernel modules loaded or not:
> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
> w1_therm4886  0
> w1_gpio 3764  0
> wire   35398  2 w1_gpio,w1_therm
>
> Check sysfs:
> william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
> 28-0647ddf6  w1_bus_master1
>
> Read from our sensor:
> william@beaglebone:~/dev/bb.org-overlays$ cat 
> /sys/bus/w1/devices/28-0647ddf6/w1_slave
> 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
> 16 01 4b 46 7f ff 0a 10 98 t=17375
>
> Pat self on back for job well done !
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2748d3e5-a742-4b1f-b96f-e58904d89633%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
Note the "mode7" column to the far right.

On Thu, Dec 1, 2016 at 10:51 PM, William Hermans  wrote:

> Ah forgot the screenshot . . .
>
> On Thu, Dec 1, 2016 at 10:50 PM, William Hermans 
> wrote:
>
>>
>> On Thu, Dec 1, 2016 at 10:39 PM, acheesehead 
>> wrote:
>>
>>> In all of the examples that I have seen, the P9.x -> GPIO bank.port
>>> translates to GPIO (bank +1).port between lines in the overlay script.
>>>
>>
>> That's incorrect if I understand what you're trying to say. the P8/P9
>> header values for the pins have absolutely no correlation to the kernel pin
>> values. These values can be gleaned from the schematics. But I typically
>> use something like the attached file( in pdf format ) that lists all the
>> important data I need.
>>
>> For example P9.22 has a kernel gpio value of gpio0_2. What this means is
>> that the pin is on gpio bank0 ( bank zero ), and is pin 2 of that gpio
>> bank. Note, that on the beaglebone there are 4 GPIO banks. gpio0-gpio3. Now
>> with this in mind. to figure out the sysfs gpio number you would . ..
>>
>> gpio_bank * 32 + pin number. So, for the sysfs file entry for the P9.22
>> pin. Our pin would be gpio2. But for example, and arguments sake. If this
>> pin were on gpio_bank 1, then the sysfs entry for this pin would be gpio34.
>> gpio_bank 1 * 32 + 2.
>>
>> Irregardless, I just gave you a step by step, exact steps recipe to
>> success. That I wrote as I figured it out for the first time myself.
>>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrQxD6jxKQmJrh1WbMA3LXeYTEnPX7qCrjT9TnzrDOZMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
On Thu, Dec 1, 2016 at 10:39 PM, acheesehead  wrote:

> In all of the examples that I have seen, the P9.x -> GPIO bank.port
> translates to GPIO (bank +1).port between lines in the overlay script.
>

That's incorrect if I understand what you're trying to say. the P8/P9
header values for the pins have absolutely no correlation to the kernel pin
values. These values can be gleaned from the schematics. But I typically
use something like the attached file( in pdf format ) that lists all the
important data I need.

For example P9.22 has a kernel gpio value of gpio0_2. What this means is
that the pin is on gpio bank0 ( bank zero ), and is pin 2 of that gpio
bank. Note, that on the beaglebone there are 4 GPIO banks. gpio0-gpio3. Now
with this in mind. to figure out the sysfs gpio number you would . ..

gpio_bank * 32 + pin number. So, for the sysfs file entry for the P9.22
pin. Our pin would be gpio2. But for example, and arguments sake. If this
pin were on gpio_bank 1, then the sysfs entry for this pin would be gpio34.
gpio_bank 1 * 32 + 2.

Irregardless, I just gave you a step by step, exact steps recipe to
success. That I wrote as I figured it out for the first time myself.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrHK9ANjPM-mzaLK7xhjbKFt5aErTQomyBC1mJ2jBt2rQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
I should probably note that when I connected everything up. I had the
beaglebone powered down, and completely disconnected from everything.

On Thu, Dec 1, 2016 at 10:28 PM, William Hermans  wrote:

> *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
> ---
> >  * Virtual cape for onewire on connector pin P9.22
> 21c21
> <   part-number = "BB-W1-P9.12";
> ---
> >   part-number = "BB-W1-P9.22";
> 27c27
> <   "P9.12";
> ---
> >   "P9.22";
> 35c35
> <   BONE_P9_12 0x37
> ---
> >   BONE_P9_22 0x37
> 51c51
> <   gpios = < 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> Backout to the base path:
> william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..
>
> Build our newly created overlay:
> william@beaglebone:~/dev/bb.org-overlays$ make ./src/arm/BB-W1-P9.22-00A0.
> dtbo
>
> "Install" our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo cp
> ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/
>
> Load our overlay:
> william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22'
> > /sys/devices/platform/bone_capemgr/slots"
>
> Check if the overlay loaded:
> william@beaglebone:~/dev/bb.org-overlays$ cat /sys/devices/platform/bone_
> capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22
>
>  william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
> [ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22',
> version 'N/A'
> [ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,BB-W1-P9.22'
> [ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo
> 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0
>
> Check to make sure kernel modules loaded or not:
> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
> w1_therm4886  0
> w1_gpio 3764  0
> wire   35398  2 w1_gpio,w1_therm
>
> Check sysfs:
> william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
> 28-0647ddf6  w1_bus_master1
>
> Read from our sensor:
> william@beaglebone:~/dev/bb.org-overlays$ cat /sys/bus/w1/devices/28-
> 0647ddf6/w1_slave
> 16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
> 16 01 4b 46 7f ff 0a 10 98 t=17375
>
> Pat self on back for job well done !
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORr2NdHWFi5YynnKhzn5suJHnZSpF%2B3urj_SLM9mH%3Dqm6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
*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
---
>  * Virtual cape for onewire on connector pin P9.22
21c21
<   part-number = "BB-W1-P9.12";
---
>   part-number = "BB-W1-P9.22";
27c27
<   "P9.12";
---
>   "P9.22";
35c35
<   BONE_P9_12 0x37
---
>   BONE_P9_22 0x37
51c51
<   gpios = < 28 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 2 GPIO_ACTIVE_HIGH>;

Backout to the base path:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..

Build our newly created overlay:
william@beaglebone:~/dev/bb.org-overlays$ make
./src/arm/BB-W1-P9.22-00A0.dtbo

"Install" our overlay:
william@beaglebone:~/dev/bb.org-overlays$ sudo cp
./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/

Load our overlay:
william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' >
/sys/devices/platform/bone_capemgr/slots"

Check if the overlay loaded:
william@beaglebone:~/dev/bb.org-overlays$ cat
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22

 william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
[ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22',
version 'N/A'
[ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-W1-P9.22'
[ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0

Check to make sure kernel modules loaded or not:
william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
w1_therm4886  0
w1_gpio 3764  0
wire   35398  2 w1_gpio,w1_therm

Check sysfs:
william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
28-0647ddf6  w1_bus_master1

Read from our sensor:
william@beaglebone:~/dev/bb.org-overlays$ cat
/sys/bus/w1/devices/28-0647ddf6/w1_slave
16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
16 01 4b 46 7f ff 0a 10 98 t=17375

Pat self on back for job well done !

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORo6Yn3ORAM8V4VJbN%3D%2B6ZPEddPtFfQ4BTuvvmOH20%2Bs6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
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.

On Thu, Dec 1, 2016 at 8:47 PM, William Hermans  wrote:

> On Thu, Dec 1, 2016 at 10:57 AM, Sebastián Sáez  wrote:
>
>> 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 = <_pinmux>;
>>>__overlay__ {
>>> dallas_w1_pins: pinmux_dallas_w1_pins {
>>> pinctrl-single,pins = < 0x150 0x37 >;
>>> };
>>>};
>>> };
>>>
>>> fragment@1 {
>>>target = <>;
>>>__overlay__ {
>>>onewire@0 {
>>>compatible  = "w1-gpio";
>>>pinctrl-names   = "default";
>>>pinctrl-0   = <_w1_pins>;
>>>status  = "okay";
>>>
>>>gpios = < 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 = <>;
>__overlay__ {
>onewire@0 {
>compatible  = "w1-gpio";
>pinctrl-names   = "default";
>pinctrl-0   = <_w1_pins>;
>status  = "okay";
>
>*gpios = < 2 0>;*
>};
>
> The code in bold is wrong. The gpio bank for this pin is bank0:
>
> *gpios = < 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
>
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqOahDP0Od7NeFdN4--%3DE2FHiJnvp2n19R9BSNHao-HKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [beagleboard] Re: ds18b20 with BBGW

2016-12-01 Thread William Hermans
On Thu, Dec 1, 2016 at 10:57 AM, Sebastián Sáez  wrote:

> 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 = <_pinmux>;
>>__overlay__ {
>> dallas_w1_pins: pinmux_dallas_w1_pins {
>> pinctrl-single,pins = < 0x150 0x37 >;
>> };
>>};
>> };
>>
>> fragment@1 {
>>target = <>;
>>__overlay__ {
>>onewire@0 {
>>compatible  = "w1-gpio";
>>pinctrl-names   = "default";
>>pinctrl-0   = <_w1_pins>;
>>status  = "okay";
>>
>>gpios = < 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 = <>;
   __overlay__ {
   onewire@0 {
   compatible  = "w1-gpio";
   pinctrl-names   = "default";
   pinctrl-0   = <_w1_pins>;
   status  = "okay";

   *gpios = < 2 0>;*
   };

The code in bold is wrong. The gpio bank for this pin is bank0:

*gpios = < 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

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoDTN4CKWmFHxROnvNj5yX9DXs3owMYwOnFJrQ8s6yM4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.