Re: [beagleboard] Power button and /dev/input/event0 on 4.1.10-bone16

[Super Twang]

I think I'm missing something, and I wonder if Robert C. Nelson would chime 
in. I'm trying to EN-able (not disable) the power button to run a custom 
script when pressed.  I've searched online and have found a lot of related 
questions but not an approach that I can get to work...
 
I'm running kernel pixelite 4.1.34-bone-rt-r24, inside of a distro based 
off of the wheezy console image of 2015-11-03.

The systemd rules seem to DISable the power button (I think), and they are 
present on my system.  But commenting them out doesn't seem to re-enable 
the functionality.  Fwiw I have acpid installed and active, but it doesn't 
seem to work.

Thanks in advance for any pointers you (or anyone else) could provide,
Dave


On Monday, November 2, 2015 at 11:04:15 AM UTC-6, RobertCNelson wrote:
>
> On Mon, Nov 2, 2015 at 11:00 AM, Alberto Potenza 
> > wrote: 
> > Thanks for the answer. 
> > It seems there is not /etc/acpi. I guess it is done somewhere else. 
> > Any ideas? 
>
> systemd: 
>
>
> https://github.com/systemd/systemd/blob/master/src/login/70-power-switch.rules#L13
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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/bb1afeb6-ad46-476d-b610-7eb2a85473cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW SPI0 data corrupt

[Buming Chen]

Thanks! Could you tell me where is the cap on the board? Already read the 
BBGW's SCH, but still couldn't figure it out
And do you think this is the problem caused by specific kernel versions 
(I'm using ubuntu 16.04, 4.4.12-ti-r30)? I assume using SPI0 for 
communication is really common among BBGW users, but after I searched the 
whole forum, just you and me encountered this CLK hardware design issue??   

On Friday, December 2, 2016 at 12:43:24 AM UTC+8, Joe Phaneuf wrote:
>
> Howdy, correct, had to completely remove the cap on the spi0 clock. Hope 
> that helps!
>

-- 
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/62a98a45-a1a7-4c4d-a7bd-74ea33ea8410%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[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

[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.

[beagleboard] Re: ds18b20 with BBGW

[acheesehead]

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.

On Wednesday, November 30, 2016 at 8:58:19 PM UTC-7, Sebastián Sáez wrote:
>
> Hi!
>
> I'm trying to read temp with a ds18b20 sensor. I try with a few tutorial 
> without luck.
>
> Any tips for read this sensor?
> I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 
> 4.4.30-ti-r64)
>
>
> regards,
> Sebastiá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/f1d15dca-80ce-4476-9cb5-94e0899c4f17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[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 = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = <&gpio0 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

[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 = <&gpio1 28 GPIO_ACTIVE_HIGH>;
---
>   gpios = <&gpio0 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] Startup Scripts

[rickyc8888]

Hi Peter,

Thanks for the template!


On Wednesday, November 30, 2016 at 12:36:37 PM UTC+8, Peter Lawler wrote:
>
>
>
> On 28/11/16 22:43, ricky...@gmail.com  wrote: 
> > Hi, 
> > 
> > I am trying to run some simple startup shell scripts when the system 
> boots. 
>
> Hi, 
> If you're after a simple 'single shot' startup, you can use this as a 
> template. I wrote this one because the flashing LEDs seemed to ... 
> distract ... the pets at night... 
>
>
> https://github.com/PeteLawler/starnix-recipes/blob/master/etc/systemd/system/bb-leds-off.service
>  
>
> Instructions on how to install it are in the comments. 
>
> I believe there are ways to have your old style SysV init scripts work 
> with systemd, but I'd suggest for future proofing sake you may be better 
> off just going with the flow. 
>
> Cheers, 
>
> Pete. 
>

-- 
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/fff0c445-0c38-48ea-a08f-58cc8a10f548%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[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 = <&am33xx_pinmux>;
>>>__overlay__ {
>>> dallas_w1_pins: pinmux_dallas_w1_pins {
>>> pinctrl-single,pins = < 0x150 0x37 >;
>>> };
>>>};
>>> };
>>>
>>> fragment@1 {
>>>target = <&ocp>;
>>>__overlay__ {
>>>onewire@0 {
>>>compatible  = "w1-gpio";
>>>pinctrl-names   = "default";
>>>pinctrl-0   = <&dallas_w1_pins>;
>>>status  = "okay";
>>>
>>>gpios = <&gpio1 2 0>;
>>>};
>>>  };
>>> };
>>> };
>>
>>
>> I notice that the bone_capemgr from /sys/devices/bone_capemgr.9/slots to
>> /sys/devices/platform/bone_capemgr/slots
>>
>> I can't found the w1 kernel module at  /sys/bus/w1/devices/DEVICE_ID
>> /w1_slave
>>
>>
>> regards,
>> Sebastián
>>
>>
> You device tree file is wrong. First lets look at this compared to your
> file: https://github.com/beagleboard/bb.org-overlays/
> blob/master/src/arm/BB-W1-P9.12-00A0.dts#L25-L27
>
> exclusive-use =
> /* the pin header uses */
> "P9.22",
> /* the hardware IP uses */
> "gpio0_2";
>
> should be:
>
>
> exclusive-use =
> /* the pin header uses */
> "P9.22";
>
>
> The comment is also wrong, but whatever, it shouldn't hurt anything.
>
> Second:
>
>
> fragment@1 {
>target = <&ocp>;
>__overlay__ {
>onewire@0 {
>compatible  = "w1-gpio";
>pinctrl-names   = "default";
>pinctrl-0   = <&dallas_w1_pins>;
>status  = "okay";
>
>*gpios = <&gpio1 2 0>;*
>};
>
> The code in bold is wrong. The gpio bank for this pin is bank0:
>
> *gpios = <&gpio0 2 0>; *would be the correct assignment.
>
> Lastly, your overlay "compatible" assignment is wrong for your board. It
> should look like this:
>
> https://github.com/beagleboard/bb.org-overlays/
> blob/master/src/arm/BB-W1-P9.12-00A0.dts#L18
>
>
>

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

[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 = <&am33xx_pinmux>;
>>__overlay__ {
>> dallas_w1_pins: pinmux_dallas_w1_pins {
>> pinctrl-single,pins = < 0x150 0x37 >;
>> };
>>};
>> };
>>
>> fragment@1 {
>>target = <&ocp>;
>>__overlay__ {
>>onewire@0 {
>>compatible  = "w1-gpio";
>>pinctrl-names   = "default";
>>pinctrl-0   = <&dallas_w1_pins>;
>>status  = "okay";
>>
>>gpios = <&gpio1 2 0>;
>>};
>>  };
>> };
>> };
>
>
> I notice that the bone_capemgr from /sys/devices/bone_capemgr.9/slots to
> /sys/devices/platform/bone_capemgr/slots
>
> I can't found the w1 kernel module at  /sys/bus/w1/devices/DEVICE_
> ID/w1_slave
>
>
> regards,
> Sebastián
>
>
You device tree file is wrong. First lets look at this compared to your
file:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L25-L27

exclusive-use =
/* the pin header uses */
"P9.22",
/* the hardware IP uses */
"gpio0_2";

should be:


exclusive-use =
/* the pin header uses */
"P9.22";


The comment is also wrong, but whatever, it shouldn't hurt anything.

Second:


fragment@1 {
   target = <&ocp>;
   __overlay__ {
   onewire@0 {
   compatible  = "w1-gpio";
   pinctrl-names   = "default";
   pinctrl-0   = <&dallas_w1_pins>;
   status  = "okay";

   *gpios = <&gpio1 2 0>;*
   };

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

*gpios = <&gpio0 2 0>; *would be the correct assignment.

Lastly, your overlay "compatible" assignment is wrong for your board. It
should look like this:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L18

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

[beagleboard] Re: ds18b20 with BBGW

[Sebastián Sáez]

Hi Dennis,

I attach my circuit. It's connected to P9_22 with a pullup 4.7K resistor. 
Now I'm trying with BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb

I try with this module from this tutorial 

:

/dts-v1/;
> /plugin/;
>  
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "BB-W1";
> version = "00A0";
>  
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.22",
> /* the hardware IP uses */
> "gpio0_2";
>  
> fragment@0 {
>target = <&am33xx_pinmux>;
>__overlay__ {
> dallas_w1_pins: pinmux_dallas_w1_pins {
> pinctrl-single,pins = < 0x150 0x37 >;
> };
>};
> };
>  
> fragment@1 {
>target = <&ocp>;
>__overlay__ {
>onewire@0 {
>compatible  = "w1-gpio";
>pinctrl-names   = "default";
>pinctrl-0   = <&dallas_w1_pins>;
>status  = "okay";
>  
>gpios = <&gpio1 2 0>;
>};
>  };
> };
> };


I notice that the bone_capemgr from /sys/devices/bone_capemgr.9/slots to 
/sys/devices/platform/bone_capemgr/slots

I can't found the w1 kernel module at 
 /sys/bus/w1/devices/DEVICE_ID/w1_slave


regards,
Sebastián


On Thursday, December 1, 2016 at 6:50:52 AM UTC-8, Dennis Lee Bieber wrote:
>
> Number 2: "We want... Information" 
>
> On Wed, 30 Nov 2016 20:03:21 -0800 (PST), Sebastián Sáez 
> > declaimed the following: 
>
> > 
> >I want to read temp with a ds18b20 sensor. I try with a few tutorial 
> >without luck. 
> > 
> What does "without luck" mean? 
>
> Program aborts with segfault? 
>
> Program runs but reports unrealistic values? 
>
> Program hangs up -- and if it does, on what statement (sample of 
> your 
> code would be useful, along with some description of how you have the 
> sensor wired). 
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ 
>
>

-- 
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/374241d6-f9cd-445e-b7a2-b2be80cf2b24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW SPI0 data corrupt

[Joe Phaneuf]

Howdy, correct, had to completely remove the cap on the spi0 clock. Hope that 
helps!

-- 
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/fccba153-c249-4df7-bdc4-e5c419151916%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: ds18b20 with BBGW

[acheesehead]

I also am having no luck. I created an overlay:

root@beaglebone:~# cat w1-p9-13.dts
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black", 
"ti,beaglebone-green";
part-number = "BB-W1";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.13",
/* the hardware IP uses */
"gpio0_31";


fragment@0 {
   target = <&am33xx_pinmux>;
   __overlay__ {
dallas_w1_pins: pinmux_dallas_w1_pins {
pinctrl-single,pins = < 0x74 0x37 >;
};
   };
};

fragment@1 {
   target = <&ocp>;
   __overlay__ {
   onewire@0 {
   compatible  = "w1-gpio";
   pinctrl-names   = "default";
   pinctrl-0   = <&dallas_w1_pins>;
   status  = "okay";

   gpios = <&gpio1 31 0>;
   };
 };
};
};

Compiled and then copied it to /lib/firmware as BB-W1-P9-13-00A0.dtbo. Did 
echo BB-W1-P9-13 > /sys/devices/platform/bone_capemgr/slots. 
root@beaglebone:~# 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-13

tail of dmesg shows:
[  221.082070] bone_capemgr bone_capemgr: slot #6: 'Override Board 
Name,00A0,Override Manuf,BB-W1-P9-13'
[  221.108759] bone_capemgr bone_capemgr: slot #6: dtbo 
'BB-W1-P9-13-00A0.dtbo' loaded; overlay id #0
[  223.111781] w1_master_driver w1_bus_master1: w1_search: max_slave_count 
64 reached, will continue next search.

There is no activity on the oscilloscope for that pin.

root@beaglebone:~# ls /sys/devices/w1_bus_master1/
00-4000  w1_master_add  w1_master_remove
00-8000  w1_master_attempts w1_master_search
driver   w1_master_max_slave_count  w1_master_slave_count
powerw1_master_name w1_master_slaves
subsystemw1_master_pointer  w1_master_timeout
uevent   w1_master_pullup   w1_master_timeout_us

Have tried other overlays on different pins. No luck. The sensor is good, 
since I checked it out on a WiPy V2.0 board.

Am frustrated by this.

Board info:
root@beaglebone:~# uname -a
Linux beaglebone 4.4.29-bone-rt-r14 #1 PREEMPT RT Tue Nov 1 21:30:09 UTC 
2016 armv7l GNU/Linux

On Wednesday, November 30, 2016 at 8:58:19 PM UTC-7, Sebastián Sáez wrote:
>
> Hi!
>
> I'm trying to read temp with a ds18b20 sensor. I try with a few tutorial 
> without luck.
>
> Any tips for read this sensor?
> I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 
> 4.4.30-ti-r64)
>
>
> regards,
> Sebastiá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/9cea473e-5f02-46f9-aee2-3a77e04eb417%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black and RS485 Cape Interface

[William Hermans]

On Thu, Dec 1, 2016 at 5:06 AM, Bouni  wrote:

> Hi,
>
> thanks for your answers!
>
> I've searched the web yesterday in the evening for quite a long time and
> stumbled up on this page:
>
> http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-
> communication.html
>
> If I got it right, I can use the installed Kernel (Linux beaglebone
> 3.8.13-bone71.1) because as of  3.8.13-bone39 RS485 support is built into
> the kernel.
>
> I just did a quick test:
>
> - The beaglebone is connected via USB to my laptop, I ssh into it over
> said usb.
> - I have a USB-RS485 adapter connected to my laptop as well
> - both devices are connected with 2 wires (A&B)
> - I've set the jumper to UART4, for both RX and TX
> - I also connected the RSE pin to P9_15 which is GPIO48
> - UART 4 was activated throug /boot/uEnv.txt (cape_enable=capemgr.enable_
> partno=BB-UART4)
>
> Using this python script https://gist.github.com/Bouni/
> 49a292798e88a7a0956c308b3c9d1190 (inspired by http://inspire.logicsupply.
> com/2014/09/beaglebone-rs-485-communication.html),
> I'm able to communicate over RS485. In my opinion i should be able to
> complete my project with these preconditions.
>
> I was considering sending you that link yesterday, but figured you knew of
it already.


> @William: my ventilation system is completely passiva as far as i know. It
> features a Modbus RTU server from which i can request information or send
> new settings over Modbus RTU.
> My Homeautomation system can only handle Modbus TCP. So my plan is to let
> the BB run a Modbus TCP server which translates the TCP requests to RTU and
> send them to the ventilation system.
> The answers just go the other way round.
>

 Ah, ok  got it.

-- 
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/CALHSORra_1c7COF13fdhe6Ar7ZP2Qkvnf%3DbMEDh8JHaiimdnwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Howto disable HDMI audio only with Debian Jessie on BBB

[kritzel . kratzel]

Just upgraded my BBB from factory image to Debian Jessie: 
https://debian.beagleboard.org/images/bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz

With the old Wheezy image and the concept of virtual HDMI capes it was 
possible to disable *HDMI audio* while keeping *HDMI video* alive 
(uENv.txt: cape_disable=capemgr.disable_partno=BB-BONELT-HDMI). This step 
released all preallocated mcasp0-pins for other applications, e.g. for PRU0 
access, while still having an HDMI display attached and running.

Now with Jessie (no more virtual capes) I have difficulties to realize such 
a scenario. Apparently there is no preconfigured DTB with capemgr, eMMC and 
HDMI enabled, but Audio disabled (see http://elinux.org/BeagleBone_DTBs). 
Also the last table at this page (
http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration) shows 
nothing more than a question mark for that particular case.

Does anyone have a suitable DTB (or *.dts) at hand or can point me to 
information how to generate such a file from existing device tree source 
files?

Thanks,
KK

-- 
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/631a53b5-1a7f-41f5-89f3-993c62dda644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW SPI0 data corrupt

[Buming Chen]

Hey Joe,

spi0 on my BBGW also gave me the wrong result when I ran the spi test code 
by shorting p18 and p21. How did you solve your problem? Replace the 
cap 

On Tuesday, November 15, 2016 at 6:58:35 AM UTC+8, Joe Phaneuf wrote:
>
> Hey, cross posting from seeed studio forums.
>
>
> tldr: clocking in data on spi0 looks cattywompus, spi1 ok
>
> Was noticing an issue with some custom hardware/software that utilizes 
> both spi channels, was working on beaglebone black prior.  Wanted to make 
> it easily reproducible so flashed a bbgw and used adafruit bbio library as 
> an example. 
>
> steps:
>
> 1.) flash BBGW with latest production image 4.4.15-ti-r37 (other kernel 
> versions and imaged used as well) 
>
> 2.) prevent sound drivers from loading, as they conflict with spi1:
>
>   cd /lib/modules/4.4.15-ti-r37/kernel/sound/core
>
>   mv snd.ko snd.ko.bkp
>
> 3.) install adafruit library from source (need latest greatest, pip 
> upgrade didn't work)
>
>   cd ~
>   git clone 
> https://github.com/adafruit/adafruit-beaglebone-io-python.git
>   cd adafruit-beaglebone-io-python
>   python setup.py install
>   cd ..
>
> 4.) reboot 
>
> 5.) use wires to loopback MOSI to MISO, both channels
>
>   short P9.18 and P9.21 with a piece of wire (SPI0)
>
>   short P9.29 and P9.30 with a piece of wire (SPI1)
>
> 6.) put the following into a file and run it
>
> from Adafruit_BBIO.SPI import SPI
> def run(x,y):
>
>   print 'running spi {} {}'.format(x,y)
>   spi = SPI(x,y)
>   spi.mode=2
>   spi.msh=400
>   bytes2send = range(20)
>   print 'sending {}'.format(bytes2send)
>   print spi.xfer2(bytes2send)
>   spi.close()
>
> run(0,0)
> run(1,0)
>
> result:
> sending [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
> 19]
> [128, 7, 28, 31, 112, 231, 124, 127, 192, 135, 156, 159, 240, 231, 252, 
> 255, 0, 7, 28, 31]
> running spi 1 0
> sending [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 
> 19]
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
>
> so, spi1 works in loopback.  spi0...wtf? there are places where it looks 
> like it's double clocking MISO (like a 0x0001 becomes a 0x0011), 
> some of it just looks random. Works fine on beaglebone black.
>
> Thoughts?
> If anyone has spi0 working on a bbgw would love to hear about the setup.
> Thanks!
>

-- 
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/5d5ea604-18b5-453a-8258-3ed3f0fc29a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] ds18b20 with BBGW

[Sebastián Sáez]

Hi Guys!

I want to read temp with a ds18b20 sensor. I try with a few tutorial 
without luck.

Any tips for read this sensor?
I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 
4.4.30-ti-r64)

I have a BeagleBone Green Wireless


regards,
Sebastiá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/14c74d5f-c7b6-4ef6-8ec6-f94f96da77e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black and RS485 Cape Interface

[Bouni]

Hi,

thanks for your answers!

I've searched the web yesterday in the evening for quite a long time and 
stumbled up on this page:

http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html

If I got it right, I can use the installed Kernel (Linux beaglebone 
3.8.13-bone71.1) because as of  3.8.13-bone39 RS485 support is built into 
the kernel.

I just did a quick test:

- The beaglebone is connected via USB to my laptop, I ssh into it over said 
usb.
- I have a USB-RS485 adapter connected to my laptop as well
- both devices are connected with 2 wires (A&B)
- I've set the jumper to UART4, for both RX and TX
- I also connected the RSE pin to P9_15 which is GPIO48
- UART 4 was activated throug /boot/uEnv.txt 
(cape_enable=capemgr.enable_partno=BB-UART4) 

Using this python 
script https://gist.github.com/Bouni/49a292798e88a7a0956c308b3c9d1190 
(inspired by 
http://inspire.logicsupply.com/2014/09/beaglebone-rs-485-communication.html),
I'm able to communicate over RS485. In my opinion i should be able to 
complete my project with these preconditions.

@William: my ventilation system is completely passiva as far as i know. It 
features a Modbus RTU server from which i can request information or send 
new settings over Modbus RTU.
My Homeautomation system can only handle Modbus TCP. So my plan is to let 
the BB run a Modbus TCP server which translates the TCP requests to RTU and 
send them to the ventilation system.
The answers just go the other way round.

On Thursday, December 1, 2016 at 11:05:54 AM UTC+1, William Hermans wrote:
>
>
>
> On Wed, Nov 30, 2016 at 1:21 PM, Bouni > 
> wrote:
>
>> Hi,
>>
>> indeed i want to go for Modbus TCP, but unfortunately my ventilation 
>> system has only Modbus RTU. The BB will act as a Gateway between Modbus TCP 
>> and Serial Modbus RTU.
>>
>
> Does your ventilation system output Modbus over RS485, or is there pure 
> CANBUS output ? What I was proposing, in the case of the later situation. 
> Was to capture the CANBUS output, and directly send that data out over the 
> ethernet port. There are several ways this can be done, and really depends 
> on your programming experience level.
>
> What I did for our case was "decode" the J1939 / Fastpacket 2000 PGN's in 
> real time. Then parse the data out to an intermediary file. Using POSIX 
> shared memory. Where the second half of the application, took that data, 
> and sent it out via a web app / web socket. All this was done directly on 
> the Beaglebone, in real-time, at 1Mbit frame rate. The application also 
> only used around 1% CPU. Both sides. Anyway, I used the socketCAN library 
> to do all this,
>
> Another way you could save this data, if you do not need to communicate 
> data back to your ventilation system. Would be to use the socketCAN candump 
> utility. To dump( pipe ) the CANBUS packets directly into Netcat, and then 
> out to a remote system for later parsing . . . The remote system would also 
> have to be running Linux too in this case. As I believe that there is a 
> netcat binary for Windows, but I think this would not be a very smart move.
>
> However, if your output is Modbus RTU *only*. I'm not very familiar with 
> Modbus, and what your options are. Except, as I recall there is a Linux 
> Modbus development framework of some sort. 
>

-- 
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/9ba7093f-d5a7-4eab-9b96-6e22b6423595%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black and RS485 Cape Interface

[William Hermans]

On Wed, Nov 30, 2016 at 1:21 PM, Bouni  wrote:

> Hi,
>
> indeed i want to go for Modbus TCP, but unfortunately my ventilation
> system has only Modbus RTU. The BB will act as a Gateway between Modbus TCP
> and Serial Modbus RTU.
>

Does your ventilation system output Modbus over RS485, or is there pure
CANBUS output ? What I was proposing, in the case of the later situation.
Was to capture the CANBUS output, and directly send that data out over the
ethernet port. There are several ways this can be done, and really depends
on your programming experience level.

What I did for our case was "decode" the J1939 / Fastpacket 2000 PGN's in
real time. Then parse the data out to an intermediary file. Using POSIX
shared memory. Where the second half of the application, took that data,
and sent it out via a web app / web socket. All this was done directly on
the Beaglebone, in real-time, at 1Mbit frame rate. The application also
only used around 1% CPU. Both sides. Anyway, I used the socketCAN library
to do all this,

Another way you could save this data, if you do not need to communicate
data back to your ventilation system. Would be to use the socketCAN candump
utility. To dump( pipe ) the CANBUS packets directly into Netcat, and then
out to a remote system for later parsing . . . The remote system would also
have to be running Linux too in this case. As I believe that there is a
netcat binary for Windows, but I think this would not be a very smart move.

However, if your output is Modbus RTU *only*. I'm not very familiar with
Modbus, and what your options are. Except, as I recall there is a Linux
Modbus development framework of some sort.

-- 
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/CALHSORobdkiD3ndpLEeczS-FZic-W0Nut73%2B4UQoU5ggwSZEiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black and RS485 Cape Interface

[Firrel]

Hi,

I managed to get the CAN portion working following this forum 
 . It is about the same 
cape.
At this site 
, 
you have a document named getting started and there are indicated steps on 
how to configure and test UART on that cape.
I would suggest you to use codesys for your application as it has built in 
Modbus RTU, at least for the testing purposes. On their forum 
 there are some interesting topics on 
beaglebone and raspberry, so you can try your luck there.
As I never tried the UART portion of that cape, I can't give you exact 
steps, but I hope this will help you.

Best regards
Firrel

Dňa štvrtok, 1. decembra 2016 1:50:18 UTC+1 Bouni napísal(-a):
>
> Hi,
>
> indeed i want to go for Modbus TCP, but unfortunately my ventilation 
> system has only Modbus RTU. The BB will act as a Gateway between Modbus TCP 
> and Serial Modbus RTU.
>
> Am 30. November 2016 21:15:14 MEZ, schrieb William Hermans <
> yyr...@gmail.com >:
>>
>> On Wed, Nov 30, 2016 at 11:45 AM, Bouni > 
>> wrote:
>>
>>> Hi,
>>>
>>> I have almost the same situation. I have a Beaglebone Green and the 
>>> Waveshare RS485 CAN CAPE mentioned in the first post.
>>> In the near future I want to use RS485 to build a Modbus TCP to Modbus 
>>> RTU Gateway to communicate with a central ventilation system in my house.
>>>
>>> What i found out so far is that the Waveshare cape can by default only 
>>> receive or transmit, but not both because it has no way to switch the /RE 
>>> and DE pins of the MAX485.
>>> But in my opinion the middle pin of the 485_RSE JMP Jumper header could 
>>> be connected to a appropriate pin using a jumper wire.
>>>
>>> My problem at the moment is that i have no idea if the kernel shipped 
>>> with the BeagleBone Green (3.8 something) is able to handle RS485, 
>>> especially direction switching.
>>>
>>> I've read that I should use the omap-serial driver instead of the 
>>> 8XXX-serial driver and that i have to apply some overlay stuff, but 
>>> actually 'm completely lost.
>>> It would be very helpful if somebody could point out what steps i need 
>>> to do in order to get RS485 working.
>>>
>>>
>> We bought a Logicsupply RS485 / CAN cape for a similar purpose. The CAN 
>> device we were trying to communicate with was actually a Schneider AC 
>> inverter, using a proprietary CANBUS protocol called "Xanbus"( Originally 
>> Xantrex ). 
>>
>> Anyway, for your case, I'm wondering why you need RS485 / Modbus at all. 
>> Considering the beaglebone has an ethernet port . . .I mean, you're 
>> probably going to want to use Cat5e, or Cat6 anyway, right ?
>>
>>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail 
> gesendet.
>

-- 
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/1c460120-8d8a-49dc-b0b3-d5c21366a5ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.