Re: [beagleboard] PocketBeagle headers

[Robert Nelson]

On Fri, Sep 29, 2017 at 10:03 PM, Graham  wrote:

>
> evilwulfie wrote:
>
> check out samtec
>
> --
>
> Good idea.
>
> But Samtec mostly sells factory direct, so hard for hobbyists to get,
> unless some one who works at Digikey could get them to stock the part we
> would need.
>


Yeah, if we can get a part number, i'll push it up the grapevine.. ;)

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

Re: [beagleboard] PocketBeagle headers

[Graham]

evilwulfie wrote:

check out samtec

--

Good idea.

But Samtec mostly sells factory direct, so hard for hobbyists to get,
unless some one who works at Digikey could get them to stock the part we
would need.

--- Graham,

-- 
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/CAC_N71r0hFHx6w3yxFUWrNQoysg6f4%2BSgoSEzz0T6th6%2B9RD2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle headers

[Robert Nelson]

On Fri, Sep 29, 2017 at 9:47 PM, Graham  wrote:
>
> I generally agree with Jason's proposed "standards."
>
> Female headers facing upwards.
> Male pins facing downwards.
>
> The "Click" boards already do this and come assembled with male header pins
> facing downwards.
>
> The BeagleBones already do it this way.
>
> But there do have to be readily available parts that allow you to implement
> the hardware standard, without forcing things to fit.

For female headers, there's got to be a "thiner" side version made by
someone.. I thought about lightly belt sanding one too see how close
we could get it.

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

Re: [beagleboard] PocketBeagle headers

[Graham]

I generally agree with Jason's proposed "standards."

Female headers facing upwards.
Male pins facing downwards.

The "Click" boards already do this and come assembled with male header pins 
facing downwards.

The BeagleBones already do it this way.

But there do have to be readily available parts that allow you to implement 
the hardware standard, without forcing things to fit.

--- Graham

==

-- 
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/b0001ffb-3c7e-4327-a647-612c3ae8739c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle headers

[Graham]

In looking for a female header receptacle to fit on the top of the board, 
to accept the Click ETH-WIZ Ethernet daughter card, so far, I have only 
found one brand of receptacle that I can make fit.

I would normally expect connectors for the 0.1 inch grid system to be 0.100 
inches wide for single row, and 0.200 inches wide for the dual row.

The Molex CGrid-III series, dual row female, is only 0.195 inches wide at 
the base and will fit on either side of the Octavo chip, and also fit flat 
against the PC board, without forcing, so the connector is vertical.
Line-to-line fit without clearance, but it does fit.

The 3M series is 0.201 inches wide at the base, and there is no way to use 
that connector on the PocketBeagle.

I have some Amphenol-FCI connectors on order, but they were delayed in 
shipping, so no results yet.

The Molex cost more, and are only stocked in distribution with tin mating 
surface (gold flash exists, but no stock found in distribution.)
The Molex is not available in a 36 pin version (18x2), but you can do 
something like a 20 and a 16 to populate all positions. (an 18 pin exists, 
but no stock found in distribution.)

Molex C-Grid-III series, dual row female, tin contacts
Following stocked at both Mouser and Digikey

90151-2116 16 position (8x2)

90151-2120 20 position (10x2)

If someone has another vendor and part number that will fit, I would like 
to hear about it.

--- Graham

==

-- 
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/3132396a-98fc-4779-86f2-cbdc6400f1e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone blue heading drift on small AUV

[jesp . hc]

Hi all,

At my work we use the BeagleBone Blue boards to control somewhat small 
AUVs. 
The board is placed in underwater tubes along with batteries, ESCs for 
thrusters and all other electronics.
We use the in-build magnometer and gyro to calculate the heading for 
navigating under water.
Testing the beagleboard alone on the desk shows that the heading is fairly 
stable and correct within reasonable limits. 
The problem arises when we do offshore tests with the AUV. Here the heading 
will start to drift. A controller has been configured for the AUV to follow 
a reference heading for X amount of time. From the data we can see that the 
AUV actually do keep a steady heading, but from inspecting the vehicle IRL 
it becomes obvious that something is wrong as the vehicle will follow an 
arc instead of a straight line. 

So to the AUV actually thinks that it keeps the same heading and actually 
does this for the first few meters and then starts to turn following an arc 
while still thinking it is on the same heading. 

I know that we introduce quit some noise on the sensors by having the 
batteries, ESCs and wiring going around the board, but could this really be 
the course of this? Can anyone of you think of other possibilities? And can 
anyone suggest a solution to this (other than moving power units and wires 
to another shielded tube - this is not an option at this moment)?

Best,
Jesper

-- 
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/4a4e2cde-de66-499a-9a9e-ec3a1a11b5a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone blue heading drift on small AUV

[jesp . hc]

Hi all,

At my work we use the BeagleBone Blue boards to control somewhat small 
AUVs. 
The board is placed in underwater tubes along with batteries, ESCs for 
thrusters and all other electronics.
We use the in-build magnometer and gyro to calculate the heading for 
navigating under water.
Testing the beagleboard alone on the desk shows that the heading is fairly 
stable and correct within reasonable limits. 
The problem arises when we do offshore tests with the AUV. Here the heading 
will start to drift. A controller has been configured for the AUV to follow 
a reference heading for X amount of time. From the data we can see that the 
AUV actually do keep a steady heading, but from inspecting the vehicle IRL 
it becomes obvious that something is wrong as the vehicle will follow an 
arc instead of a straight line. 

So to the AUV actually thinks that it keeps the same heading and actually 
does this for the first few meters and then starts to turn following an arc 
while still thinking it is on the same heading. 

I know that we introduce quit some noise on the sensors by having the 
batteries, ESCs and wiring going around the board, but could this really be 
the course of this? Can anyone of you think of other possibilities? And can 
anyone suggest a solution to this (other than moving power units and wires 
to another shielded tube - this is not an option at this moment)?

Best,
Jesper

-- 
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/a0e21882-6109-45df-8e35-b3d562098e5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone blue heading drift on small AUV

[jesp . hc]

Hi all,

At my work we use the BeagleBone Blue boards to control somewhat small 
AUVs. 
The board is placed in underwater tubes along with batteries, ESCs for 
thrusters and all other electronics.
We use the in-build magnometer and gyro to calculate the heading for 
navigating under water.
Testing the beagleboard alone on the desk shows that the heading is fairly 
stable and correct within reasonable limits. 
The problem arises when we do offshore tests with the AUV. Here the heading 
will start to drift. A controller has been configured for the AUV to follow 
a reference heading for X amount of time. From the data we can see that the 
AUV actually do keep a steady heading, but from inspecting the vehicle IRL 
it becomes obvious that something is wrong as the vehicle will follow an 
arc instead of a straight line. 

So to the AUV actually thinks that it keeps the same heading and actually 
does this for the first few meters and then starts to turn following an arc 
while still thinking it is on the same heading. 

I know that we introduce quit some noise on the sensors by having the 
batteries, ESCs and wiring going around the board, but could this really be 
the course of this? Can anyone of you think of other possibilities? And can 
anyone suggest a solution to this (other than moving power units and wires 
to another shielded tube - this is not an option at this moment)?

Best,
Jesper

-- 
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/e9e57477-1991-48ae-8474-b12ca8a741bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

[William Hermans]

I think I have it figured out. If you  disable the ecap devices, the dual
channel populate normally. e.g. 0,2,4. But when you do have ecap enabled,
that's when things start to get squirrely. But at least it's not completely
random. There are or seem to be patterns when you have both ecap enabled.
My file structure looked exactly the same as your above where you had ecap
enabled.

On Fri, Sep 29, 2017 at 2:17 PM, Robert Nelson 
wrote:

> On Fri, Sep 29, 2017 at 3:19 PM, William Hermans 
> wrote:
> > Robert,
> >
> > Ok I think I see what you mean now( fully ). With universal IO and the
> > generic startup script enabled. I did see something similar to what you
> were
> > saying. However, if one disables both universal IO, and the generic
> startup
> > script, then writes their own custom overlay for all 3 of the PWM chips
> that
> > are dual channel. You get a structure like this:
> >
> > root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
> > /sys/class/pwm/pwmchip0/:
> > npwm
> > /sys/class/pwm/pwmchip2/:
> > npwm
> > /sys/class/pwm/pwmchip4/:
> > npwm
> >
> > This is consistent across multiple images on the same board. In this
> case a
> > 4G beaglebone black( rev C ). But at the same time as you can see from
> the
> > output above. The two PWM channels for each PWM chip are not enabled. In
> > Jessie, these are populated automatically at boot. How can I make that
> > happen in stretch ? I could write a script, but I think that is done
> > automatically through cape_manager in Jessie ?
>
> What's happening in v4.4.x, the pwm's are now in the correct order, if
> you look at v4.4.x: (pwm came before ecap)
>
> #4.4.88-ti-r129
> pwmchip0 -> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/
> pwm/pwmchip0
> pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/
> pwm/pwmchip2
> pwmchip4 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/
> pwm/pwmchip4
> pwmchip6 -> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/
> pwm/pwmchip6
> pwmchip7 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/
> pwm/pwmchip7
>
> In v4.9.x: (since ecap are considered pwm's) they are now in the order
> of the register address:
>
> pwmchip0 -> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/
> pwm/pwmchip0
> pwmchip1 -> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/
> pwm/pwmchip1
> pwmchip3 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/
> pwm/pwmchip3
> pwmchip5 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/
> pwm/pwmchip5
> pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/
> pwm/pwmchip6
>
> In your case, you only want the dual mode "pwm", (48300200.pwm,
> 48302200.pwm, 48304200.pwm), you shouldn't blindly enable the
> "pwmchip0,2,4" as they are dynamic.  You should grep the symlink
> first.
>
> Ps, watch out for v4.11.x too:
>
> #v4.4.x/v4.9.x
> /sys/class/pwm/pwmchip1/:
> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm0
> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm1
>
> #v4.11.x+
>
> /sys/class/pwm/pwmchip1/:
> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:0
> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:1
>
> (ps, this last change is good thing, notice that udev correctly added
> the "root:pwm" rule.. ;) )
>
> 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/CALHSORpeFHTD5q2WrPaQeLwCQ4D0D%2B_Yr0fTL4FuEZ_hvx%2BwLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

[Robert Nelson]

On Fri, Sep 29, 2017 at 3:19 PM, William Hermans  wrote:
> Robert,
>
> Ok I think I see what you mean now( fully ). With universal IO and the
> generic startup script enabled. I did see something similar to what you were
> saying. However, if one disables both universal IO, and the generic startup
> script, then writes their own custom overlay for all 3 of the PWM chips that
> are dual channel. You get a structure like this:
>
> root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
> /sys/class/pwm/pwmchip0/:
> npwm
> /sys/class/pwm/pwmchip2/:
> npwm
> /sys/class/pwm/pwmchip4/:
> npwm
>
> This is consistent across multiple images on the same board. In this case a
> 4G beaglebone black( rev C ). But at the same time as you can see from the
> output above. The two PWM channels for each PWM chip are not enabled. In
> Jessie, these are populated automatically at boot. How can I make that
> happen in stretch ? I could write a script, but I think that is done
> automatically through cape_manager in Jessie ?

What's happening in v4.4.x, the pwm's are now in the correct order, if
you look at v4.4.x: (pwm came before ecap)

#4.4.88-ti-r129
pwmchip0 -> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip0
pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2
pwmchip4 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4
pwmchip6 -> 
../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip6
pwmchip7 -> 
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7

In v4.9.x: (since ecap are considered pwm's) they are now in the order
of the register address:

pwmchip0 -> 
../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0
pwmchip1 -> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip1
pwmchip3 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3
pwmchip5 -> 
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6

In your case, you only want the dual mode "pwm", (48300200.pwm,
48302200.pwm, 48304200.pwm), you shouldn't blindly enable the
"pwmchip0,2,4" as they are dynamic.  You should grep the symlink
first.

Ps, watch out for v4.11.x too:

#v4.4.x/v4.9.x
/sys/class/pwm/pwmchip1/:
drwxr-xr-x 3 root root0 Sep 29 21:06 pwm0
drwxr-xr-x 3 root root0 Sep 29 21:06 pwm1

#v4.11.x+

/sys/class/pwm/pwmchip1/:
drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:0
drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:1

(ps, this last change is good thing, notice that udev correctly added
the "root:pwm" rule.. ;) )

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

Re: [beagleboard] Re: Debian 9.1.0 with VirtualBox unable to "sudo apt-get install crossbuild-essential-armhf"

[William Hermans]

On Fri, Sep 29, 2017 at 1:54 PM, Jose Valenzuela San Juan <
javal...@gmail.com> wrote:

> Were you able to do this?
> The guide from Derek is a bit outdated.
> You don't have to use the source from embedian (as its deprecated). In
> debian 9 the cross compiling packages are in the standard repository.
> Follow this steps instead - Installation for unstable  - from
> https://wiki.debian.org/CrossToolchains - :
>
> You must enable the appropriate (HOST) foreign architecture before
>> installing the cross-compiler.
>>
>> dpkg --add-architecture armhfapt-get update
>>
>> It is recommended to install the cross environment like this as that
>> pulls in all the necessary components:
>>
>> apt-get install crossbuild-essential-
>>
>> i.e
>>
>> apt-get install crossbuild-essential-armhf
>>
>> But you can install just the compiler with
>>
>> apt-get install gcc-arm-linux-gnueabihf
>>
>> Note that gcc-arm-linux-gnueabihf is (like the native 'gcc') just a
>> metapackage, which brings int he current version of the actual compiler
>> gcc-4.9-arm-linux-gnueabihf (c.f. gcc-4.9)
>>
>
> Everything else form the guide should be ok to follow. You could even try
> to install a newer eclipse version if you want, it works fine.
>
> PD. The step in which you get the error is optional. Derek uses it only to
> show how easy is to get the versions of the libraries you need for either
> architecture
>

You should be aware that Stretch uses a newer gcc: gcc version 6.3.0
20170516 (Debian 6.3.0-18)

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

[beagleboard] Re: Debian 9.1.0 with VirtualBox unable to "sudo apt-get install crossbuild-essential-armhf"

[Jose Valenzuela San Juan]

Were you able to do this?
The guide from Derek is a bit outdated.
You don't have to use the source from embedian (as its deprecated). In 
debian 9 the cross compiling packages are in the standard repository.
Follow this steps instead - Installation for unstable  - 
from https://wiki.debian.org/CrossToolchains - :

You must enable the appropriate (HOST) foreign architecture before 
> installing the cross-compiler.
>
> dpkg --add-architecture armhfapt-get update
>
> It is recommended to install the cross environment like this as that pulls 
> in all the necessary components:
>
> apt-get install crossbuild-essential-
>
> i.e
>
> apt-get install crossbuild-essential-armhf
>
> But you can install just the compiler with
>
> apt-get install gcc-arm-linux-gnueabihf
>
> Note that gcc-arm-linux-gnueabihf is (like the native 'gcc') just a 
> metapackage, which brings int he current version of the actual compiler 
> gcc-4.9-arm-linux-gnueabihf (c.f. gcc-4.9)
>

Everything else form the guide should be ok to follow. You could even try 
to install a newer eclipse version if you want, it works fine.

PD. The step in which you get the error is optional. Derek uses it only to 
show how easy is to get the versions of the libraries you need for either 
architecture


On Thursday, August 10, 2017 at 6:18:57 PM UTC-4, Patrick Ireland wrote:
>
> I am attempting to install the Debian 9.1.0 system to support 
> BeagleBoneBlack on my Windows 10 system.
>
> I am following the Derek Molloy blog site and until I tried to load the 
> "sudo apt-get install libicu-dev:armhf", everything was moving smoothly 
> (within limits of my Linux knowledge).
>
> http://exploringbeaglebone.com/chapter7/
>
> However, the step to install the libraries fails.
>
> "Some packages could not be installed. This may mean that you have 
> requested an impossible situation or if you are using the unstable 
> distribution that some required packages have not yet been created or been 
> moved out of Incoming.
> The following information may help to resolve the situation:
> The following packages have unmet dependencies:
> libicu-dev:armhf : Depends : libc6-dev:armhf but it is not going to be 
> installed or libc-dev:armhf"
>
> This message leads me to believe that the libicu-dev:armhf is not 
> available with Debian 9.1.0 (Stretch).
>
> Am I doing something wrong or is cross library linking not supported on 
> Debian 9.1.0 yet?
>
> Assuming that it is not yet supported, any expected date for availability?
>
> Is my only viable solution to reload using Jessie?
>
> TIA,
>
> Pat
>
>
>
>
>
>

-- 
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/c36eb4cc-c33e-4454-92d2-906f29a6e2e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

[William Hermans]

I mean this hack fix is fairly trivial. Without the qep's being enabled.

debian@wgd:~$ sudo su
root@wgd:/home/debian# cd ~
root@wgd:~# nano pwm-enable.sh









*#!/bin/bashecho '0' > /sys/class/pwm/pwmchip0/exportecho '1' >
/sys/class/pwm/pwmchip0/exportecho '0' >
/sys/class/pwm/pwmchip2/exportecho '1' >
/sys/class/pwm/pwmchip2/exportecho '0' >
/sys/class/pwm/pwmchip4/exportecho '1' >
/sys/class/pwm/pwmchip4/exportexit 0*

root@wgd:~# chmod +x pwm-enable.sh
root@wgd:~# ./pwm-enable.sh

root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip2/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip4/:
npwm
pwm0
pwm1

-- 
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/CALHSORojNm6u5Eb%3DSrWvO%2BBcuVGFBO%3D_UTdjMa%2B-Wnh1V8TBrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

[William Hermans]

Robert,

Ok I think I see what you mean now( fully ). With universal IO and the
generic startup script enabled. I did see something similar to what you
were saying. However, if one disables both universal IO, and the generic
startup script, then writes their own custom overlay for all 3 of the PWM
chips that are dual channel. You get a structure like this:

root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
/sys/class/pwm/pwmchip2/:
npwm
/sys/class/pwm/pwmchip4/:
npwm

This is consistent across multiple images on the same board. In this case a
4G beaglebone black( rev C ). But at the same time as you can see from the
output above. The two PWM channels for each PWM chip are not enabled. In
Jessie, these are populated automatically at boot. How can I make that
happen in stretch ? I could write a script, but I think that is done
automatically through cape_manager in Jessie ?

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

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Jason Kridner]

On Fri, Sep 29, 2017 at 8:55 AM Graham Haddock  wrote:

> You use the "USB-tether-gadget", which, when your USB cable is connected
> to a Windows host computer, allows you to bridge and share the Ethernet
> port on the Windows host.
>
> I have it working on Windows 10.
>
> See
>
>
> https://www.digikey.com/en/maker/blogs/how-to-connect-a-beaglebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee
>
>
> The only difference I found was that with the new security enforcements on
> the Beagle, you need to do something like
>
>  sudo nano /etc/resolv.conf
>
> to add "nameserver 8.8.8.8" to the resolv.conf file, instead of the
> echo... command in the article.
>
> The edits in the beagle are not persistent, so need to be repeated every
> time you reboot.
>
> --- Graham
>
> On Thu, Sep 28, 2017 at 11:09 PM,  wrote:
>
>>
>> I ordered a pocket.  But I have a question with out the internet link how
>> do you add software to the pocket after it's up and running?
>>
>
Please help review and augment this newly added entry to the FAQ:
https://github.com/beagleboard/pocketbeagle/wiki/FAQ#how-do-i-get-connected-to-the-internet



>
>> Thanks  Andy
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>>
> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/JtOGZb-FH2A/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/eeea6761-7389-4429-b00d-e4265d8b197e%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CANN_KV4n36OF%2BM5YdfvEsAo%3DXPSdSYu8Fpq5u_dsFmFSu%2B-YxA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPmTHKOHCzVK7N90qS3J0%3DhUxqgNhYp6%2B5s4RF8byUGqrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle headers

[H. Nikolaus Schaller]

> Am 29.09.2017 um 17:19 schrieb Jason Kridner :
> 
> 
> 
> On Fri, Sep 29, 2017 at 10:32 AM Robert Nelson  > wrote:
> On Fri, Sep 29, 2017 at 7:05 AM, Giulio Moro  > wrote:
> > I got myself a PocketBeagle and I realized that I cannot fit headers on the
> > CPU components side because there is not enough clearance between the pads
> > and the Octavo chip for the plastic of the header to fit in. I am using
> > headers like these https://www.adafruit.com/product/2076 
> > , these
> > https://www.mouser.co.uk/ProductDetail/Gravitech/20Mx2-254mm 
> >  or sockets 
> > like
> > these sockets  https://www.mouser.co.uk/ProductDetail/Gravitech/4Fx2-254mm/ 
> > 
> > None of these would fit.
> >
> > The alternative would be to place the sockets on the bottom side and put the
> > solder on the components side, but it does not seem a great option. Are
> > there any sockets/headers that you use that fit on the components side?
> 
> I've gotten both dual row and single row female headers to fit..
> 
> The secret, use a "CLICK" board to help keep it aligned..
> 
> Single row push hard enough and it'll fit around the Octavo
> 
> Dual Row, they'll be a gap, but enough room to solder:
> 
> See the pictures as an example:
> 
> BTW, we are looking at creating an add-on specification. Feedback from the 
> community is critical.
> 
> Yes, indeed, we know the fit around the Octavo SIP is tight for shrouded 
> connectors. This was to enable use of mikroBUS Click boards (two of them). 
> Robert has shown how it is indeed possible.
> 
> Some conventions it seems we should encourage such that people making add-on 
> daughterboards do them consistently. Feedback requested here.
> 
> * Always put female headers on top and male headers on bottom.
> * Pass-through headers are fine.
> * If populating for a breadboard, try to use the outer rows and use only 
> one-side per board (don't try to span or you won't have a place to put your 
> wires where you can see them.

That is the reason why we thinned out the number of pins to a single row on our 
Letux Cortex 8 OSD3358 board.

> * Add-on daughterboards should tend to use male headers on the bottom, 
> exposing the silkscreen on PocketBeagle's bottom for easy probing.

Sounds very reasonable.

The only downside I see is that you can't press the reset button or see the 
LEDs.

> 
> These are just some thoughts from someone who has been prototyping with the 
> boards for a couple of weeks. The point is to provide feedback. Please chime 
> in on each point feel free to "pile-on" in the feedback. It can be annoying 
> for some people not interested, but should be OK if we keep it to ONE THREAD.
> 
> Some concerns about my thoughts, right off the bat.
> * Using the silkscreen is difficult if you keep the board upright, so putting 
> male headers on bottom makes prototyping on a breadboard difficult.
> * Having male headers on bottom could easily result in shorts when setting 
> the board down.

well, female on top still have metal pins standing out of the bottom side, but 
it might be easier to protect.

> * Ribbon cables and the Pi-style breakouts to breadboards could work if male 
> headers were put on top.
> * Any headers on the bottom will make fitting in the Altoids Smalls mint tin 
> more difficult.
> * Breadboarding often is useful for SPI/I2C/UART devices or 5V/3.3V output 
> not available on the outer rows by default.
> 
> Some alternate thoughts that support my initial position.
> * The headers are positioned to work with Click boards on *top*. This is 
> something I might have changed if we did it over, but my sensibilities tell 
> me the components should be top-side on all boards.
> * If breadboarding, you can always use female headers on top, as suggested, 
> and use male-pins to act as an interposer, flipping the board and selectively 
> placing those male pins on either the inner or outer row. To that end, I 
> might suggest never soldering male headers on the bottom at all, but I can 
> imagine many cases where that is desirable.

Female headers on top is also the default of the BeagleBone. So it has become 
sort of "Beagle"-standard...
So it seems to be quite "natural" to me.

I have thinned out the EAGLE files so that only the board dimensions and the 
contact pads and the silk screen (so that a daughterboard can have the same 
bottom print - but uses male headers):

https://www.goldelico.com/downloads/PocketBeagleCape.sch
https://www.goldelico.com/downloads/PocketBeagleCape.brd

Maybe you could publish an "official" blueprint like this somewhere and 
recommend headers for PocketBeagle and a Cape.

BR,
Nikolaus Schaller

> 
> OK, I had a lot more on my mind, 

Re: [beagleboard] Adding a USB Port to PocketBeagle

[Jason Kridner]

On Fri, Sep 29, 2017 at 8:17 AM Dan Brown  wrote:

> I have added a USB Type A connector to my Pocket Beagle.  When I plug a
> Kingston 8GB Flash Key into the port and boot the PocketBeagle, I can see
> that the device is sort of detected, but I never get access to the Flash.
>

How did you wire it? Here's how I've connected a microUSB:

[image: PocketBeagle_microUSB_bb.png]

I'm looking for a good Fritzing element for the USB type-A, but it is
largely the same except that ID and GND are tied together (connector is
only 4-pin).



> In /var/log/messages I see the following block:
>
> Sep 28 12:08:19 beaglebone kernel: [2.177870] usbcore: registered new
> interface driver usb-storage
> Sep 28 12:08:19 beaglebone kernel: [2.180479] 47401300.usb-phy supply
> vcc not found, using dummy regulator
> Sep 28 12:08:19 beaglebone kernel: [2.183416] musb-hdrc
> musb-hdrc.0.auto: MUSB HDRC host driver
> Sep 28 12:08:19 beaglebone kernel: [2.183453] musb-hdrc
> musb-hdrc.0.auto: new USB bus registered, assigned bus number 1
> Sep 28 12:08:19 beaglebone kernel: [2.183781] usb usb1: New USB device
> found, idVendor=1d6b, idProduct=0002
> Sep 28 12:08:19 beaglebone kernel: [2.183795] usb usb1: New USB device
> strings: Mfr=3, Product=2, SerialNumber=1
> Sep 28 12:08:19 beaglebone kernel: [2.183805] usb usb1: Product: MUSB
> HDRC host driver
> Sep 28 12:08:19 beaglebone kernel: [2.183814] usb usb1: Manufacturer:
> Linux 4.4.88-ti-r125 musb-hcd
> Sep 28 12:08:19 beaglebone kernel: [2.183824] usb usb1: SerialNumber:
> musb-hdrc.0.auto
> Sep 28 12:08:19 beaglebone kernel: [2.184765] hub 1-0:1.0: USB hub
> found
> Sep 28 12:08:19 beaglebone kernel: [2.184832] hub 1-0:1.0: 1 port
> detected
> Sep 28 12:08:19 beaglebone kernel: [2.187254] 47401b00.usb-phy supply
> vcc not found, using dummy regulator
> Sep 28 12:08:19 beaglebone kernel: [2.189903] musb-hdrc
> musb-hdrc.1.auto: MUSB HDRC host driver
> Sep 28 12:08:19 beaglebone kernel: [2.189941] musb-hdrc
> musb-hdrc.1.auto: new USB bus registered, assigned bus number 2
> Sep 28 12:08:19 beaglebone kernel: [2.190429] usb usb2: New USB device
> found, idVendor=1d6b, idProduct=0002
> Sep 28 12:08:19 beaglebone kernel: [2.190444] usb usb2: New USB device
> strings: Mfr=3, Product=2, SerialNumber=1
> Sep 28 12:08:19 beaglebone kernel: [2.190454] usb usb2: Product: MUSB
> HDRC host driver
> Sep 28 12:08:19 beaglebone kernel: [2.190463] usb usb2: Manufacturer:
> Linux 4.4.88-ti-r125 musb-hcd
> Sep 28 12:08:19 beaglebone kernel: [2.190473] usb usb2: SerialNumber:
> musb-hdrc.1.auto
> Sep 28 12:08:19 beaglebone kernel: [2.191478] hub 2-0:1.0: USB hub
> found
> Sep 28 12:08:19 beaglebone kernel: [2.191554] hub 2-0:1.0: 1 port
> detected
>
> Notice that the network blocks are usb1 and usb2.  Without the Flash key
> inserted, those lines would be usb0 and usb1.
>

The index delta is interesting. Did you change the device tree at all? I
attempted to make the default device tree enable host mode on the USB1
(hardware) port.

Even though the controller shows up, you don't seem to have the flash drive
showing up. Are VBUS and ID connected properly?


>
> lsmod shows:
>
> usb_f_mass_storage 51139  2
>

I believe that is just the "function" mass storage class driver, ie. slave,
not master.


>
> So shouldn't I have a /dev/sdX device then?
>
> --
> 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/061c31aa-5d9b-4258-aacc-f996683185b7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QP%3Db98P0u%2BO5%2BRyS6k6Nu7aNEG6P7YayM-3VUPQnF8y%3D-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle headers

[Jason Kridner]

On Fri, Sep 29, 2017 at 10:32 AM Robert Nelson 
wrote:

> On Fri, Sep 29, 2017 at 7:05 AM, Giulio Moro  wrote:
> > I got myself a PocketBeagle and I realized that I cannot fit headers on
> the
> > CPU components side because there is not enough clearance between the
> pads
> > and the Octavo chip for the plastic of the header to fit in. I am using
> > headers like these https://www.adafruit.com/product/2076, these
> > https://www.mouser.co.uk/ProductDetail/Gravitech/20Mx2-254mm or sockets
> like
> > these sockets
> https://www.mouser.co.uk/ProductDetail/Gravitech/4Fx2-254mm/
> > None of these would fit.
> >
> > The alternative would be to place the sockets on the bottom side and put
> the
> > solder on the components side, but it does not seem a great option. Are
> > there any sockets/headers that you use that fit on the components side?
>
> I've gotten both dual row and single row female headers to fit..
>
> The secret, use a "CLICK" board to help keep it aligned..
>
> Single row push hard enough and it'll fit around the Octavo
>
> Dual Row, they'll be a gap, but enough room to solder:
>
> See the pictures as an example:
>

BTW, we are looking at creating an add-on specification. Feedback from the
community is critical.

Yes, indeed, we know the fit around the Octavo SIP is tight for shrouded
connectors. This was to enable use of mikroBUS Click boards (two of them).
Robert has shown how it is indeed possible.

Some conventions it seems we should encourage such that people making
add-on daughterboards do them consistently. Feedback requested here.

* Always put female headers on top and male headers on bottom.
* Pass-through headers are fine.
* If populating for a breadboard, try to use the outer rows and use only
one-side per board (don't try to span or you won't have a place to put your
wires where you can see them.
* Add-on daughterboards should tend to use male headers on the bottom,
exposing the silkscreen on PocketBeagle's bottom for easy probing.

These are just some thoughts from someone who has been prototyping with the
boards for a couple of weeks. The point is to provide feedback. Please
chime in on each point feel free to "pile-on" in the feedback. It can be
annoying for some people not interested, but should be OK if we keep it to
ONE THREAD.

Some concerns about my thoughts, right off the bat.
* Using the silkscreen is difficult if you keep the board upright, so
putting male headers on bottom makes prototyping on a breadboard difficult.
* Having male headers on bottom could easily result in shorts when setting
the board down.
* Ribbon cables and the Pi-style breakouts to breadboards could work if
male headers were put on top.
* Any headers on the bottom will make fitting in the Altoids Smalls mint
tin more difficult.
* Breadboarding often is useful for SPI/I2C/UART devices or 5V/3.3V output
not available on the outer rows by default.

Some alternate thoughts that support my initial position.
* The headers are positioned to work with Click boards on *top*. This is
something I might have changed if we did it over, but my sensibilities tell
me the components should be top-side on all boards.
* If breadboarding, you can always use female headers on top, as suggested,
and use male-pins to act as an interposer, flipping the board and
selectively placing those male pins on either the inner or outer row. To
that end, I might suggest never soldering male headers on the bottom at
all, but I can imagine many cases where that is desirable.

OK, I had a lot more on my mind, but time for me to say
less-about-me-and-more-about-you. Pile on! (Please use in-line comments to
make the thread readable, rather than just throwing your comments on top.


>
> 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/CAOCHtYg6-P4%3Dq-Db%3DT4nOhKVCGqt0FwJ5yPQVWTvazZNmn13oA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://beagleboard.org/about

-- 
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/CA%2BT6QPkXLk4Q05h9amGyA_sz2vH6Zec%2BTv3d8k5g4QP1Axj7JA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle headers

[Dan Brown]

I have installed my headers on the bottom.  They do not fit on top.  I also 
figure that this is best so I can heatsink the Octavo chip if needed.

On Friday, September 29, 2017 at 8:05:14 AM UTC-4, Giulio Moro wrote:
>
> I got myself a PocketBeagle and I realized that I cannot fit headers on 
> the CPU components side because there is not enough clearance between the 
> pads and the Octavo chip for the plastic of the header to fit in. I am 
> using headers like these https://www.adafruit.com/product/2076, these 
> https://www.mouser.co.uk/ProductDetail/Gravitech/20Mx2-254mm or sockets 
> like these sockets  
> https://www.mouser.co.uk/ProductDetail/Gravitech/4Fx2-254mm/
> None of these would fit.
>
> The alternative would be to place the sockets on the bottom side and put 
> the solder on the components side, but it does not seem a great option. Are 
> there any sockets/headers that you use that fit on the components side?
>

-- 
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/91fcaee3-7750-4418-9cf6-dced55864995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Adding a USB Port to PocketBeagle

[Dan Brown]

I have added a USB Type A connector to my Pocket Beagle.  When I plug a 
Kingston 8GB Flash Key into the port and boot the PocketBeagle, I can see 
that the device is sort of detected, but I never get access to the Flash.

In /var/log/messages I see the following block:

Sep 28 12:08:19 beaglebone kernel: [2.177870] usbcore: registered new 
interface driver usb-storage
Sep 28 12:08:19 beaglebone kernel: [2.180479] 47401300.usb-phy supply 
vcc not found, using dummy regulator
Sep 28 12:08:19 beaglebone kernel: [2.183416] musb-hdrc 
musb-hdrc.0.auto: MUSB HDRC host driver
Sep 28 12:08:19 beaglebone kernel: [2.183453] musb-hdrc 
musb-hdrc.0.auto: new USB bus registered, assigned bus number 1
Sep 28 12:08:19 beaglebone kernel: [2.183781] usb usb1: New USB device 
found, idVendor=1d6b, idProduct=0002
Sep 28 12:08:19 beaglebone kernel: [2.183795] usb usb1: New USB device 
strings: Mfr=3, Product=2, SerialNumber=1
Sep 28 12:08:19 beaglebone kernel: [2.183805] usb usb1: Product: MUSB 
HDRC host driver
Sep 28 12:08:19 beaglebone kernel: [2.183814] usb usb1: Manufacturer: 
Linux 4.4.88-ti-r125 musb-hcd
Sep 28 12:08:19 beaglebone kernel: [2.183824] usb usb1: SerialNumber: 
musb-hdrc.0.auto
Sep 28 12:08:19 beaglebone kernel: [2.184765] hub 1-0:1.0: USB hub found
Sep 28 12:08:19 beaglebone kernel: [2.184832] hub 1-0:1.0: 1 port 
detected
Sep 28 12:08:19 beaglebone kernel: [2.187254] 47401b00.usb-phy supply 
vcc not found, using dummy regulator
Sep 28 12:08:19 beaglebone kernel: [2.189903] musb-hdrc 
musb-hdrc.1.auto: MUSB HDRC host driver
Sep 28 12:08:19 beaglebone kernel: [2.189941] musb-hdrc 
musb-hdrc.1.auto: new USB bus registered, assigned bus number 2
Sep 28 12:08:19 beaglebone kernel: [2.190429] usb usb2: New USB device 
found, idVendor=1d6b, idProduct=0002
Sep 28 12:08:19 beaglebone kernel: [2.190444] usb usb2: New USB device 
strings: Mfr=3, Product=2, SerialNumber=1
Sep 28 12:08:19 beaglebone kernel: [2.190454] usb usb2: Product: MUSB 
HDRC host driver
Sep 28 12:08:19 beaglebone kernel: [2.190463] usb usb2: Manufacturer: 
Linux 4.4.88-ti-r125 musb-hcd
Sep 28 12:08:19 beaglebone kernel: [2.190473] usb usb2: SerialNumber: 
musb-hdrc.1.auto
Sep 28 12:08:19 beaglebone kernel: [2.191478] hub 2-0:1.0: USB hub found
Sep 28 12:08:19 beaglebone kernel: [2.191554] hub 2-0:1.0: 1 port 
detected

Notice that the network blocks are usb1 and usb2.  Without the Flash key 
inserted, those lines would be usb0 and usb1.

lsmod shows:

usb_f_mass_storage 51139  2

So shouldn't I have a /dev/sdX device then?

-- 
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/061c31aa-5d9b-4258-aacc-f996683185b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] board::vcores_init() - SPL doesn't boot if you implement "complex conditional statements"

[Jeff Andich]

Hi,

In u-boot/board/ti/am57xx/board.c, function, vcores_init() appears to be 
initializing a pointer to one of 2-3 tables which appear to contain a set 
of voltage rails for all the cores on a given board. 

I witnessed something a little funky last-night and I was wondering if you 
might have some insight into what's going on.  If you implement a simple 
if, else statement (e.g. with two possible tables), then SPL boots. 
 However, if you implement an if : else if : else construct, the board 
doesn't want to boot.  I'm not sure what's going on here, but I'm wondering 
if vcores_init has timing constraints?  I know that the PMIC shuts 
everything (or at least the A15 cores) down if you don't send a message to 
it on the I2C bus to keep the cores powered on.  

I'm wondering if vcores_init is called close to the end of this time 
window??

If you use a simple if, else statement:

if (board_is_am572x_idk())
{
*omap_vcores = _idk_volts;
}
else
{
*omap_vcores = _x15_volts;
}

SPL loads and vectors to u-boot.

If, however, you code the following construct:


if (board_is_am572x_idk())
{
*omap_vcores = _idk_volts;
}
else if (board_is_am571x_idk())
{
*omap_vcores = _idk_volts;
}
else if (board_is_am572x_custom())
{
*omap_vcores = _x15_volts;
}
else
{
*omap_vcores = _x15_volts;
}


Then all that pops up on the boot console is 1-2 ASCII characters and then 
everything APPEARS dead.

I have no idea what's going on, but I wonder if the additional assembly 
code generated for the else if, else if could be delaying the "stay powered 
on" I2C message which gets sent to the PMIC until after the PMIC has 
already started the core power down ???


Thanks!

Jeff 

-- 
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/78f43fd6-50f8-4305-8db7-046093e1b959%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Announcing $25 PocketBeagle

[Graham Haddock]

You use the "USB-tether-gadget", which, when your USB cable is connected to
a Windows host computer, allows you to bridge and share the Ethernet port
on the Windows host.

I have it working on Windows 10.

See

https://www.digikey.com/en/maker/blogs/how-to-connect-a-beaglebone-black-to-the-internet-using-usb/cdf66181b3a5436e9ad730e4ed4cf9ee


The only difference I found was that with the new security enforcements on
the Beagle, you need to do something like

 sudo nano /etc/resolv.conf

to add "nameserver 8.8.8.8" to the resolv.conf file, instead of the echo...
command in the article.

The edits in the beagle are not persistent, so need to be repeated every
time you reboot.

--- Graham

On Thu, Sep 28, 2017 at 11:09 PM,  wrote:

>
> I ordered a pocket.  But I have a question with out the internet link how
> do you add software to the pocket after it's up and running?
>
> Thanks  Andy
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/JtOGZb-FH2A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/eeea6761-7389-4429-b00d-e4265d8b197e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CANN_KV4n36OF%2BM5YdfvEsAo%3DXPSdSYu8Fpq5u_dsFmFSu%2B-YxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagle headers

[Giulio Moro]

I got myself a PocketBeagle and I realized that I cannot fit headers on the 
CPU components side because there is not enough clearance between the pads 
and the Octavo chip for the plastic of the header to fit in. I am using 
headers like these https://www.adafruit.com/product/2076, 
these https://www.mouser.co.uk/ProductDetail/Gravitech/20Mx2-254mm or 
sockets like these sockets 
 https://www.mouser.co.uk/ProductDetail/Gravitech/4Fx2-254mm/
None of these would fit.

The alternative would be to place the sockets on the bottom side and put 
the solder on the components side, but it does not seem a great option. Are 
there any sockets/headers that you use that fit on the components side?

-- 
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/6a2af8dd-6332-46da-a697-92551e41e128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4DCAPE43 on Beaglebone Black

[l . armstrong1985]

Hi,
I've some problem with 4DCAPE43 and Beaglebone integration.
I read old posts for issue and now I'm be able to use 4DCAPE43-BBB on 
Beaglebone with Debian 8.1 (24/01/2016 - there is problems instead with the 
latest version 9.1), but I still have problem when I enable UART4. In this 
case the screen appear all black. If I look log with dmesg all cape are 
loaded correctly, no conflict is detected. 
The only thing  which I think it could cause problems are cts and rts 
signals of UART4 which overlap some lcddata signals, but if I look BB-UART4 
overlay I think that this pins aren't enabled.
Can you help me to figure out what the problem is?

Thank you in advance!

-- 
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/56b8d9ea-5e11-47f3-bd08-0d42c13c32fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4DCape43 on Beaglebone Black

[l . armstrong1985]

Hi,
I've some problem with 4DCAPE43 and Beaglebone integration.
I read old posts for issue and now I'm be able to use 4DCAPE43-BBB on 
Beaglebone with Debian 8.1 (24/01/2016 - there is problems instead with the 
latest version 9.), but I still have problem when I enable UART4. In this 
case the screen appear all black. If I look log with dmesg all cape are 
loaded correctly, no conflict is detected. 
The only thing  which I think it could cause problems are cts and rts 
signals of UART4 which overlap some lcddata signals, but if I look BB-UART4 
overlay I think that this pins aren't enabled.
Can you help me to figure out what the problem is?

Thank you in advance!

-- 
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/6dc8b11f-8ee5-41c9-bff4-bb707ba574e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4DCape43 on Beaglebone Black

[Fabio Benevento]

Hi,
I've some problem with 4DCAPE43 and Beaglebone integration.
I read old posts for issue and now I'm be able to use 4DCAPE43-BBB on 
Beaglebone with Debian 8.1 (24/01/2016 - there is problems instead with the 
latest version 9.), but I still have problem when I enable UART4. In this 
case the screen appear all black. If I look log with dmesg all cape are 
loaded correctly, no conflict is detected. 
The only thing  which I think it could cause problems are cts and rts 
signals of UART4 which overlap some lcddata signals, but if I look BB-UART4 
overlay I think that this pins aren't enabled.
Can you help me to figure out what the problem is?

Thank you in advance!

-- 
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/a7744068-3aae-45c7-9267-5241e48a645c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] grove ultrasonic ranger interfacing with beaglebone black

[jithunair21]

Hi,
I wanted to interface the grove ultrasonic ranger sensor with beaglebone 
black. i couldnt find any libraries for beaglebone. i found its libraries 
for raspberry pi, arduino etc but not for BBB. If anyone has done it, 
please share the ideas.
Thanks in advance.
Jithu.

-- 
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/34409a64-539e-409f-b119-e99784df81ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Announcing $25 PocketBeagle

[ahbushnell]

I ordered a pocket.  But I have a question with out the internet link how 
do you add software to the pocket after it's up and running?

Thanks  Andy


-- 
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/eeea6761-7389-4429-b00d-e4265d8b197e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.