Re: [beagleboard] Re: Beaglebone Cloud9 Default User

[William Hermans]

>
> *After giving him a configured BBG (he'd have been dead in the water with
> the image that came in the BBG eMMC, which really breaks the ideal for a
> newbie idea) and showing him how to install the Windows drivers and connect
> to the BBG with Chrome web browser, it clearly was a great starting point
> for him.*
>

Anything of this nature still has a learning curve. Personally, I think
things of this nature are a waste of time. Not because they're not handy,
or cool. But instead you have to spend a time investment to learn anything.
So you may as well learn the "underlying basics" so you're better prepared
in the future to deal with more complex problems.

So a very quick example . . . Not knowing what Node-RED really is, I'd have
to spend a considerable amount of time learning this new "software
technology", when I could instead just write  my own code and be done with
it. Now sure, because I'm an experienced developer, who *now* has a decent
bit of javascript / Nodejs experience, this may be easier for me. However,
I had to learn all of this, just like anyone else, and in fact I'm by far
not a Nodejs "expert". And in fact, I knew very little of  Nodejs 3 years
ago when we got our first BBB's . . .


On Fri, Feb 5, 2016 at 11:54 AM, Wally Bkg  wrote:

> I agree that if you plan to have your Beaglebone connected directly to the
> Internet the current default setups are woefully inadequate,  I'm
> comfortable with my IOT stuff behind a solid firewall on a trusted subnet,
> but having just setup a friend with a BBG Cloud9 BoneScript and Node-Red
> and the USB "gadget", it is a pretty setup to explain and demo.
>
> Knowing better tools made me ignore it all starting with my Rev A6 BBW,
> but when a friend very experienced in electronics, but total newbie at
> programming, asked me about Arduino vs. Raspberry Pi vs.  Beaglebone -- he
> was aware of them all but unsure where to start,  I had to play with the
> newbie stuff a bit myself before actually recommending anything.
>
> After giving him a configured BBG (he'd have been dead in the water with
> the image that came in the BBG eMMC, which really breaks the ideal for a
> newbie idea) and showing him how to install the Windows drivers and connect
> to the BBG with Chrome web browser, it clearly was a great starting point
> for him.
>
>
> On Friday, February 5, 2016 at 12:27:59 PM UTC-6, William Hermans wrote:
>>
>>
>>>
>>> * I very much appreciate the reply.  I was accessing Cloud9 through eth0
>>> not usb0 so root access from the network was possible.  Were I only
>>> accessing the BeagleBone over the usb network I wouldn't have been
>>> concerned.  However I remotely connected over port 3000 and saw a command
>>> line running with root.I tried chasing down the problem but found the
>>> Cloud9 IDE just too convoluted to figure out.  I tried but failed to change
>>> the default user and password in the configuration file referred to in my
>>> earlier post.  At that point I simply killed Cloud9, and just used Byobu
>>> (tmux) terminals to work with node.js.*
>>
>>
>> You're not alone with finding cloud9 too convoluted to even bother
>> messing with. Personally, I have years experience with Debian( think over
>> 20 ), and am a very experienced programmer in a few different languages. So
>> I'm not exactly computer illiterate, and can usually solve most problems
>> rather quickly. Not so with the current default base Debian image with
>> cloud9 etc.
>>
>> I actually found it much easier to build my own Debian images from
>> scratch, based on Roberts kernel build guide, compiling Nodejs personally,
>> and installing it via a package, than using the cloud9 images with
>> bonescript, and all that fluff.
>>
>> I just use a very basic custom image that is less than 200M in size, with
>> Nodejs + Express + NPM installed, and then ssh in to write code on a NFS
>> share <--- This is so I can edit code for the BBB on a local system running
>> Windows, in my editor of choice. VIM, and all that is kind of neat, but is
>> not exactly my sort of "thing" . . .
>>
>>
>> On Fri, Feb 5, 2016 at 9:44 AM, Paul Wolfson  wrote:
>>
>>> I very much appreciate the reply.  I was accessing Cloud9 through eth0
>>> not usb0 so root access from the network was possible.  Were I only
>>> accessing the BeagleBone over the usb network I wouldn't have been
>>> concerned.  However I remotely connected over port 3000 and saw a command
>>> line running with root.
>>>
>>> I tried chasing down the p

Re: [beagleboard] Can't see USB hard drive

[William Hermans]

Well then Rikk, your best option at this point may be to google something
like "LInux USB hard drive x.y.z", find unique fixes, and experiment. But
"x.y.z" would be whatever keyword that returns useful results. Which may
also require some experimentation . . .

On Fri, Feb 5, 2016 at 12:04 PM, Rikk Sullenberger 
wrote:

> Just tried the drive minus the hub,  no luck.  I tried with a split cable
> (power/USB)  and a standard cable (peed from the  BBB...  Sane issue.  :(
> On Feb 5, 2016 1:14 PM, "William Hermans"  wrote:
>
>> If the drive does not show up from the output of lsusb, then the hardware
>> isn't connecting to the OS. So, I would suggest bypassing the USB HUB for a
>> temporary test, and see if the drive shows up like that.
>>
>> 3.8.13-bone47 might be old, but I know it works with external self
>> powered USB hard drives. As I've booted from USB in the past . . . Note the
>> date of this blog post I wrote . . . over two years ago.
>> http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/
>>
>> On Fri, Feb 5, 2016 at 10:34 AM, Robert Nelson 
>> wrote:
>>
>>> On Fri, Feb 5, 2016 at 11:31 AM, Rikk Sullenberger
>>>  wrote:
>>> > I am trying to attatch a 360gig USB2 NTFS hard drive to a Beaglebone
>>> Black.
>>> > The drive does not show up under the /dev/ tree, doesn't show up with
>>> lsusb,
>>> > doesn't show up in dmesg..
>>> >
>>> > The drive is self powered, I have tried a different hub, different hard
>>> > drive, the hard drive works on a raspberry..
>>> >
>>> > Anyone had this happen? I bought this BBB a year ago and just started
>>> > playing with it...
>>>
>>> > [   17.647683] usb usb2: Manufacturer: Linux 3.8.13-bone47 musb-hcd
>>> > [   17.647694] usb usb2: SerialNumber: musb-hdrc.0.auto
>>> > [   17.648205] usb usb2: usb_probe_device
>>> > [   17.648223] usb usb2: configuration #1 chosen from 1 choice
>>> > [   17.648269] usb usb2: adding 2-0:1.0 (config #1, interface 0)
>>> > [   17.648396] hub 2-0:1.0: usb_probe_interface
>>> > [   17.648410] hub 2-0:1.0: usb_probe_interface - got id
>>> > [   17.648428] hub 2-0:1.0: USB hub found
>>> > [   17.648452] hub 2-0:1.0: 1 port detected
>>> > [   17.648463] hub 2-0:1.0: standalone hub
>>> > [   17.648473] hub 2-0:1.0: individual port power switching
>>> > [   17.648483] hub 2-0:1.0: no over-current protection
>>> > [   17.648493] hub 2-0:1.0: Single TT
>>> > [   17.648505] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns)
>>> > [   17.648516] hub 2-0:1.0: power on to power good time: 10ms
>>> > [   17.648540] hub 2-0:1.0: local power source is good
>>> > [   17.648599] hub 2-0:1.0: enabling power on all ports
>>> > [   17.748539] hub 2-0:1.0: state 7 ports 1 chg  evt 
>>> > [   17.748600] hub 2-0:1.0: hub_suspend
>>> > [   17.748629] usb usb2: bus auto-suspend, wakeup 1
>>>
>>>
>>> 3.8.13-bone47 is pretty old.. How are you powering the bbb? 5volt dc
>>> jack right
>>>
>>> Give one of the jessie lxqt shapshots a try with a more modern kernel:
>>>
>>>
>>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>>>
>>> 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.
>>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/IfCgSUqeRsQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't see USB hard drive

[William Hermans]

This does totally "smell" of a USB driver issue to me  . . .

On Fri, Feb 5, 2016 at 12:53 PM, William Hermans  wrote:

> Well then Rikk, your best option at this point may be to google something
> like "LInux USB hard drive x.y.z", find unique fixes, and experiment. But
> "x.y.z" would be whatever keyword that returns useful results. Which may
> also require some experimentation . . .
>
> On Fri, Feb 5, 2016 at 12:04 PM, Rikk Sullenberger <
> rikksullen...@gmail.com> wrote:
>
>> Just tried the drive minus the hub,  no luck.  I tried with a split cable
>> (power/USB)  and a standard cable (peed from the  BBB...  Sane issue.  :(
>> On Feb 5, 2016 1:14 PM, "William Hermans"  wrote:
>>
>>> If the drive does not show up from the output of lsusb, then the
>>> hardware isn't connecting to the OS. So, I would suggest bypassing the USB
>>> HUB for a temporary test, and see if the drive shows up like that.
>>>
>>> 3.8.13-bone47 might be old, but I know it works with external self
>>> powered USB hard drives. As I've booted from USB in the past . . . Note the
>>> date of this blog post I wrote . . . over two years ago.
>>> http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/
>>>
>>> On Fri, Feb 5, 2016 at 10:34 AM, Robert Nelson 
>>> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 11:31 AM, Rikk Sullenberger
>>>>  wrote:
>>>> > I am trying to attatch a 360gig USB2 NTFS hard drive to a Beaglebone
>>>> Black.
>>>> > The drive does not show up under the /dev/ tree, doesn't show up with
>>>> lsusb,
>>>> > doesn't show up in dmesg..
>>>> >
>>>> > The drive is self powered, I have tried a different hub, different
>>>> hard
>>>> > drive, the hard drive works on a raspberry..
>>>> >
>>>> > Anyone had this happen? I bought this BBB a year ago and just started
>>>> > playing with it...
>>>>
>>>> > [   17.647683] usb usb2: Manufacturer: Linux 3.8.13-bone47 musb-hcd
>>>> > [   17.647694] usb usb2: SerialNumber: musb-hdrc.0.auto
>>>> > [   17.648205] usb usb2: usb_probe_device
>>>> > [   17.648223] usb usb2: configuration #1 chosen from 1 choice
>>>> > [   17.648269] usb usb2: adding 2-0:1.0 (config #1, interface 0)
>>>> > [   17.648396] hub 2-0:1.0: usb_probe_interface
>>>> > [   17.648410] hub 2-0:1.0: usb_probe_interface - got id
>>>> > [   17.648428] hub 2-0:1.0: USB hub found
>>>> > [   17.648452] hub 2-0:1.0: 1 port detected
>>>> > [   17.648463] hub 2-0:1.0: standalone hub
>>>> > [   17.648473] hub 2-0:1.0: individual port power switching
>>>> > [   17.648483] hub 2-0:1.0: no over-current protection
>>>> > [   17.648493] hub 2-0:1.0: Single TT
>>>> > [   17.648505] hub 2-0:1.0: TT requires at most 8 FS bit times (666
>>>> ns)
>>>> > [   17.648516] hub 2-0:1.0: power on to power good time: 10ms
>>>> > [   17.648540] hub 2-0:1.0: local power source is good
>>>> > [   17.648599] hub 2-0:1.0: enabling power on all ports
>>>> > [   17.748539] hub 2-0:1.0: state 7 ports 1 chg  evt 
>>>> > [   17.748600] hub 2-0:1.0: hub_suspend
>>>> > [   17.748629] usb usb2: bus auto-suspend, wakeup 1
>>>>
>>>>
>>>> 3.8.13-bone47 is pretty old.. How are you powering the bbb? 5volt dc
>>>> jack right
>>>>
>>>> Give one of the jessie lxqt shapshots a try with a more modern kernel:
>>>>
>>>>
>>>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>>>>
>>>> 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.
>>>> 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 a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/IfCgSUqeRsQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't see USB hard drive

[William Hermans]

>
> *Its not an external drive, but I just plugged a 1GB USB memory stick into
> my BBG running "latest" 2015-11-12 with all upgrades as of about five days
> ago.  While nothing auto mounted, and lsusb didn't show anything I could
> recognize as the USB stick, /dev/sd and /dev/sda1 appeared*
>

OK that's odd . . .

So what I was going to before, was to run *fdisk -l* and see if the drive
shows up there, but lsusb always showed my usb driver controller for my
external hard drive. Maybe this is some sort of USB thumb drive sort of
thing ? *shrug*

On Fri, Feb 5, 2016 at 1:02 PM, Wally Bkg  wrote:

> Its not an external drive, but I just plugged a 1GB USB memory stick into
> my BBG running "latest" 2015-11-12 with all upgrades as of about five days
> ago.  While nothing auto mounted, and lsusb didn't show anything I could
> recognize as the USB stick, /dev/sd and /dev/sda1 appeared
>
> mount -t vfat /dev/sda1 /mnt let me list the files.
>
>
> Are the ntfs tools installed on your system?  ('m not certain of the
> actual package name),  are they installed on the beaglebone.org images?
>
>
>
> On Friday, February 5, 2016 at 1:04:32 PM UTC-6, Rikk Sullenberger wrote:
>>
>> Just tried the drive minus the hub,  no luck.  I tried with a split cable
>> (power/USB)  and a standard cable (peed from the  BBB...  Sane issue.  :(
>> On Feb 5, 2016 1:14 PM, "William Hermans"  wrote:
>>
>>> If the drive does not show up from the output of lsusb, then the
>>> hardware isn't connecting to the OS. So, I would suggest bypassing the USB
>>> HUB for a temporary test, and see if the drive shows up like that.
>>>
>>> 3.8.13-bone47 might be old, but I know it works with external self
>>> powered USB hard drives. As I've booted from USB in the past . . . Note the
>>> date of this blog post I wrote . . . over two years ago.
>>> http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/
>>>
>>> On Fri, Feb 5, 2016 at 10:34 AM, Robert Nelson 
>>> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 11:31 AM, Rikk Sullenberger
>>>>  wrote:
>>>> > I am trying to attatch a 360gig USB2 NTFS hard drive to a Beaglebone
>>>> Black.
>>>> > The drive does not show up under the /dev/ tree, doesn't show up with
>>>> lsusb,
>>>> > doesn't show up in dmesg..
>>>> >
>>>> > The drive is self powered, I have tried a different hub, different
>>>> hard
>>>> > drive, the hard drive works on a raspberry..
>>>> >
>>>> > Anyone had this happen? I bought this BBB a year ago and just started
>>>> > playing with it...
>>>>
>>>> > [   17.647683] usb usb2: Manufacturer: Linux 3.8.13-bone47 musb-hcd
>>>> > [   17.647694] usb usb2: SerialNumber: musb-hdrc.0.auto
>>>> > [   17.648205] usb usb2: usb_probe_device
>>>> > [   17.648223] usb usb2: configuration #1 chosen from 1 choice
>>>> > [   17.648269] usb usb2: adding 2-0:1.0 (config #1, interface 0)
>>>> > [   17.648396] hub 2-0:1.0: usb_probe_interface
>>>> > [   17.648410] hub 2-0:1.0: usb_probe_interface - got id
>>>> > [   17.648428] hub 2-0:1.0: USB hub found
>>>> > [   17.648452] hub 2-0:1.0: 1 port detected
>>>> > [   17.648463] hub 2-0:1.0: standalone hub
>>>> > [   17.648473] hub 2-0:1.0: individual port power switching
>>>> > [   17.648483] hub 2-0:1.0: no over-current protection
>>>> > [   17.648493] hub 2-0:1.0: Single TT
>>>> > [   17.648505] hub 2-0:1.0: TT requires at most 8 FS bit times (666
>>>> ns)
>>>> > [   17.648516] hub 2-0:1.0: power on to power good time: 10ms
>>>> > [   17.648540] hub 2-0:1.0: local power source is good
>>>> > [   17.648599] hub 2-0:1.0: enabling power on all ports
>>>> > [   17.748539] hub 2-0:1.0: state 7 ports 1 chg  evt 
>>>> > [   17.748600] hub 2-0:1.0: hub_suspend
>>>> > [   17.748629] usb usb2: bus auto-suspend, wakeup 1
>>>>
>>>>
>>>> 3.8.13-bone47 is pretty old.. How are you powering the bbb? 5volt dc
>>>> jack right
>>>>
>>>> Give one of the jessie lxqt shapshots a try with a more modern kernel:
>>>>
>>>>
>>>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>>>>
>>>> Regards,
>>>>
>>>> --
>&g

Re: [beagleboard] Re: Use GPIO as non-root user?

[William Hermans]

The "safest" way I can think of is put a very specific line in the sudoers
file ( via visudo ). What this does, is allow you to issue a command, using
sudo, potentially without using a passwd. So for example:

sudo sh -c "echo '1' > /sys/class/gpio/gpio67/value"

The above  can be made to run without using a passwd. So what this
**is** is a way to allow a very specific command to be run
as root, without using a passwd. What this **is not** is a way to
secure somethign similar on a multi user system.

So this method does have it's perks, e.g. allowing a very specific
command, say read a GPIO value, that is not really a security
risk, while the rest of the GPIO bank could represent an issue.

I do believe one can achieve something very similar to what I suggest
above using udev rules, but I'm honestly not all that well
versed with udev. . .


On Fri, Feb 5, 2016 at 3:35 PM, jmelson  wrote:

>
>
> On Friday, February 5, 2016 at 4:13:34 PM UTC-6, Drew Fustini wrote:
>>
>> I noticed that the Raspberry Pi kernel adopted /dev/gpiomem to provide a
>> way for non-root users to access GPIO:
>>
>>
>> The poor man's way is to make the executable file be owned  by root, and
> then set the S bit so it takes execute permissions from the file owner.
> You do this with :
>
> sudo chown root:root filename
> sudo chmod u+s filename
>
> This requires a valid root user to be set up.
>
>
> Jon
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Use GPIO as non-root user?

[William Hermans]

So, here is an example of what I mean above.
http://unix.stackexchange.com/questions/18830/how-to-run-a-specific-program-as-root-without-a-password-prompt

3rd post has a decent example.


On Fri, Feb 5, 2016 at 4:26 PM, William Hermans  wrote:

> The "safest" way I can think of is put a very specific line in the sudoers
> file ( via visudo ). What this does, is allow you to issue a command, using
> sudo, potentially without using a passwd. So for example:
>
> sudo sh -c "echo '1' > /sys/class/gpio/gpio67/value"
>
> The above  can be made to run without using a passwd. So what this **is** is 
> a way to allow a very specific command to be run
> as root, without using a passwd. What this **is not** is a way to secure 
> somethign similar on a multi user system.
>
> So this method does have it's perks, e.g. allowing a very specific command, 
> say read a GPIO value, that is not really a security
> risk, while the rest of the GPIO bank could represent an issue.
>
> I do believe one can achieve something very similar to what I suggest above 
> using udev rules, but I'm honestly not all that well
> versed with udev. . .
>
>
> On Fri, Feb 5, 2016 at 3:35 PM, jmelson  wrote:
>
>>
>>
>> On Friday, February 5, 2016 at 4:13:34 PM UTC-6, Drew Fustini wrote:
>>>
>>> I noticed that the Raspberry Pi kernel adopted /dev/gpiomem to provide a
>>> way for non-root users to access GPIO:
>>>
>>>
>>> The poor man's way is to make the executable file be owned  by root, and
>> then set the S bit so it takes execute permissions from the file owner.
>> You do this with :
>>
>> sudo chown root:root filename
>> sudo chmod u+s filename
>>
>> This requires a valid root user to be set up.
>>
>>
>> Jon
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

>
> *This is why Unix/Linux has groups. Do the following:*
>

Using groups is not necessarily the safest way to go about things John. But
I do agree it is a possibility. The only real contention that I have with
using groups. Is . . . my sudo example can be used on a very specific
command, only allowing that very specific command, where all others, no
matter how similar, if not exactly the same will not run. My example if not
really a good illustration of this but imagine this:

echo '1' > /sys/class/gpio/gpio67/value /* allowed */
echo '0' > /sys/class/gpio/gpio67/value /* not allowed */

Obviously the above is very contrived, but there can be a need for
something similar.



Also, when using groups, you do not really want to change groups, but add
groups. e.g. you *do not* want to change group root to wheel ( or whatever
group you want ) for a specific item. Since the system likely needs root to
have access to given items for various reasons. You also want to be as
specific as possible when creating / using groups. As using groups,
wrongly, is a perfect way to add a huge gaping security hole into a system.

On Fri, Feb 5, 2016 at 4:34 PM, John Syne  wrote:

> This is why Unix/Linux has groups. Do the following:
>
> ls -la /dev
>
> You will see groups such as i2c, dialout, tty, etc. If you want to access
> these devices from a regular user account, add your user to those groups.
> If you need to use a device that has root:root, then change the group and
> add your user account to that group.
>
>
> Regards,
> John
>
>
>
>
> On Feb 5, 2016, at 2:13 PM, Drew Fustini  wrote:
>
> I noticed that the Raspberry Pi kernel adopted /dev/gpiomem to provide a
> way for non-root users to access GPIO:
>
> Add /dev/gpiomem device for rootless user GPIO access:
> https://github.com/raspberrypi/linux/pull/1112
>
> Is there anything comparable for BeagleBone?  Anyone have ideas/plans?
>
> I started thinking about this after seeing this post on the Adafruit forum:
>
> Trying to use Adafruit_BBIO library and run as non-root user
>
> https://forums.adafruit.com/viewtopic.php?f=49&t=89338&p=450036#p450036
>
>
> thanks,
> drew
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Cloud9 Default User

[William Hermans]

I "get it" though. Like for me, I know very basic electronics "OK", but
really do not have the time nor inclination to become a fully fledged E.E.
Or my buddy here, who is an excellent E.E. but whom also does not want to
learn how to program.

I will say that the only real differences I can think of between GPIO, and
PWM in any code should only be file path, and values sent to the file
handle. So anyone willing to read through,and understand  the code for
GPIO. Should theoretically be able to adapt that code for PWM as well.

Unfortunately, in my own case. If I do not have the time to bother learning
this "something". Obviously I do not have the time to refactor the existing
code either . . .



On Fri, Feb 5, 2016 at 4:15 PM, Wally Bkg  wrote:

>
>
> On Friday, February 5, 2016 at 1:48:53 PM UTC-6, William Hermans wrote:
>>
>> *After giving him a configured BBG (he'd have been dead in the water with
>>> the image that came in the BBG eMMC, which really breaks the ideal for a
>>> newbie idea) and showing him how to install the Windows drivers and connect
>>> to the BBG with Chrome web browser, it clearly was a great starting point
>>> for him.*
>>>
>>
>> Anything of this nature still has a learning curve. Personally, I think
>> things of this nature are a waste of time. Not because they're not handy,
>> or cool. But instead you have to spend a time investment to learn anything.
>> So you may as well learn the "underlying basics" so you're better prepared
>> in the future to deal with more complex problems.
>>
>> So a very quick example . . . Not knowing what Node-RED really is, I'd
>> have to spend a considerable amount of time learning this new "software
>> technology", when I could instead just write  my own code and be done with
>> it. Now sure, because I'm an experienced developer, who *now* has a decent
>> bit of javascript / Nodejs experience, this may be easier for me. However,
>> I had to learn all of this, just like anyone else, and in fact I'm by far
>> not a Nodejs "expert". And in fact, I knew very little of  Nodejs 3 years
>> ago when we got our first BBB's . . .
>>
>>
> What you say is true, but I'm afraid its been so long since you've started
> with zero programming knowledge that you've forgotten how difficult that
> first step is, its mind numbingly complex when you throw in all the GPIO
> mux options and restrictions of the Beaglebone
>
> A GUI tool like node-red lets a rank beginner do something useful, without
> spending weeks learning programming and languages.  Drag and drop, wire,
> and deploy can result it a rather sophisticated program with distributed
> processing -- a sensor in one building communicating with a actuator in
> another building over a WiFi network using mqtt protocol and mosquito
> broker running on one of the Beaglebones -- all done like drawing a
> schematic diagram -- something people with a hardware background find
> "intuitive".  To use a GPIO as input or output, you drag the node to the
> "tab", double click it, and fill in the necessary "properties" to make the
> function.  The choices are limited to what is available with the "default"
> pin mux settings but for a beginner its feature, not a bug.  If only the
> PWM worked, and there were UART nodes it could do most anything that needs
> response times on the order of human reaction times or longer.
>
> What's nice is that starting with node-red lets my friend ease into
> programming with some cut and paste of nodejs examples and modifying them
> in a "function" node within an otherwise working "flow" (program) to add
> functionality, instead of starting with a blank page and a "Programming
> Language Du-jour for Dummies" book in hand.
>
> Node-red has some rough edges but it has tremendous potential for helping
> "subject matter experts" quickly get into programming  prototype solutions
> to their problems.  I've always said that its far easier to teach a
> Biochemist enough programming to solve a biochemistry problem than is is to
> teach a programmer enough biochemistry to solve a biochemistry problem.
> Things like node-red really lower the bar!
>
>
> Go to the node-red website and look at the "your second flow" example --
> it "polls" the UK power grid at 5 minute intervals and reports true or
> false if the frequency is 50 Hz or greater (below 50 hz, maybe delay
> starting that induction motor a bit to let the grid recover -- minimal
> impact from my one motor, but if millions of motors are making this

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

Drew, FYI, that is just a character device based on /dev/mem/ which could
very easily be done for the Beaglebones as well. In fact, porting their
code would be potentially as simple as redefining pin constants in code,
plus adding an additional 60+ for beaglebones ;)

On Fri, Feb 5, 2016 at 4:47 PM, William Hermans  wrote:

> *This is why Unix/Linux has groups. Do the following:*
>>
>
> Using groups is not necessarily the safest way to go about things John.
> But I do agree it is a possibility. The only real contention that I have
> with using groups. Is . . . my sudo example can be used on a very specific
> command, only allowing that very specific command, where all others, no
> matter how similar, if not exactly the same will not run. My example if not
> really a good illustration of this but imagine this:
>
> echo '1' > /sys/class/gpio/gpio67/value /* allowed */
> echo '0' > /sys/class/gpio/gpio67/value /* not allowed */
>
> Obviously the above is very contrived, but there can be a need for something 
> similar.
>
>
>
> Also, when using groups, you do not really want to change groups, but add
> groups. e.g. you *do not* want to change group root to wheel ( or
> whatever group you want ) for a specific item. Since the system likely
> needs root to have access to given items for various reasons. You also want
> to be as specific as possible when creating / using groups. As using
> groups, wrongly, is a perfect way to add a huge gaping security hole into a
> system.
>
> On Fri, Feb 5, 2016 at 4:34 PM, John Syne  wrote:
>
>> This is why Unix/Linux has groups. Do the following:
>>
>> ls -la /dev
>>
>> You will see groups such as i2c, dialout, tty, etc. If you want to access
>> these devices from a regular user account, add your user to those groups.
>> If you need to use a device that has root:root, then change the group and
>> add your user account to that group.
>>
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 5, 2016, at 2:13 PM, Drew Fustini  wrote:
>>
>> I noticed that the Raspberry Pi kernel adopted /dev/gpiomem to provide a
>> way for non-root users to access GPIO:
>>
>> Add /dev/gpiomem device for rootless user GPIO access:
>> https://github.com/raspberrypi/linux/pull/1112
>>
>> Is there anything comparable for BeagleBone?  Anyone have ideas/plans?
>>
>> I started thinking about this after seeing this post on the Adafruit
>> forum:
>>
>> Trying to use Adafruit_BBIO library and run as non-root user
>>
>> https://forums.adafruit.com/viewtopic.php?f=49&t=89338&p=450036#p450036
>>
>>
>> thanks,
>> drew
>>
>> --
>> 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.
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *When I run experiments I see that the physical addresses are contiguous,
> but are they guaranteed to be? or has this just been "lucky"?*
>

If memory serves, I think they have to be. But, if as you say you've tested
and they've come up contiguous already, then I'm very sure this can not
change. Not unless they memory is somehow freed using free(), and I do not
think that is possible . . .

On Fri, Feb 5, 2016 at 5:33 PM, Bill Gray  wrote:

> Hi,
>
> I've got PRU0 of my BBB pulling in 12 Bytes of data from a ADC with a
> sampling frequency of 31250hz.
>
> I want to stash all of this data in an array that lives in DDR memory.  I
> would like to make the array 0x4000 bytes (16kB) large.  This would give me
> 1365 12 byte records and about 43ms of data to play with.
>
> I'm currently using prussdrv_map_extmem() to hook me up with the DDR
> memory.  It provides me with a memory block that is 256kB, so I have plenty
> of room.
>
> The question I have is... can I count on the physical address in this
> 256kB block of memory to be contiguous?
>
> I'm pretty new to linux memory management, but I see that the "page size"
> is only 4kB... so I imagine that the virtual memory system might chop my
> 256kB block up into bits which might not necessarily have contiguous
> addresses.
>
> If I can count on contiguous addresses, this radically simplifies the
> memory access code in the PRU.  If I can't... well, then I can't, and I've
> got to figure something else out.
>
> When I run experiments I see that the physical addresses are contiguous,
> but are they guaranteed to be? or has this just been "lucky"?
>
> Thanks,
>
> Bill
>
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

>
> *Using sudo seems much less secure as it exposes the application to being
> exploited for security flaws. And since the application is running as root,
> it has access to everything.*
>

So, we have a device on a system that can potentially cause physical damage
to external hardware when something like a wrong GPIO state is toggled, or
such. How would sudo be less secure in this context? In fact under certain
conditions it would be less safe using groups.

Also, "root has access to everything" is wrong. Reread what I've written
above about running specific commands through sudo.

On Fri, Feb 5, 2016 at 6:05 PM, Brian Anderson  wrote:

> Err, why?
>
> Groups are frequently used to restrict access to resources. Android
> exploits groups for permissions and to sandbox applications.  And the
> kernel enforces access.
>
> Using sudo seems much less secure as it exposes the application to being
> exploited for security flaws. And since the application is running as root,
> it has access to everything.
>
> But maybe I'm missing something?
>
> ba
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] gpio-keys works on 3.8.13-bone79 but not jessie 4.1.16-ti-rt-r44

[William Hermans]

>
> *The gpio#'s changed after 3.8, in your gpio-key property, for "gpio3*
> * use &gpio3" not "$gpio4" like was used on 3.8.x*
>

So this means that the gpio banks are now zero based( starting from 0 ) ?
Anything else ?

On Sat, Feb 6, 2016 at 4:22 PM, pabigot  wrote:

>
> On Saturday, February 6, 2016 at 3:31:44 PM UTC-6, RobertCNelson wrote:
>>
>> On Sat, Feb 6, 2016 at 2:56 PM, pabigot  wrote:
>> > I've got a custom cape for BeagleBone Black which has several
>> peripherals
>> > including a 5-switch joystick.  I have device tree nodes for each
>> peripheral
>> > which I add to a copy of am335x-boneblack.dts and use as a fixed device
>> tree
>> > (no overlays) loaded by u-boot.  The joystick pins are bound to
>> gpio-keys
>> > using the gpios property, but I don't specify the interrupts property.
>> >
>> > All peripherals work fine on 3.8.13-bone79, including the joystick
>> (using
>> > evtest).
>> >
>> > On 4.1.16-ti-rt-r44 the joystick does not work.  The input device is
>> > created, and evtest displays the keys it supports, but does not
>> generate
>> > events when the joystick is manipulated.
>>
>> The gpio#'s changed after 3.8, in your gpio-key property, for "gpio3
>> use &gpio3" not "$gpio4" like was used on 3.8.x
>>
>
> I knew that &uart2 from 3.8 needed to be &uart1 as of 3.12, and had fixed
> that.  I hadn't realized the same issue affected the &gpioX aliases,
> because the applications using gpio-of-helper + sysfs "just worked".
>
> Shifting all the &gpioX aliases down one level fixes the problem.
>
> Many thanks for the solution, and all your work on BeagleBone.
>
> Peter
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] UART1 with CTS/RTS on Debian kernel 4.1

[William Hermans]

>
> *But I don't want to use I2C-2... and i don't know how to disable that.*
> *Here is my slots:*
>

So, this is probably enabled in the main board dtb file. Which means, in
order to disable i2c-2, you'll have to edit that file.

**HOWEVER* *if i2c-2 is enabled in the main board file, then there is a
good chance it is needed for something in relation to booting. I do know
that the on board eeprom is used through i2c, for serial number, board type
identification, etc. But not sure which i2c is used. Probably safe to guess
that i2c-2 is what's used though . . .

On Sat, Feb 6, 2016 at 12:23 PM,  wrote:

> Hello
> I'm using image: bone-debian-8.2-console-armhf-2015-12-20-2gb
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.1.13-ti-r36 #1 SMP PREEMPT Fri Dec 11 00:44:56 UTC
> 2015 armv7l GNU/Linux
>
> I can't load cape to use UART1 with CTS/RTS. It looks like pin 95 conflict
> witch I2C-2.
>
> [4.044320] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART1'
> VER 'N/A' PR '0'
> [4.044334] bone_capemgr bone_capemgr: slot #4: override
> 
> [4.045402] bone_capemgr bone_capemgr: initialized OK.
> [4.047681] pinctrl-single 44e10800.pinmux: pin 44e1097c.0 already
> requested by 4819c000.i2c; cannot claim for 48022000.serial
> 
> [4.083531] pinctrl-single 44e10800.pinmux: pin-95 (48022000.serial)
> status -22
> [4.098640] pinctrl-single 44e10800.pinmux: could not request pin 95 (
> 44e1097c.0) from group pinmux_bb_uart1_pins  on device pinctrl-single
>
> But I don't want to use I2C-2... and i don't know how to disable that.
> Here is my 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-UART1
>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,BB-UART2
>  6: P-O-L-   2 Override Board Name,00A0,Override Manuf,BB-UART4
>  7: P-O-L-   3 Override Board Name,00A0,Override Manuf,BB-UART5
>
> Other UART's are loading without any problem.
>
> Here is my uEnv.txt
> root@beaglebone:~# cat /boot/uEnv.txt
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=4.1.13-ti-r36
> #uuid=
> #dtb=
>
> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> #dtb=am335x-boneblack-emmc-overlay.dtb
>
> ##BeagleBone Black: eMMC disabled:
> #dtb=am335x-boneblack-hdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI Audio/eMMC disabled:
> #dtb=am335x-boneblack-nhdmi-overlay.dtb
>
> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
> #dtb=am335x-boneblack-overlay.dtb
>
> ##BeagleBone Black: wl1835
> #dtb=am335x-boneblack-wl1835mod.dtb
>
> ##BeagleBone Black: replicape
> #dtb=am335x-boneblack-replicape.dtb
>
> ##BeagleBone Green: eMMC disabled
> #dtb=am335x-bonegreen-overlay.dtb
>
> cmdline=coherent_pool=1M quiet cape_universal=enable
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M quiet cape_universal=enable
> video=HDMI-A-1:1024x768@60e
>
> ##Example v3.8.x
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> cape_enable=bone_capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5
>
> ##Disable HDMI/eMMC (v3.8.x)
>
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
> ##Disable HDMI (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>
> ##Disable eMMC (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G
>
> ##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
> #cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
> #cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02
>
>
> ##enable Generic eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>
>
> I would be wery thankfull if someone explain me how to disable i2c-2 on
> system startup.
>
>
>
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] New to BBB... question on driving GPIO pins

[William Hermans]

>
> *I'm not sure that the usleep function (or nanosleep) can provide the
> microsecond resolution I need here.*
>

It can, but can never be guaranteed. The problem here is kernel latency.
Which can be mitigated some by using an RT kernel.

*The DCC spec also says that the packet should be resent several times to
> ensure packet delivery, so would it be possible to get this to work using
> the usleep() or nanosleep() timer and GPIO pins with this kind of accuracy
> if I am resending the packets, say, 10 times? I am currently reading
> through Derek Molloy's book on the beaglebone so if I have to do something
> like use the PRUs I will do so, but I am really new to all of this and the
> amount of information out there is just overwhelming! Advice on how to
> proceed is of course greatly appreciated. Thanks!*
>

No idea of this DCC spec, but resending packets "just in case" is terribly
inefficient. usleep() / nanosleep() are Linux API functions, which could be
replaced by using a hardware timer from the Beaglebone. Here, I personally
have zero experience, so I'm not sure how to implement such, or how well it
would truely work out. I can say after reading some of DR Molloy's
companion web page for his book. One can create a high resolution / highly
accurate timer using a PRU.

How I would recommend proceeding . . . is to learn more about the Linux
programming interface ( API ), and experiment. Only you truly know what
*you* want, or need. If using a PRU is required for timing, that is fine,
but do know that communications between Linux, and the PRU can still
present *some* latency issues. Whether these latency issues present a
problem for your project now, is something only you can really answer.
After all, there is nothing that is truly real time, only degrees of "real
time enough".

On Sun, Feb 7, 2016 at 5:07 AM, Benjamin Melikant 
wrote:

> Hi everyone! I am new to embedded linux systems and the beaglebone black.
> I have had some interest lately in creating a DCC model railroad controller
> for a while now, and while I have seen examples out there for Arduino and
> the RPi, not much is out there in the way of handling something like this
> on the beaglebone. The DCC signal is sent to the locomotives through the
> track via square-waveform AC in the voltage range of +-8v to +-22 v. A
> binary 0 is represented by a 100 microsecond +v, and a 100 microsecond -v,
> and a 1 is 58 microseconds +, -. My plan was to use an H-bridge setup to
> provide the +15v to the tracks, and use a GPIO pin on the board to control
> the h-bridge. One example I saw in Python for the RPi used a for loop to
> write the binary information in a similar fashion to this (c-type code
> below):
>
> string bit_pattern = "1100100101"; // example string
>
> for (int i = 0; i < bit_pattern.length(); i++) {
>
>  if (bit_pattern[i] == '1') {
>
>   writePin (WHICHEVER_GPIO, PIN_HIGH);
>   usleep (binary_one_delay);
>   // delay for ~58 microseconds
>   writePin (WHICHEVER_GPIO, PIN_LOW);  //
> turn the pin back off
>   usleep (binary_one_delay);
>   // and delay again to represent 1
>  }
>
>  else if (bit_pattern[i] == '0') {
>
>   // same as above, using different delay pattern
>  }
> }
>
> // the DCC spec says there must be a delay here, I think it was 20
> microseconds minimum?
> usleep(packet_space_delay);
>
>
> I'm not sure that the usleep function (or nanosleep) can provide the
> microsecond resolution I need here. The DCC spec also says that the packet
> should be resent several times to ensure packet delivery, so would it be
> possible to get this to work using the usleep() or nanosleep() timer and
> GPIO pins with this kind of accuracy if I am resending the packets, say, 10
> times? I am currently reading through Derek Molloy's book on the beaglebone
> so if I have to do something like use the PRUs I will do so, but I am
> really new to all of this and the amount of information out there is just
> overwhelming! Advice on how to proceed is of course greatly appreciated.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't see USB hard drive

[William Hermans]

Here's Robert's guide for downloading tools, uboot source, kernel source,
and scripts to compile / set it all up.
https://eewiki.net/display/linuxonarm/BeagleBone+Black


On Sun, Feb 7, 2016 at 11:33 AM, Rikk Sullenberger 
wrote:

> Ok, interesting finding. I have everything running on an sd card. started
> moving to emmc and no USB, nothing at all.. I've come to the conclusion
> that maybe the emmc versions of the op system has a cut down kernel.
>
> I haven't reworked a kernel in 15 years or so.. I'm going to do this, but
> I ask, any ideas of a good on line tutor for kernel rework?
>
> On Fri, Feb 5, 2016 at 3:06 PM, William Hermans  wrote:
>
>> *Its not an external drive, but I just plugged a 1GB USB memory stick
>>> into my BBG running "latest" 2015-11-12 with all upgrades as of about five
>>> days ago.  While nothing auto mounted, and lsusb didn't show anything I
>>> could recognize as the USB stick, /dev/sd and /dev/sda1 appeared*
>>>
>>
>> OK that's odd . . .
>>
>> So what I was going to before, was to run *fdisk -l* and see if the
>> drive shows up there, but lsusb always showed my usb driver controller for
>> my external hard drive. Maybe this is some sort of USB thumb drive sort of
>> thing ? *shrug*
>>
>> On Fri, Feb 5, 2016 at 1:02 PM, Wally Bkg  wrote:
>>
>>> Its not an external drive, but I just plugged a 1GB USB memory stick
>>> into my BBG running "latest" 2015-11-12 with all upgrades as of about five
>>> days ago.  While nothing auto mounted, and lsusb didn't show anything I
>>> could recognize as the USB stick, /dev/sd and /dev/sda1 appeared
>>>
>>> mount -t vfat /dev/sda1 /mnt let me list the files.
>>>
>>>
>>> Are the ntfs tools installed on your system?  ('m not certain of the
>>> actual package name),  are they installed on the beaglebone.org images?
>>>
>>>
>>>
>>> On Friday, February 5, 2016 at 1:04:32 PM UTC-6, Rikk Sullenberger wrote:
>>>>
>>>> Just tried the drive minus the hub,  no luck.  I tried with a split
>>>> cable (power/USB)  and a standard cable (peed from the  BBB...  Sane
>>>> issue.  :(
>>>> On Feb 5, 2016 1:14 PM, "William Hermans"  wrote:
>>>>
>>>>> If the drive does not show up from the output of lsusb, then the
>>>>> hardware isn't connecting to the OS. So, I would suggest bypassing the USB
>>>>> HUB for a temporary test, and see if the drive shows up like that.
>>>>>
>>>>> 3.8.13-bone47 might be old, but I know it works with external self
>>>>> powered USB hard drives. As I've booted from USB in the past . . . Note 
>>>>> the
>>>>> date of this blog post I wrote . . . over two years ago.
>>>>> http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/
>>>>>
>>>>> On Fri, Feb 5, 2016 at 10:34 AM, Robert Nelson 
>>>>> wrote:
>>>>>
>>>>>> On Fri, Feb 5, 2016 at 11:31 AM, Rikk Sullenberger
>>>>>>  wrote:
>>>>>> > I am trying to attatch a 360gig USB2 NTFS hard drive to a
>>>>>> Beaglebone Black.
>>>>>> > The drive does not show up under the /dev/ tree, doesn't show up
>>>>>> with lsusb,
>>>>>> > doesn't show up in dmesg..
>>>>>> >
>>>>>> > The drive is self powered, I have tried a different hub, different
>>>>>> hard
>>>>>> > drive, the hard drive works on a raspberry..
>>>>>> >
>>>>>> > Anyone had this happen? I bought this BBB a year ago and just
>>>>>> started
>>>>>> > playing with it...
>>>>>>
>>>>>> > [   17.647683] usb usb2: Manufacturer: Linux 3.8.13-bone47 musb-hcd
>>>>>> > [   17.647694] usb usb2: SerialNumber: musb-hdrc.0.auto
>>>>>> > [   17.648205] usb usb2: usb_probe_device
>>>>>> > [   17.648223] usb usb2: configuration #1 chosen from 1 choice
>>>>>> > [   17.648269] usb usb2: adding 2-0:1.0 (config #1, interface 0)
>>>>>> > [   17.648396] hub 2-0:1.0: usb_probe_interface
>>>>>> > [   17.648410] hub 2-0:1.0: usb_probe_interface - got id
>>>>>> > [   17.648428] hub 2-0:1.0: USB hub found
>>>>>> > [   17.648452] hub 2-0:1.0: 1 port detected
&g

Re: [beagleboard] New to BBB... question on driving GPIO pins

[William Hermans]

Sounds as though the packets are sent electrically through the tracks,
which is . . . well pretty ingenius, but not totally unexpected I guess. I
had not considered that based on your first post. Because it seemed as
though you were implying switching a GPIO on, and off several times, to
"send" 15vdc out of a DC/DC converter of some type. Which again, seemed
like a really "cheap" way of attempting PWM.

Anyway, I have a pretty decent idea of implementing what you're talking
about, but am busy at the moment, and the post might be fairly lengthy . .
. i'll make a new post once I'm able.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] New to BBB... question on driving GPIO pins

[William Hermans]

Well, I had assumed you're an EE of some sort, or at least have a decent
electronics background. But from memory, each GPIO pin on the board can
only sink 3-5ma current at most. Depending on which pin it is. So this
means you're going to need an external power source no matter what. Which
means, maybe a buffer, maybe a transistor, plus an external power source
this buffer or transistor "switches". Anyway, I'm no EE, so excuse the
rough explanation here.

So, PWM I think is out of the question. If I understand what is going on:
Which seems to be signaling over the tracks ? You tell me. But in this
case, there are only really two options.

The first option, would be to use SPI for the signaling. Typically though,
to use SPI in this manner is usually for "high speed" stuff. Which it does
not seem you really need high speed for this. Also, I've never used SPI in
this manner personally, and thinking of all the different things needing be
done . . . it seems overly complex. But certainly possible.


The second option would be to bitbang GPIO.  First, in this case I
personally would opt to use one of the PRU's. Second, I would probably at
least initially hack one of the DDR3 to PRU examples to do this. By this, I
mean you write a bit pattern to memory, the PRU grabs it, and "spits" it
out over a GPIO pin. I think here is where it would start to get really
interesting for me - Since there would be a lot to consider, and learn.
Because this value you write to memory could also be a bit field containing
the value, GPIO timing, and a repeat value( as in how many times to repeat
).

Whats more in the context of the PRU, reading / writing to DDR3 memory can
be comparatively slow. Since I believe this would be done over the L3
interconnect. But it very well could e more than enough "speed" for your
application. However, if it is not. Then it *should* be possible to mmap()
the PRU's shared memory. Where I believe the PRU's have single cycle reads
/ writes.

Anyway, thats a really high level way of looking at how to solve the
problem. Also since I have not read about the spec, and have not
experimenting with my idea. There could be more to consider.

On Sun, Feb 7, 2016 at 1:32 PM, Benjamin Melikant 
wrote:

> Well I was going to use said conversion technique because each decoder
> soaks ~500mA and needs at minimum 8 volts to work, prefereably somewhere in
> the +-15 to +-18v range. So if I wanted to run 4 -5 locomotives at a time,
> thats 6 amps minimum ability to the track (just to err on the side of
> caution.)There is no way to support this kind of power drain from the board
> itself (neither high enough voltage nor amperage), so either way I will
> have to use a booster of some kind. I chose the method above because there
> are already working solutions that use it. It sounds too like it works
> pretty well, but I really am not too familiar with other techniques for
> doing this kind of thing so I would be very grateful to see an example of a
> different method. I would assume that you would use PWM through an h-bridge
> rather than sending a digital high / low? I look forward to hearing your
> plan. Thank you!
>
> On Sun, Feb 7, 2016 at 3:24 PM, William Hermans  wrote:
>
>> Sounds as though the packets are sent electrically through the tracks,
>> which is . . . well pretty ingenius, but not totally unexpected I guess. I
>> had not considered that based on your first post. Because it seemed as
>> though you were implying switching a GPIO on, and off several times, to
>> "send" 15vdc out of a DC/DC converter of some type. Which again, seemed
>> like a really "cheap" way of attempting PWM.
>>
>> Anyway, I have a pretty decent idea of implementing what you're talking
>> about, but am busy at the moment, and the post might be fairly lengthy . .
>> . i'll make a new post once I'm able.
>>
>> --
>> 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/7385vSRF5DY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.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.
> For more options, visit https://gro

Re: [beagleboard] Segmentation fault error while trying to set the direction of the GPIO pin to perform read operation

[William Hermans]

Also the code could stand a bit more error checking / testing. sprintf()
for example returns an int, negative number for failure, and I also believe
it sets errno. Or on success it returns the number of bytes written, not
including the terminating null.

Anyway, since you're not testing for a negative number on the return value
of sprintf(), you have no idea if it's failing or not . . . That, and
there's probably more I missed, because I only briefly "reviewed" the code.
Seems overly long winded though . . .

On Sun, Feb 7, 2016 at 2:30 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Sun, Feb 7, 2016 at 3:03 AM,   wrote:
> > Hi Everyone,
> >
> > I am new to beaglebone black linux and looking for some support for the
> > issue I am facing. I have been following Derek Molleys video tutorials on
> > how to configure and program the GPIO's here
> >
> http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/
> .
> > Everything was going fine, until I encountered this weird bug that has
> to do
> > something with the memory segments I believe. Searched on net and came
> > across someone who had faced the same issue here
> > https://groups.google.com/forum/#!topic/beagleboard/Xe-oIuQOeI8, did the
> > respective changes in the code as suggested, yet I keep getting
> > segmentation fault error and the execution stops while displaying "Could
> not
> > set the direction of the pin". Here is the code I am trying to fix,
> >
>
> > sprintf(Inputpin_dir,"sys/class/gpio/gpio%d/direction",inputpin);
> >...
> > //Set the direction of the pin
> > if((ButtonHandle = fopen(Inputpin_dir, "rb+"))==NULL)
> > {
> >   printf("Could not set the direction\n");
> >   return 1;> Control comes here and display
> "Could not set the direction and segmentation fault
> > }
>
> The value for the sysfs node is not correct (you're missing the
> initial /). I don't know where the SEGV comes from: compile with with
> the -g flag and run under gdb, and it'll tell you which line is the
> SEGV in.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Cape Bacon & device tree issue on a BBB with 3.8.13 kernel

[William Hermans]

>
> *Many thanks for your help and for your amazing contribution to Linux for
> BBB.*
>

Maybe nitpicking, and a point that perhaps Robert does not care to toot his
own horn over . . . But Robert contributes to Linux for far more than just
the BBB. In the context of beagle hardware, probably 5-6 boards alone . .
.Overall, I'd guess at 20-30 unique boards, but possibly more . . .

On Mon, Feb 8, 2016 at 2:45 PM, YA  wrote:

> You are right, I've done a mess with the I/O, Cape Bacon is now up and
> running !
>
> Many thanks for your help and for your amazing contribution to Linux for
> BBB.
>
> Kind regards,
> YA
>
> Le dimanche 7 février 2016 23:55:38 UTC+1, RobertCNelson a écrit :
>>
>> On Sun, Feb 7, 2016 at 4:34 PM, YA  wrote:
>> >
>> > Sorry I would like to say gpio0_5 (P9.17) and gpio0_4 (P9.18).
>> >
>> > "P9.17", /* shift: gpio0_5 LATCH */
>> > "P9.18", /* shift: gpio0_4 SERIAL */
>> >
>> > These pins remain at 0 logic level.
>>
>> gpio0_4, gpio0_5, not gpio4/gpio5 that's another bank..
>>
>> should be already exported..
>>
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

>
> *I call my success partial because I can get a test LED to turn on, but I
> can't get it to flash using PWM.*
>
> *Any ideas why that would be?*
>

No . . . Because you've given no pertinent details. We'd need to know a few
things, but kernel version used, method used for attempting to control said
PWM, code, etc. All will help. So, if you want help, help us, help you.

On Mon, Feb 8, 2016 at 11:33 AM,  wrote:

> This is John, the guy with the question Drew to above on the Adafruit
> board. (Thanks Drew for starting this conversation here.)
>
> The problem is, this is part of a commercial application. My code will be
> reading and writing to the GPIOs and doing various things, communicating
> data to remote systems... I anticipate adding a fair bit of complexity. I'd
> hate to make a bug that blew something important away or something like
> that. I am generally leery of unnecessary privilege escalation.
>
> So I could
>
> - sudo my entire application, which would be the same as running as root;
> - partition my application and have it invoke the code that interfaces
> directly to the GPIOs as sudo in some way (via shell?);
> - go by way of the PRUs;
> - change permissions;
> - some other way.
>
> I did have partial success changing the permissions on relevant files, ala
>
> https://github.com/cnobile2012/RobotControl/tree/master/contrib
>
> which uses udev to set up permissions (not that I understand udev either.)
>
> I call my success partial because I can get a test LED to turn on, but I
> can't get it to flash using PWM.
>
> Any ideas why that would be?
>
> On Sunday, February 7, 2016 at 10:00:01 AM UTC-6, Mike Bell wrote:
>>
>> On 02/06/2016 12:51 AM, Brian Anderson wrote:
>>
>>
>> My comments are really to do with what I perceive as best practices on
>> how one would approach building systems that are "security conscious".  Of
>> course, "convenience" may direct us in different directions during
>> development.  I am not sure what you are trying to imply by "safe" as in
>> protecting the GPIOs from misuse.  I don't actually see any way to
>> accomplish that.  What I do think one can do is to be aware of security
>> considerations and not unnecessarily present an attack surface that can
>> compromise the entire system.
>>
>>
>> *Using sudo seems much less secure as it exposes the application to being
 exploited for security flaws. And since the application is running as root,
 it has access to everything.*

>>>
>>> So, we have a device on a system that can potentially cause physical
>>> damage to external hardware when something like a wrong GPIO state is
>>> toggled, or such. How would sudo be less secure in this context?
>>>
>>
>> It wouldn't.  And that is not my point.  I am not talking about how to
>> protect the GPIOs from "bad behaved" programs that are "trusted" as implied
>> by the fact that they are running as a normal user in the group that has
>> access to those GPIOs.  If an application is trusted (is a member of the
>> appropriate group or for that matter can sudo), it is a hopeless task to
>> protect the GPIOs from misuse.  What I am trying to point out is that
>> running an app as "root" (sudo, set uid, whatever) exposes a security
>> attack vector...a vector that has access to _all_ system resources.  I
>> would claim that it is an unnecessary exposure...from a security point of
>> view.  YMMV when it comes to "convenience".
>>
>>
>>> In fact under certain conditions it would be less safe using groups.
>>>
>>
>> How would an application running at a non-root level using groups to
>> access protected resources be less "safe" than an application running as
>> root using sudo?
>>
>>
>>>
>>> Also, "root has access to everything" is wrong. Reread what I've written
>>> above about running specific commands through sudo.
>>>
>>
>> Errr, an application running as root, by definition, has access to _all_
>> system resources.  The fact that you are limiting just a single
>> application/user to run sudo doesn't limit the attack surface for that
>> application.  If your root application is compromised in some way, then the
>> entire system can be compromised.  Running as a normal user does not
>> present the same attack surface...its much smaller and sandboxed by the
>> kernel.  Running as root affords no protection enforcement by the kernel.
>>
>> ba
>>
>>
>>>
>>> On Fri, Feb 5, 2016 at 6:05 PM, Brian Anderson  wrote:
>>>
 Err, why?

 Groups are frequently used to restrict access to resources. Android
 exploits groups for permissions and to sandbox applications.  And the
 kernel enforces access.

 Using sudo seems much less secure as it exposes the application to
 being exploited for security flaws. And since the application is running as
 root, it has access to everything.

 But maybe I'm missing something?

 ba

 Brian,
>>
>> This is a great summation of the issue!
>>
>> Mike
>>
> --
> For more options, visit http://bea

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

Have the pins "shifted" in this kernel again ?

On Mon, Feb 8, 2016 at 3:34 PM, Mark A. Yoder 
wrote:

> Sorry, I left that out.
>
> *config-pin -q P9_14*
> P9_14 Mode: pwm
>
> It appears to be set right.
>
> --Mark
>
> On Monday, February 8, 2016 at 5:27:42 PM UTC-5, RobertCNelson wrote:
>
>> On Mon, Feb 8, 2016 at 4:22 PM, Mark A. Yoder 
>> wrote:
>> > I'm have trouble reproducing this.  I'm running
>> >
>> > cat /etc/dogtag
>> > BeagleBoard.org Debian Image 2016-01-24
>> > cat $SLOTS
>> >  0: PF  -1
>> >  1: PF  -1
>> >  2: PF  -1
>> >  3: PF  -1
>> >  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln
>> >
>> > Wire an LED to P9_14 and then:
>> > cd /sys/class/pwm/pwmchip3
>> > echo 0 > export
>> > cd pwm0
>> > echo 1 > enable
>> > echo 10 > period
>> > echo  5 > duty_cycle
>> >
>> > No errors, but the LED doesn't flash. The LED does turn on when I
>> control
>> > via the GPIO.
>> >
>> > What am I missing?
>>
>> What's the status of P9_14?
>>
>> sudo config-pin -q P9.14
>>
>> sudo config-pin P9.14 pwm
>>
>> then re-check:
>>
>> sudo config-pin -q P9.14
>>
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

@Mark,

Yes,and no.

No, in that there is no way to differentiate which header the peripheral is
physically attacked to.

Yes, in that device tree "defines" usually define a device module as
something similar to:

device_tree_friendly_name@

In other words, we should be able to extrapolate which device module, and
pins are used based on their base address. There is also a place in a
systems directory structure that sysfs uses the base address as part of the
path for the device . . .but I can not recall exactly where that is :/


On Mon, Feb 8, 2016 at 4:56 PM, Mark A. Yoder 
wrote:

> Well, they move around depending on which dts you boot under.  P9_14
> appears at /sys/class/pwm/pwmchip*2*/pwm0 with
> *cat $SLOTS *
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,*univ-emmc*
>
> But if you use:
> *cat $SLOTS *
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,*cape-universaln*
>
> it appears at /sys/class/pwm/pwmchip*4*/pwm0!
>
> Is there a way the pwm system can tell you which headers they are attached
> to?
>
> --Mark
>
> On Monday, February 8, 2016 at 6:42:11 PM UTC-5, RobertCNelson wrote:
>>
>> On Mon, Feb 8, 2016 at 5:36 PM, Mark A. Yoder 
>> wrote:
>> > Well  /sys/class/pwm/pwmchip2/pwm0 worked!  Thanks...
>> >
>> > So given the pin name (P9_14 for example) how do I find the pwm path?
>> (I'm
>> > trying to port bonescript to Jessie.)
>>
>> For the pwm, I think it's load order (scary)  not sure if we can
>> for an alias in the dt..
>>
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

attached . . .but I figure you all knew that already ;)

On Mon, Feb 8, 2016 at 5:13 PM, William Hermans  wrote:

> @Mark,
>
> Yes,and no.
>
> No, in that there is no way to differentiate which header the peripheral
> is physically attacked to.
>
> Yes, in that device tree "defines" usually define a device module as
> something similar to:
>
> device_tree_friendly_name@
>
> In other words, we should be able to extrapolate which device module, and
> pins are used based on their base address. There is also a place in a
> systems directory structure that sysfs uses the base address as part of the
> path for the device . . .but I can not recall exactly where that is :/
>
>
> On Mon, Feb 8, 2016 at 4:56 PM, Mark A. Yoder 
> wrote:
>
>> Well, they move around depending on which dts you boot under.  P9_14
>> appears at /sys/class/pwm/pwmchip*2*/pwm0 with
>> *cat $SLOTS *
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,*univ-emmc*
>>
>> But if you use:
>> *cat $SLOTS *
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,*cape-universaln*
>>
>> it appears at /sys/class/pwm/pwmchip*4*/pwm0!
>>
>> Is there a way the pwm system can tell you which headers they are
>> attached to?
>>
>> --Mark
>>
>> On Monday, February 8, 2016 at 6:42:11 PM UTC-5, RobertCNelson wrote:
>>>
>>> On Mon, Feb 8, 2016 at 5:36 PM, Mark A. Yoder 
>>> wrote:
>>> > Well  /sys/class/pwm/pwmchip2/pwm0 worked!  Thanks...
>>> >
>>> > So given the pin name (P9_14 for example) how do I find the pwm path?
>>> (I'm
>>> > trying to port bonescript to Jessie.)
>>>
>>> For the pwm, I think it's load order (scary)  not sure if we can
>>> for an alias in the dt..
>>>
>>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

You know this makes me cringe when I think about it. But perhaps Bonescript
needs it's own dt overlay ? One needs consistency when using a certain
thing, and based on what I'm seeing, you're not guaranteed that. What's
more, there is no real way you can expect this either, considering
difference capes do different things.

*Or* there needs to be a mechanism in device tree, that populates some file
somewhere, that lets the users know what's going on. This *can* be done via
/dev/mem/ and using mmap() to read out register data for every pin, and
perihperal to see what state it's in but man . . . that'd be an awful lot
of work to do, just to port bonescript . . .

On Mon, Feb 8, 2016 at 5:36 PM, Mark A. Yoder 
wrote:

> Yup, here's the mappings depending on which dts file is used:
>
> # universaln
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 ->
> ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 ->
> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 ->
> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 ->
> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 ->
> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
>
>
> # cape-emmc
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 ->
> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 ->
> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 ->
> ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip2
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 ->
> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4
> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 ->
> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
>
> Yes, the addresses are there, so I need to find a place that maps the
> addresses to the header pin numbers.
>
> --Mark
>
> On Monday, February 8, 2016 at 6:42:11 PM UTC-5, RobertCNelson wrote:
>>
>> On Mon, Feb 8, 2016 at 5:36 PM, Mark A. Yoder 
>> wrote:
>> > Well  /sys/class/pwm/pwmchip2/pwm0 worked!  Thanks...
>> >
>> > So given the pin name (P9_14 for example) how do I find the pwm path?
>> (I'm
>> > trying to port bonescript to Jessie.)
>>
>> For the pwm, I think it's load order (scary)  not sure if we can
>> for an alias in the dt..
>>
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

>
> *We could also add the alias to the am33xx.dtsi:*
>
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20
> *
>
> * like:*
>
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee
> *
>

Yeah, but would that help with the given problem with what Mark is
currently facing ? Look at the two capes, and base address, and mode each
pwm chip is placed in.

On Mon, Feb 8, 2016 at 5:50 PM, Robert Nelson 
wrote:

> On Mon, Feb 8, 2016 at 6:36 PM, Mark A. Yoder 
> wrote:
> > Yup, here's the mappings depending on which dts file is used:
> >
> > # universaln
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 ->
> > ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 ->
> > ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 ->
> > ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 ->
> > ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 ->
> > ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
> >
> >
> > # cape-emmc
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 ->
> > ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 ->
> > ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 ->
> > ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip2
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 ->
> > ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4
> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 ->
> > ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
> >
> > Yes, the addresses are there, so I need to find a place that maps the
> > addresses to the header pin numbers.
>
> We could also add the alias to the am33xx.dtsi:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20
>
> like:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

[William Hermans]

Mark,
Quite honestly, I have no idea how both of those capes you're showing data
on work. Each peripheral module between the two have different base
addresses. Offset width, I can understand being different, but device
module base address ? . . .I'm confused.

On Mon, Feb 8, 2016 at 5:58 PM, William Hermans  wrote:

> *We could also add the alias to the am33xx.dtsi:*
>>
>> *
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20
>> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20>*
>>
>> * like:*
>>
>> *
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee
>> <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee>*
>>
>
> Yeah, but would that help with the given problem with what Mark is
> currently facing ? Look at the two capes, and base address, and mode each
> pwm chip is placed in.
>
> On Mon, Feb 8, 2016 at 5:50 PM, Robert Nelson 
> wrote:
>
>> On Mon, Feb 8, 2016 at 6:36 PM, Mark A. Yoder 
>> wrote:
>> > Yup, here's the mappings depending on which dts file is used:
>> >
>> > # universaln
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 ->
>> > ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 ->
>> > ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 ->
>> > ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 ->
>> > ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 ->
>> > ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
>> >
>> >
>> > # cape-emmc
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 ->
>> > ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 ->
>> > ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 ->
>> > ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip2
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 ->
>> > ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4
>> > # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 ->
>> > ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6
>> >
>> > Yes, the addresses are there, so I need to find a place that maps the
>> > addresses to the header pin numbers.
>>
>> We could also add the alias to the am33xx.dtsi:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20
>>
>> like:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee
>>
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

OK, so assuming your issue doing the above - only works as root, and you'd
like it to work as a regular user too . . .

You need to figure out how the Adafruit_BBIO library accesses the pins, and
go from there. Does it use sysfs, or /dev/mem/ ?

If the library uses sysfs. Then I would think you'd need to create a udev
rule to add a group to your desired asset. In order for the pin path to
have the appropriate permissions every time that asset is enabled through
pinctrl. Which in your case I'd assume every reboot only.

A bit of advice however . . . if this library uses /dev/mem/ to access the
pins . . . **DO NOT** adjust permissions on /dev/mem/. As that could give
anyone in that group direct access to any physical address on the CPU. In
short. they could pretty much do anything they'd want.

If you're confident you can control access to the board, my concern above
is less of a problem. As I tend to look at security issues of this nature
as if one is already compromised at a regular user level. If the board is
rooted . . . well then . . .heh it's moot.

On Mon, Feb 8, 2016 at 3:48 PM, John Stoner  wrote:

> and when I do the above as root it blinks as it should.
>
> On Mon, Feb 8, 2016 at 4:44 PM John Stoner  wrote:
>
>> (env) app@beaglebone:/opt/reactor_controller/src$ uname -a
>> Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l
>> GNU/Linux
>> (env) app@beaglebone:/opt/reactor_controller/src$ cat /etc/dogtag
>> BeagleBoard.org Debian Image 2015-03-01
>>
>> (env) app@beaglebone:/opt/reactor_controller/src$ python
>> Python 2.7.3 (default, Mar 14 2014, 17:55:54)
>> [GCC 4.6.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import Adafruit_BBIO.PWM as PWM
>> >>> PWM.start('P8_13', 33, 4) # this turns the light on steady
>> >>> PWM.stop('P8_13') # this turns it off
>> >>> PWM.cleanup()
>>
>> I am using the latest Adafruit_BBIO library, source available at
>>
>> https://github.com/adafruit/adafruit-beaglebone-io-python
>>
>> Anything else you need?
>>
>> On Mon, Feb 8, 2016 at 4:39 PM William Hermans  wrote:
>>
>>> *I call my success partial because I can get a test LED to turn on, but
>>>> I can't get it to flash using PWM.*
>>>>
>>>> *Any ideas why that would be?*
>>>>
>>>
>>> No . . . Because you've given no pertinent details. We'd need to know a
>>> few things, but kernel version used, method used for attempting to control
>>> said PWM, code, etc. All will help. So, if you want help, help us, help you.
>>>
>>> On Mon, Feb 8, 2016 at 11:33 AM,  wrote:
>>>
>>>> This is John, the guy with the question Drew to above on the Adafruit
>>>> board. (Thanks Drew for starting this conversation here.)
>>>>
>>>> The problem is, this is part of a commercial application. My code will
>>>> be reading and writing to the GPIOs and doing various things, communicating
>>>> data to remote systems... I anticipate adding a fair bit of complexity. I'd
>>>> hate to make a bug that blew something important away or something like
>>>> that. I am generally leery of unnecessary privilege escalation.
>>>>
>>>> So I could
>>>>
>>>> - sudo my entire application, which would be the same as running as
>>>> root;
>>>> - partition my application and have it invoke the code that interfaces
>>>> directly to the GPIOs as sudo in some way (via shell?);
>>>> - go by way of the PRUs;
>>>> - change permissions;
>>>> - some other way.
>>>>
>>>> I did have partial success changing the permissions on relevant files,
>>>> ala
>>>>
>>>> https://github.com/cnobile2012/RobotControl/tree/master/contrib
>>>>
>>>> which uses udev to set up permissions (not that I understand udev
>>>> either.)
>>>>
>>>> I call my success partial because I can get a test LED to turn on, but
>>>> I can't get it to flash using PWM.
>>>>
>>>> Any ideas why that would be?
>>>>
>>>> On Sunday, February 7, 2016 at 10:00:01 AM UTC-6, Mike Bell wrote:
>>>>>
>>>>> On 02/06/2016 12:51 AM, Brian Anderson wrote:
>>>>>
>>>>>
>>>>> My comments are really to do with what I perceive as best practices on
>>>>> how one would approach 

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

It seems as though their using sysfs:
https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_pwm.c#L68-L77

On Mon, Feb 8, 2016 at 6:23 PM, William Hermans  wrote:

> OK, so assuming your issue doing the above - only works as root, and you'd
> like it to work as a regular user too . . .
>
> You need to figure out how the Adafruit_BBIO library accesses the pins,
> and go from there. Does it use sysfs, or /dev/mem/ ?
>
> If the library uses sysfs. Then I would think you'd need to create a udev
> rule to add a group to your desired asset. In order for the pin path to
> have the appropriate permissions every time that asset is enabled through
> pinctrl. Which in your case I'd assume every reboot only.
>
> A bit of advice however . . . if this library uses /dev/mem/ to access the
> pins . . . **DO NOT** adjust permissions on /dev/mem/. As that could give
> anyone in that group direct access to any physical address on the CPU. In
> short. they could pretty much do anything they'd want.
>
> If you're confident you can control access to the board, my concern above
> is less of a problem. As I tend to look at security issues of this nature
> as if one is already compromised at a regular user level. If the board is
> rooted . . . well then . . .heh it's moot.
>
> On Mon, Feb 8, 2016 at 3:48 PM, John Stoner  wrote:
>
>> and when I do the above as root it blinks as it should.
>>
>> On Mon, Feb 8, 2016 at 4:44 PM John Stoner  wrote:
>>
>>> (env) app@beaglebone:/opt/reactor_controller/src$ uname -a
>>> Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015
>>> armv7l GNU/Linux
>>> (env) app@beaglebone:/opt/reactor_controller/src$ cat /etc/dogtag
>>> BeagleBoard.org Debian Image 2015-03-01
>>>
>>> (env) app@beaglebone:/opt/reactor_controller/src$ python
>>> Python 2.7.3 (default, Mar 14 2014, 17:55:54)
>>> [GCC 4.6.3] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import Adafruit_BBIO.PWM as PWM
>>> >>> PWM.start('P8_13', 33, 4) # this turns the light on steady
>>> >>> PWM.stop('P8_13') # this turns it off
>>> >>> PWM.cleanup()
>>>
>>> I am using the latest Adafruit_BBIO library, source available at
>>>
>>> https://github.com/adafruit/adafruit-beaglebone-io-python
>>>
>>> Anything else you need?
>>>
>>> On Mon, Feb 8, 2016 at 4:39 PM William Hermans 
>>> wrote:
>>>
>>>> *I call my success partial because I can get a test LED to turn on, but
>>>>> I can't get it to flash using PWM.*
>>>>>
>>>>> *Any ideas why that would be?*
>>>>>
>>>>
>>>> No . . . Because you've given no pertinent details. We'd need to know a
>>>> few things, but kernel version used, method used for attempting to control
>>>> said PWM, code, etc. All will help. So, if you want help, help us, help 
>>>> you.
>>>>
>>>> On Mon, Feb 8, 2016 at 11:33 AM,  wrote:
>>>>
>>>>> This is John, the guy with the question Drew to above on the Adafruit
>>>>> board. (Thanks Drew for starting this conversation here.)
>>>>>
>>>>> The problem is, this is part of a commercial application. My code will
>>>>> be reading and writing to the GPIOs and doing various things, 
>>>>> communicating
>>>>> data to remote systems... I anticipate adding a fair bit of complexity. 
>>>>> I'd
>>>>> hate to make a bug that blew something important away or something like
>>>>> that. I am generally leery of unnecessary privilege escalation.
>>>>>
>>>>> So I could
>>>>>
>>>>> - sudo my entire application, which would be the same as running as
>>>>> root;
>>>>> - partition my application and have it invoke the code that interfaces
>>>>> directly to the GPIOs as sudo in some way (via shell?);
>>>>> - go by way of the PRUs;
>>>>> - change permissions;
>>>>> - some other way.
>>>>>
>>>>> I did have partial success changing the permissions on relevant files,
>>>>> ala
>>>>>
>>>>> https://github.com/cnobile2012/RobotControl/tree/master/contrib
>>>>>
>>>>> which uses udev to set up permissions (not that I unders

Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *Could you tell me where I can find it?*
>


http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide

You can also read through the code . . . but I will mention the last time I
was reading through the code, and reading up on this API, the amount of
memory used is not limited to 8k or whatever is default as shipped.

Another interesting thing I realized, is that mmap() can map any register
through /dev/mem/ so should be easy to access the PRU scratchpad from
"userspace". Meaning, you still have the latency from Linux to memory, but
PRU accesses should be much faster. Not to mention having the ability of
"broadsiding" from one PRU to the other . . .granted, I'm having a hard
time tryign to think of a usecase where that might be useful . . .

On Wed, Feb 10, 2016 at 2:15 PM, Bill Gray  wrote:

> Charles,
>
> Thanks so much for a definitive answer to this question!!!
>
> Perhaps even more than the answer, I am fascinated by the account you give
> of how you know this to be the case!
>
> I would like to have a better understanding of kernel drivers and DMA
> memory.  As an educational exercise I would like dig through the PRU kernel
> driver and see this code for myself?
>
> Could you tell me where I can find it?
>
> Thank you very much.
>
> Bill
>
> On Wed, Feb 10, 2016 at 12:15 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> If you dig through the user-mode uio_pruss code, you will see that the
>> PRU itself, the PRU memory and control registers, and the large shared
>> buffer is all accessed via a mmap on the /dev/uio_pruss* device.
>>
>> If you dig in the PRU kernel driver, you will see the dram shared
>> buffer is allocated and handled as DMA memory.  The
>> dma_alloc_coherent() call used to allocate the memory grabs a
>> physically contiguous chunk, provides physical and virtual addresses,
>> and sets the page caching flags as needed for the architecture.
>>
>> On 2/10/2016 9:07 AM, Tyler Turcotte wrote:
>> >  I have been using the BeagleBone PRU and have been accessing and
>> mapping
>> > memory this way and thus far it seems as though it is one contiguous
>> > address.  I am relatively new to Beaglebone so maybe one of the more
>> > experienced may want to step in on this one.
>> >
>> > Once I have used prussdrv_get_phys_addr to get the physical address it
>> > seems to store to one contiguous memory and is limited to 8mb.
>> >
>> > I believe it is allocated contiguous from uio_pruss as well.
>> >
>> >
>> > On Friday, February 5, 2016 at 7:33:59 PM UTC-5, Bill Gray wrote:
>> >>
>> >> Hi,
>> >>
>> >> I've got PRU0 of my BBB pulling in 12 Bytes of data from a ADC with a
>> >> sampling frequency of 31250hz.
>> >>
>> >> I want to stash all of this data in an array that lives in DDR
>> memory.  I
>> >> would like to make the array 0x4000 bytes (16kB) large.  This would
>> give me
>> >> 1365 12 byte records and about 43ms of data to play with.
>> >>
>> >> I'm currently using prussdrv_map_extmem() to hook me up with the DDR
>> >> memory.  It provides me with a memory block that is 256kB, so I have
>> plenty
>> >> of room.
>> >>
>> >> The question I have is... can I count on the physical address in this
>> >> 256kB block of memory to be contiguous?
>> >>
>> >> I'm pretty new to linux memory management, but I see that the "page
>> size"
>> >> is only 4kB... so I imagine that the virtual memory system might chop
>> my
>> >> 256kB block up into bits which might not necessarily have contiguous
>> >> addresses.
>> >>
>> >> If I can count on contiguous addresses, this radically simplifies the
>> >> memory access code in the PRU.  If I can't... well, then I can't, and
>> I've
>> >> got to figure something else out.
>> >>
>> >> When I run experiments I see that the physical addresses are
>> contiguous,
>> >> but are they guaranteed to be? or has this just been "lucky"?
>> >>
>> >> Thanks,
>> >>
>> >> Bill
>> >>
>> >>
>> >>
>> >
>>
>>
>> --
>> Charles Steinkuehler
>> char...@steinkuehler.net
>>
>> --
>> 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/N47C7-WdsZE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Bill Gray
> Velkess
> 415 407 7356
>
> --
> 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.
> 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 s

Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

I would recommend staying away from remoteproc and rpmsg at least until
it's out of experimental.

On Wed, Feb 10, 2016 at 2:44 PM, Soapy Smith 
wrote:

> Bill, I have been studying this myself, it is complex, and the learning
> curve looks to be pretty steep to a newbie embedded programmer.
> Here's as clear of an explanation as I have been able to find:
>
> http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg
>
>>
> I've got the PRU Cape and that combined with the Debian distro and version
> 4 kernel it is pretty easy to run the example code using the kernel
> driver.  Understanding what is going on is another story.  If you go to
> exploringbeaglebone.com and look in the chapter "Extra Content Linux
> Kernel Programming" there are 3 articles which guide you through the
> workings of kernel drivers.
>
> Regards,
> Greg
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Read voltage from ADC using an external power supply

[William Hermans]

>
> *I have a new BBB. I'm trying to read voltages from a DC power supply. I'm
> having trouble doing so. I connected the output from the power supply to
> AIN0, and the ground from the power supply to the ADC_GND, and tried to run
> the code, but the voltages that I'm reading doesn't make sense.*
>

What voltage is the external DC power supply ? Unless the dc power supply
voltage is 1.8v then voltage = value * 1.8  will not make sense.

How this works is voltage = value * scale, where scale is the external
voltage to be measured. So for example if your external powr supply is 12v,
then scale would be 12.0. Just to make sure it is understood however, the
input voltage to the ADC pins must never exceed 1.8v, or you risk at
minimum burning out that pin.

On Wed, Feb 10, 2016 at 2:54 PM, Chelsea Orefice  wrote:

> Hi All,
>
> I have a new BBB. I'm trying to read voltages from a DC power supply. I'm
> having trouble doing so. I connected the output from the power supply to
> AIN0, and the ground from the power supply to the ADC_GND, and tried to run
> the code, but the voltages that I'm reading doesn't make sense.
>
> So I went back to the basic, and just ran the code without plugging
> anything in, and yet the voltage value I'm printing says 1.6 instead of 0.
> Below shows the code, which I got from adafruit. I'm aware that I'm not
> supposed to connect BBB ADC to anything above 1.8V or below 0V, which I
> don't believe I have.
>
> import Adafruit_BBIO.ADC as ADC
>> ADC.setup()
>> value = ADC.read("P9_40")
>> voltage = value * 1.8
>> print (voltage)
>
>
>
> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/adc
>
> I've also been reading somewhere that I may have to enable the ADC before
> I can read it??
>
> Help?
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Read voltage from ADC using an external power supply

[William Hermans]

>
> *What voltage is the external DC power supply ? Unless the dc power supply
> voltage is 1.8v then voltage = value * 1.8  will not make sense.*
>

Sorry this is wrong. Values read out of the ADC are in range of 0 to 4095.
so . . .

voltage = ( value / 4096 ) * scale

On Wed, Feb 10, 2016 at 3:05 PM, William Hermans  wrote:

> *I have a new BBB. I'm trying to read voltages from a DC power supply. I'm
>> having trouble doing so. I connected the output from the power supply to
>> AIN0, and the ground from the power supply to the ADC_GND, and tried to run
>> the code, but the voltages that I'm reading doesn't make sense.*
>>
>
> What voltage is the external DC power supply ? Unless the dc power supply
> voltage is 1.8v then voltage = value * 1.8  will not make sense.
>
> How this works is voltage = value * scale, where scale is the external
> voltage to be measured. So for example if your external powr supply is 12v,
> then scale would be 12.0. Just to make sure it is understood however, the
> input voltage to the ADC pins must never exceed 1.8v, or you risk at
> minimum burning out that pin.
>
> On Wed, Feb 10, 2016 at 2:54 PM, Chelsea Orefice 
> wrote:
>
>> Hi All,
>>
>> I have a new BBB. I'm trying to read voltages from a DC power supply. I'm
>> having trouble doing so. I connected the output from the power supply to
>> AIN0, and the ground from the power supply to the ADC_GND, and tried to run
>> the code, but the voltages that I'm reading doesn't make sense.
>>
>> So I went back to the basic, and just ran the code without plugging
>> anything in, and yet the voltage value I'm printing says 1.6 instead of 0.
>> Below shows the code, which I got from adafruit. I'm aware that I'm not
>> supposed to connect BBB ADC to anything above 1.8V or below 0V, which I
>> don't believe I have.
>>
>> import Adafruit_BBIO.ADC as ADC
>>> ADC.setup()
>>> value = ADC.read("P9_40")
>>> voltage = value * 1.8
>>> print (voltage)
>>
>>
>>
>> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/adc
>>
>> I've also been reading somewhere that I may have to enable the ADC before
>> I can read it??
>>
>> Help?
>>
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

Hi Soapy,

Yeah John always seems to take things personally, or out of context. I have
no problem what so ever with anyone using whatever they want. Including the
OP. My comment were merely to point out that remoteproc / rpmsg are not
finished, have known issues, and are a pain in the backside to initially
get working.

So for someone using prussdrv, it is probably a bad idea to even start
thinking about using remoteproc / rpmsg. Unless they're just experimenting
. . . where then it could be a good learning experience I suppose. Me . . .
I'd rather something were fully functional and well documented before I
invest my time into it. remoteproc is neither of these.

On Wed, Feb 10, 2016 at 3:42 PM, Soapy Smith 
wrote:

> remoteproc definitely has some bad behavior.  But what I am doing is just
> as experimental, and no motors (all data transfer) involved.
>
> What is currently considered a reliable methodology for getting the most
> out of the PRUs?
> Also, what about C versus assembler?  Will C alone suffice, or is there
> real need to do some assembler?
> I've found that there are actually two different assemblers, the older
> pasm (apparently no longer supported), and the assembler part of clpru.
> If you are just starting out in PRU work, should pasm even be considered?
>
> Regards,
> Greg
>
> On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans wrote:
>>
>> I would recommend staying away from remoteproc and rpmsg at least until
>> it's out of experimental.
>>
>>
>> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *remoteproc definitely has some bad behavior.  But what I am doing is just
> as experimental, and no motors (all data transfer) involved.*
>
> *What is currently considered a reliable methodology for getting the most
> out of the PRUs?*
>

Whatever works for you. Me, I opted for C in Linux of course, and ASM for
the PRU's because it is the best documented. But I've experimented with it
all including attempting remoteproc . . .

The assembler I decided to use was the one included with the
am335x_pru_package. I have not really spend a lot of time writing PRU
assembly yet, but was reading up on the registers, etc, and then got busy
with other things. But I did start to understand the prussdrv driver, and
API set . . .

Anyway, pick something, and go with it. If you ask me the old way of using
the PRU is the best way to go right now. Later, when remoteproc / rpmsg is
mainline, and perhaps well documented. Then I personally plan on giving it
a more serious look. Right now, I consider it a toy . . .

On Wed, Feb 10, 2016 at 3:47 PM, William Hermans  wrote:

> Hi Soapy,
>
> Yeah John always seems to take things personally, or out of context. I
> have no problem what so ever with anyone using whatever they want.
> Including the OP. My comment were merely to point out that remoteproc /
> rpmsg are not finished, have known issues, and are a pain in the backside
> to initially get working.
>
> So for someone using prussdrv, it is probably a bad idea to even start
> thinking about using remoteproc / rpmsg. Unless they're just experimenting
> . . . where then it could be a good learning experience I suppose. Me . . .
> I'd rather something were fully functional and well documented before I
> invest my time into it. remoteproc is neither of these.
>
> On Wed, Feb 10, 2016 at 3:42 PM, Soapy Smith 
> wrote:
>
>> remoteproc definitely has some bad behavior.  But what I am doing is just
>> as experimental, and no motors (all data transfer) involved.
>>
>> What is currently considered a reliable methodology for getting the most
>> out of the PRUs?
>> Also, what about C versus assembler?  Will C alone suffice, or is there
>> real need to do some assembler?
>> I've found that there are actually two different assemblers, the older
>> pasm (apparently no longer supported), and the assembler part of clpru.
>> If you are just starting out in PRU work, should pasm even be considered?
>>
>> Regards,
>> Greg
>>
>> On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans
>> wrote:
>>>
>>> I would recommend staying away from remoteproc and rpmsg at least until
>>> it's out of experimental.
>>>
>>>
>>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

[William Hermans]

I've often given thought to running two processes in this context, and
using inter process communications( shared memory seemed the most
attractive to me ). How I envisioned this though, is that you have one
process running as root, that is the main "supervisor" part of the
application. Then a regular user application that makes requests via
whatever shared memory mechanism that get used.

I think the main benefit of an application of this sort is that there is
kind of a partition between privileged commands, and non privileged users.
With the ability of having very fine grained control.

Anyway, I only bring this up because the last post kind of reminds me of
what I mention above, and actually could be made to work as a "userland"
driver.

On Wed, Feb 10, 2016 at 4:02 PM,  wrote:

> You might want think more about this then the peep hole approach.
>
> Rather then running things in userland and relying on user id isolation; a
> better way is to write a kernel driver that exposes a very specific and
> limited interface. GPIOs are directly toggling hardware which means there
> are
> more then thing simple "privileges" -
> - Can the pins be reconfigured to conflict (i.e. BBB is an Output and the
> thing connected is an output) and is the hardware tolerant of that or will
> things die?
>
> - Is there anything bad that will happen if the pin floats (i.e. a normally
> output pin is switched to an input)? Will it pickup noise and let things go
> crazy?
>
> Just merely changing permissions can leave a dangling problem.
>
> On Monday, February 08, 2016 10:33:03 j...@forelight.com wrote:
> > This is John, the guy with the question Drew to above on the Adafruit
> > board. (Thanks Drew for starting this conversation here.)
> >
> > The problem is, this is part of a commercial application. My code will be
> > reading and writing to the GPIOs and doing various things, communicating
> > data to remote systems... I anticipate adding a fair bit of complexity.
> I'd
> > hate to make a bug that blew something important away or something like
> > that. I am generally leery of unnecessary privilege escalation.
> >
> > So I could
> >
> > - sudo my entire application, which would be the same as running as root;
> > - partition my application and have it invoke the code that interfaces
> > directly to the GPIOs as sudo in some way (via shell?);
> > - go by way of the PRUs;
> > - change permissions;
> > - some other way.
> >
> > I did have partial success changing the permissions on relevant files,
> ala
> >
> > https://github.com/cnobile2012/RobotControl/tree/master/contrib
> >
> > which uses udev to set up permissions (not that I understand udev
> either.)
> >
> > I call my success partial because I can get a test LED to turn on, but I
> > can't get it to flash using PWM.
> >
> > Any ideas why that would be?
> >
> > On Sunday, February 7, 2016 at 10:00:01 AM UTC-6, Mike Bell wrote:
> > > On 02/06/2016 12:51 AM, Brian Anderson wrote:
> > >
> > >
> > > My comments are really to do with what I perceive as best practices on
> how
> > > one would approach building systems that are "security conscious".  Of
> > > course, "convenience" may direct us in different directions during
> > > development.  I am not sure what you are trying to imply by "safe" as
> in
> > > protecting the GPIOs from misuse.  I don't actually see any way to
> > > accomplish that.  What I do think one can do is to be aware of security
> > > considerations and not unnecessarily present an attack surface that can
> > > compromise the entire system.
> > >
> > >
> > > *Using sudo seems much less secure as it exposes the application to
> being
> > >
> > >>> exploited for security flaws. And since the application is running as
> > >>> root,
> > >>> it has access to everything.*
> > >>
> > >> So, we have a device on a system that can potentially cause physical
> > >> damage to external hardware when something like a wrong GPIO state is
> > >> toggled, or such. How would sudo be less secure in this context?
> > >
> > > It wouldn't.  And that is not my point.  I am not talking about how to
> > > protect the GPIOs from "bad behaved" programs that are "trusted" as
> > > implied
> > > by the fact that they are running as a normal user in the group that
> has
> > > access to those GPIOs.  If an application is trusted (is a member of
> the
> > > appropriate group or for that matter can sudo), it is a hopeless task
> to
> > > protect the GPIOs from misuse.  What I am trying to point out is that
> > > running an app as "root" (sudo, set uid, whatever) exposes a security
> > > attack vector...a vector that has access to _all_ system resources.  I
> > > would claim that it is an unnecessary exposure...from a security point
> of
> > > view.  YMMV when it comes to "convenience".
> > >
> > >> In fact under certain conditions it would be less safe using groups.
> > >
> > > How would an application running at a non-root level using groups to
> > > access protected resources be less "saf

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *William, what are you talking about? Why would I take what you say
> personally? You make these blanket statements about a technology you say
> you don’t know how to use and recommend that everyone else not use this
> technology. If you want to stay with a dead technology, that is your call,
> but there is no reason for anyone to stay away from RemoteProc/RPMSG.
> Manufacturers other than TI have embraced this technology which open up a
> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. Yes,
> I know you told me you have no interest in the x15 so this is probably not
> important to you and I respect that. *
>

So, using something consistent , that is well documented, and has been
proven to work over the last several years does not make it "dead tech". It
makes it something that actually works for many people. No one cares what
TI adopts, except perhaps you, and TI. People care what works, with the
least amount of resistance.

So hey lets put the squash on this right now. Why don't you write us some
code in the next day or two that blinks the USR leds in some kind of
pattern that proves the remoteproc / rpmsg is actually functional / usable.
As no one cares if you can write 100 "hello world " messages into
/var/log/messages . . . I can do that with a bash script and no PRU . . .

You do that, and I'll concede that remoteproc is at least semi useful.


On Wed, Feb 10, 2016 at 4:57 PM, John Syne  wrote:

> William, what are you talking about? Why would I take what you say
> personally? You make these blanket statements about a technology you say
> you don’t know how to use and recommend that everyone else not use this
> technology. If you want to stay with a dead technology, that is your call,
> but there is no reason for anyone to stay away from RemoteProc/RPMSG.
> Manufacturers other than TI have embraced this technology which open up a
> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. Yes,
> I know you told me you have no interest in the x15 so this is probably not
> important to you and I respect that.
>
> Soapy, I use the drivers from Starterware and adapt them to work on the
> PRU, so I always use the C compiler. There is a github repo were several of
> the Starterware drivers have been ported to the PRU. This will save you a
> bunch of time.
>
> Regards,
> John
>
>
>
>
> On Feb 10, 2016, at 2:47 PM, William Hermans  wrote:
>
> Hi Soapy,
>
> Yeah John always seems to take things personally, or out of context. I
> have no problem what so ever with anyone using whatever they want.
> Including the OP. My comment were merely to point out that remoteproc /
> rpmsg are not finished, have known issues, and are a pain in the backside
> to initially get working.
>
> So for someone using prussdrv, it is probably a bad idea to even start
> thinking about using remoteproc / rpmsg. Unless they're just experimenting
> . . . where then it could be a good learning experience I suppose. Me . . .
> I'd rather something were fully functional and well documented before I
> invest my time into it. remoteproc is neither of these.
>
> On Wed, Feb 10, 2016 at 3:42 PM, Soapy Smith 
> wrote:
>
>> remoteproc definitely has some bad behavior.  But what I am doing is just
>> as experimental, and no motors (all data transfer) involved.
>>
>> What is currently considered a reliable methodology for getting the most
>> out of the PRUs?
>> Also, what about C versus assembler?  Will C alone suffice, or is there
>> real need to do some assembler?
>> I've found that there are actually two different assemblers, the older
>> pasm (apparently no longer supported), and the assembler part of clpru.
>> If you are just starting out in PRU work, should pasm even be considered?
>>
>> Regards,
>> Greg
>>
>> On Wednesday, February 10, 2016 at 4:49:49 PM UTC-5, William Hermans
>> wrote:
>>>
>>> I would recommend staying away from remoteproc and rpmsg at least until
>>> it's out of experimental.
>>>
>>>
>>>
>> --
>> 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.
>> 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 f

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *Hi William, please see the above.  I have the PRU Cape, but I haven't got
> this far in the labs.  The other labs with remoteproc and other associated
> modules works so far.*
>

Hi Soapy,

Thanks, but I have been aware of that guide for some time now. The example,
blinks a PRU cape LED, not one of the USR leds on beaglebone. That's
problem #1( not everyone wants to buy yet more hardware to explore an
experimental concept).

Problem #2 the guide is based on code composer studio. If you can not see
the problem with that, then chances are I will probably never convince you
it is a problem. For many of us though, a requirement of using CCS is a
major problem.

Problem #3, there is no in depth code explanation, just setup "do x.y.z
exact steps", and thats it. So, for me, no code explanation is not really
the problem. The problem is no one bothers explaining how the rpmsg
mechanism works in conjunction with our specific hardware. That is to say,
many of us already know how the hardware works, but how do "WE" control the
hardware through this software ? 1 or 2 *good* examples would go a very
long ways here.

Problem #4, as ybeagle3 mentions above, performance. If we're wanting to
use a PRU or two, chances are pretty good we want / need performance.
Granted, there are probably ways to tweak rpmsg, but at some point one has
to wonder why even bother.

Problem #5, and possibly the biggest turn off for me aside from very little
documentation. This software is experimental, incomplete, and has no proven
track record. Which means, no one knows how stable the software is right
now. Anyone saying they know if full of it. While on the other hand, the
UIO PRU based software has been around a good long time, is proven, and is
probably in many commercial grade applications. Not to mention scientific
applications, etc.

Anyway, I still think remoteproc / rpmsg is a really cool idea - In
concept. In reality though it has a very long ways to go, and no telling if
it will ever make it passed the experimental stage. Then if it does, how
long will it take ?

Another thing. This hardware( beaglebone ) is an open sourced design. So
who in their right mind thought it would be a good idea to demonstrate such
a cool idea using a closed source toolchain / toolset ? Oh, right. The same
company who says they do not support the PRU's to begin with . . .

Do also keep in mind, that I actualy am PRO TI . . .

On Wed, Feb 10, 2016 at 6:22 PM,  wrote:

> Not to add add data points to the flames but -
>
> That example code in that link works fine. Was able to use that sample
> code to
> build a rpmsg simulator for other hw using the PRU. The PRU firmware
> creates 2
> rpmsg channels that gets messages sent between then. Setup is:
> Kernel driver A is a I2C driver attaches to one rpmsg channel. It reads
> data
> from the I2C channel and forwards it to the PRU using that rpmsg channel.
>
> Kernel driver B is rpmsg/IIO driver that attaches to the other rpmsg
> channel
> and sends out IIO data based on the rpmsg packets from the PRU.
>
> Having used both UIO_pruss and remote proc/rpmsg -
> - remoteproc/rpmsg is a lot easier to use with standard kernel interfaces
> (i.e. tying in I2C, etc).
> - remoteproc/rpmsg really works better with the C compiler which adds a
> layer
> of overhead compared to pure ASM. The UIO_pruss interface gives a raw
> processor which simplifies pure ASM code.
> - Passing large amounts of data using rpmsg could have considerable
> overhead.
> For example, I would just do just pure remoteproc or stay with UIO for my
> PRUSS driven video capture code. But for slower data rates, rpmsg could
> simplify things as the buffer management/interrupt/driver attachment code
> is
> done for you.
> - Just keep in mind resources are limited on the PRUSS and accessing
> resources
> outside of the PRUSS can be expensive.
>
>
>
> On Wednesday, February 10, 2016 16:37:12 Soapy Smith wrote:
> >
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_B
> > linking_LEDs_with_RPMsg_from_Linux_User_Space
> >
> > Hi William, please see the above.  I have the PRU Cape, but I haven't got
> > this far in the labs.  The other labs with remoteproc and other
> associated
> > modules works so far.
> >
> > Regards,
> > Greg
> >
> > On Wednesday, February 10, 2016 at 7:25:27 PM UTC-5, William Hermans
> wrote:
> > > *William, what are you talking about? Why would I take what you say
> > >
> > >> personally? You make these blanket statements about a technology you
> say
> > >> you don’t know how to use and recommend that everyone else not use
> this
> > >> technology. If you want to stay with a dead technology, that is your
> >

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *Hi Greg,*
>
> *I’ve pointed this out to William before, but he doesn’t like to use
> CCSV6, so you are wasting your time ;-)*
>

Actually John, I was well aware of that guide long before you ever
mentioned it.

*Hi William,*
>
> *By dead technology, I mean there is no further development expected. All
future efforts will focus on RemoteProc/RPMSG. For someone looking to start
development with remote processor communications, why spend the time
learning a technology that isn’t going anywhere? Rather, spend time
learning to use a technology that will be enhanced and supported in future
kernels. *

That's not for you, or even TI to decide. That is for the community to
decide. Especially since TI has pretty much refused to support the PRU
since day one. As for what who does when. You seem to conveniently
selectively reading what I write in my post. As I've said like 500 times
already. I do not care what people use. I will however come into a post
like this where the OP originally posted in relation to something
am335x_pru_package specific. and you or anyone for that matter jumps in
suggesting to use remoteproc / rpmsg. Why ?

Because obviously this person has a time investment into the
am335x_pru_package already. I'd like to try and save them from chasing yet
another rabbit down yet another useless rabbit hole. As many people here
use this software in products, school projects, or just something very
serious in the hobbyist circles. They do not care what you think about some
experimental bit of software that has yet to be proven . . .

You're like TJP or whatever his name. Everything is a nail, except instead
of prusio, or whatever it is, remoteproc is your hammer.


On Wed, Feb 10, 2016 at 7:22 PM, John Syne  wrote:

> Hi Greg,
>
> I’ve pointed this out to William before, but he doesn’t like to use CCSV6,
> so you are wasting your time ;-)
>
> Hi William,
>
> By dead technology, I mean there is no further development expected. All
> future efforts will focus on RemoteProc/RPMSG. For someone looking to start
> development with remote processor communications, why spend the time
> learning a technology that isn’t going anywhere? Rather, spend time
> learning to use a technology that will be enhanced and supported in future
> kernels.
>
> Regards,
> John
>
>
>
>
> On Feb 10, 2016, at 4:37 PM, Soapy Smith  wrote:
>
>
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_6:_Blinking_LEDs_with_RPMsg_from_Linux_User_Space
>
> Hi William, please see the above.  I have the PRU Cape, but I haven't got
> this far in the labs.  The other labs with remoteproc and other associated
> modules works so far.
>
> Regards,
> Greg
>
> On Wednesday, February 10, 2016 at 7:25:27 PM UTC-5, William Hermans wrote:
>>
>> *William, what are you talking about? Why would I take what you say
>>> personally? You make these blanket statements about a technology you say
>>> you don’t know how to use and recommend that everyone else not use this
>>> technology. If you want to stay with a dead technology, that is your call,
>>> but there is no reason for anyone to stay away from RemoteProc/RPMSG.
>>> Manufacturers other than TI have embraced this technology which open up a
>>> range of cores you can interact with, such as DSP, CortexM4, PRU, etc. Yes,
>>> I know you told me you have no interest in the x15 so this is probably not
>>> important to you and I respect that. *
>>>
>>
>> So, using something consistent , that is well documented, and has been
>> proven to work over the last several years does not make it "dead tech". It
>> makes it something that actually works for many people. No one cares what
>> TI adopts, except perhaps you, and TI. People care what works, with the
>> least amount of resistance.
>>
>> So hey lets put the squash on this right now. Why don't you write us some
>> code in the next day or two that blinks the USR leds in some kind of
>> pattern that proves the remoteproc / rpmsg is actually functional / usable.
>> As no one cares if you can write 100 "hello world " messages into
>> /var/log/messages . . . I can do that with a bash script and no PRU . . .
>>
>> You do that, and I'll concede that remoteproc is at least semi useful.
>>
>>
>> On Wed, Feb 10, 2016 at 4:57 PM, John Syne  wrote:
>>
>>> William, what are you talking about? Why would I take what you say
>>> personally? You make these blanket statements about a technology you say
>>> you don’t know how to use and recommend that everyone else not use this
>>> technology. If you want to stay with a dead technology, that is your ca

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

[William Hermans]

>
> *Hi William, one note on CCS.  I haven't used it at all.  The
> compiler/assembler (clpru) and associated includes and libraries are
> present in the Beaglebone testing image (Debian 8, version 4 kernel).*
> *I had to tweak add a symbolic link for the clpru, but that's it.  After
> that, the Makefiles included in the labs worked perfectly.  All done at the
> command line.  No CCS IDE required.*
> *I wasn't excited about CCS either, but then I discovered the clpru stuff
> and no problems.*


Hi Soapy,

Yeah there was what ? 3 different ways one could go. Well technicaly 4-5 I
guess including following the gcc path. I messed with attempting to get the
standalone TI C compiler, on a cross(Lubuntu 14.04 x64 ) system. No joy
after I guess about a day and a half. Normally, I probably would have
gotten it to work, but after playing around with that, and several other
things all related to the PRU's I decided to toss in the towel.

In relation though I was able to work with a custom am335x_pru_package git,
that included example code for using the USR LEDs, and a dmx light
controller. The USR LED example I got working straight off, no problem, and
I'd assume the dmx controller would also have worked, but I had no hardware
to test.

Plus the am335x_pru_package driver uses UIO, which I find really
interesting, and indeed really  easy to write a custom driver for when the
need arises. Or, more likely just modify the existing one, but it's really
easy to read through and understand . . .

On Wed, Feb 10, 2016 at 8:41 PM, John Syne  wrote:

> Here is what Robert Nelson said on Dec 17, 2015: "If you want "uio_pruss"
> use "4.1.x-bone", while this "4.1.x-ti" branch is developing
> "pruss_remoteproc" which will be replacing uio_pruss…”
>
> If you look at the development off uio_pruss, it was developed in 2011 and
> has a few update/fixes since then, but no new development.
>
> With RemoteProc/VirtualIO, it is possible to implement custom hardware
> interfaces on the PRU such as Profibus, Ethernet, UART, i2C, SPI, ADC, DAC,
> etc and make those look like a device to the Linux kernel.
>
> Regards,
> John
>
>
>
>
> On Feb 10, 2016, at 6:35 PM, William Hermans  wrote:
>
> *Hi Greg,*
>>
>> *I’ve pointed this out to William before, but he doesn’t like to use
>> CCSV6, so you are wasting your time ;-)*
>>
>
> Actually John, I was well aware of that guide long before you ever
> mentioned it.
>
> *Hi William,*
>>
>> *By dead technology, I mean there is no further development expected. All
> future efforts will focus on RemoteProc/RPMSG. For someone looking to start
> development with remote processor communications, why spend the time
> learning a technology that isn’t going anywhere? Rather, spend time
> learning to use a technology that will be enhanced and supported in future
> kernels. *
>
> That's not for you, or even TI to decide. That is for the community to
> decide. Especially since TI has pretty much refused to support the PRU
> since day one. As for what who does when. You seem to conveniently
> selectively reading what I write in my post. As I've said like 500 times
> already. I do not care what people use. I will however come into a post
> like this where the OP originally posted in relation to something
> am335x_pru_package specific. and you or anyone for that matter jumps in
> suggesting to use remoteproc / rpmsg. Why ?
>
> Because obviously this person has a time investment into the
> am335x_pru_package already. I'd like to try and save them from chasing yet
> another rabbit down yet another useless rabbit hole. As many people here
> use this software in products, school projects, or just something very
> serious in the hobbyist circles. They do not care what you think about some
> experimental bit of software that has yet to be proven . . .
>
> You're like TJP or whatever his name. Everything is a nail, except instead
> of prusio, or whatever it is, remoteproc is your hammer.
>
>
> On Wed, Feb 10, 2016 at 7:22 PM, John Syne  wrote:
>
>> Hi Greg,
>>
>> I’ve pointed this out to William before, but he doesn’t like to use
>> CCSV6, so you are wasting your time ;-)
>>
>> Hi William,
>>
>> By dead technology, I mean there is no further development expected. All
>> future efforts will focus on RemoteProc/RPMSG. For someone looking to start
>> development with remote processor communications, why spend the time
>> learning a technology that isn’t going anywhere? Rather, spend time
>> learning to use a technology that will be enhanced and supported in future
>> kernels.
>>
>> Regards,
>> John
>>
>>
&

Re: [beagleboard] DDR3 RAM access from PRU program

[William Hermans]

>
> *But I wonder if you could use the large 512MB DDR3 RAM with the PRU. *
>


No, because Linux is probably going to need at minimum 50MB to run, and
ideally 128-256M for caching, and process housekeeping etc. But you can use
a good portion of that DDR memory.

On Thu, Feb 11, 2016 at 12:31 AM,  wrote:

>
> Is it possible for the PRU program to use DDR3 RAM? I'm looking for a way
> to interface high resolution camera with the BBB. The PRU in beagle bone
> looks nice for this job with its good performance. But I wonder if you
> could use the large 512MB DDR3 RAM with the PRU.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How do you enable analog on Beaglebone Black?

[William Hermans]

http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/

On Thu, Feb 11, 2016 at 5:52 PM, John Syne  wrote:

> Do you see /sys/bus/iio folder?
>
> If you don’t, then load the kernel module:
>
> modprobe ti_am335x_adc
>
> Regards,
> John
>
>
>
>
> On Feb 11, 2016, at 2:04 PM, newquist...@gmail.com wrote:
>
> Hi, I am new to Beaglebone, and it seems that analog is not enabled.  I am
> using a new Beaglebone Black Rev C with debian linux version 4.4.  I tried
> both the default image and the image on the board, and neither had the
> analog enabled.
>
> How do you enable analog?
>
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How do you enable analog on Beaglebone Black?

[William Hermans]

>
> *My approach was wrong because you need the devicetree, so follow
> William’s docs.*
> *Regards,*
>
*John*


Not necessarily wrong. The ADC device tree file would, and will infact load
the same device module. The only problem with just loading the kernel
module, is the pins will be in whatever the default state is after boot up.
Which I'm not certain what state that would be . . .

On Thu, Feb 11, 2016 at 6:00 PM, John Syne  wrote:

> My approach was wrong because you need the devicetree, so follow William’s
> docs.
>
> Regards,
> John
>
>
>
>
> On Feb 11, 2016, at 4:54 PM, William Hermans  wrote:
>
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
>
> On Thu, Feb 11, 2016 at 5:52 PM, John Syne  wrote:
>
>> Do you see /sys/bus/iio folder?
>>
>> If you don’t, then load the kernel module:
>>
>> modprobe ti_am335x_adc
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 11, 2016, at 2:04 PM, newquist...@gmail.com wrote:
>>
>> Hi, I am new to Beaglebone, and it seems that analog is not enabled.  I
>> am using a new Beaglebone Black Rev C with debian linux version 4.4.  I
>> tried both the default image and the image on the board, and neither had
>> the analog enabled.
>>
>> How do you enable analog?
>>
>> 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.
>> 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.
>> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Websocket on Beagelbone

[William Hermans]

You have two options that I'm aware of.


   1. Use Nodejs + socket.io
   2. Use libmongoose

There actually a third option I can think of off hand. Write your own
library from scratch . . .

On Thu, Feb 11, 2016 at 7:27 PM, Abhishek G  wrote:

> Hi,
>
> I was planning to send some data from beaglebone to AWS server which runs
> an EC2 instance of ubuntu.
>
> Can anyone help me on how to go about this? It would be more helpful if it
> is through a websocket protocol.
>
> Regards
> Abhishek Gurudutt
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to build Os to beaglebone with hardcoding some of the GPIOs of beaglebone?

[William Hermans]

What ? Could you possibly ask a more obscure question ?

On Thu, Feb 11, 2016 at 10:47 PM, Gowri reddi 
wrote:

> How to build Os to beaglebone with hardcoding some of the GPIOs of
> beaglebone?
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to build Os to beaglebone with hardcoding some of the GPIOs of beaglebone?

[William Hermans]

>
> *When I refer, Beaglebone Black P8 Header, the GPIO 38, 39 (GPIO1[6],
> GPIO1[7]) are having note as "Used on Board (Group: pinmux_emmc2_pins).
> There are more other PINs having same note.*
>

The bolded text in the quote above should make it obvious as to why your
attempt as using these pins as gpio's fails. They're in use, and whats
more, they're in use by the eMMC interface is seems.

With older 3.8.x kernels is was possible to disable the eMMC by removing,
or commenting out loading the appropriate device tree file in uEnv.txt.
Then one could use the pin otherwise assigned to the eMMC how they saw fit.
One thing to note however. The hardware is still physically connected, so
it could be a bad idea to use some, or all of the pins other than how
they're meant to be used.  For this, you would need to consult with one of
the community members whose expertise with electronics is greater than mine.

With current 4.1.x kernels, I'd assume the above procedure has not changed
much, if at all. But I am unsure. As I have not had reason to check / test
this.

On Fri, Feb 12, 2016 at 12:51 AM, Gowri reddi 
wrote:

> Hi William,
>
> Thanks for your reply.
>
> On Beaglebone black, when I tried turn ON/OFF the LEDs connected to GPIOs
> like 38, 39 on Beaglebone, I am not able to do. With the same logic I am
> able turn ON/OFF of LEDs connected to GPIOs 44, 45 etc.
>
> When I refer, Beaglebone Black P8 Header, the GPIO 38, 39 (GPIO1[6],
> GPIO1[7]) are having note as "Used on Board (Group: pinmux_emmc2_pins).
> There are more other PINs having same note.
>
> I think, those are not by default available as GPIOs, rather used for
> internal purpose.
>
> So, I am looking for below
> - Is there any way to use them (ex: GPIO1[6], GPIO1[7]) as GPIOs
> - Is there any way to build Beaglebone OS such that those (ex: GPIO1[6],
> GPIO1[7]) pins can be used as GPIO directly without changing anything.
>
> Thanks,
> Gowri.
>
> On Fri, Feb 12, 2016 at 11:41 AM, William Hermans 
> wrote:
>
>> What ? Could you possibly ask a more obscure question ?
>>
>> On Thu, Feb 11, 2016 at 10:47 PM, Gowri reddi 
>> wrote:
>>
>>> How to build Os to beaglebone with hardcoding some of the GPIOs of
>>> beaglebone?
>>>
>>> --
>>> 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.
>>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/yOhAH_kVxyI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Read voltage from ADC using an external power supply

[William Hermans]

>
> *So I went back to the basic, and just ran the code without plugging
> anything in, and yet the voltage value I'm printing says 1.6 instead of 0.
> Below shows the code, which I got from adafruit. I'm aware that I'm not
> supposed to connect BBB ADC to anything above 1.8V or below 0V, which I
> don't believe I have.*
>

Ok, somehow I managed to miss this paragraph when I first posted. So
Chelsea, if you have not enabled the internal pulldown for the ADC pin in
question, where you're getting 1.6v. That makes perfect sense. These pins
will return a value in the mid to high range values when left floating.
Typically when I did experimentation I would read between 2500's and
4500's.

*I've also been reading somewhere that I may have to enable the ADC before
> I can read it??*
>

I really do not see how you can be getting any values out of the ADC at all
if it's not already enabled. ut here is a short "primer" I wrote concerning
the onchip ADC:
http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/

On Sat, Feb 13, 2016 at 1:36 AM, TJF  wrote:

> Hi Chelsea Orefice!
>
> 1V6 at an open pin looks good. AIN7 is connected to 1V65 at the board
> (half of power line) and that voltage pulls up the other pins, when open.
> When connecting P9_40 to ADC_GND you should see a values close to zero.
>
> You could use the libpruio 
> example oszi
> 
> to study the ADC behaviour.
>
> BR
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Read voltage from ADC using an external power supply

[William Hermans]

>
> *Typically when I did experimentation I would read between 2500's and
> 4500's*.
>

typo . . should be 3500's and that is out of 4095 possible as max value for
the onchip ADC.

On Sun, Feb 14, 2016 at 1:24 PM, William Hermans  wrote:

> *So I went back to the basic, and just ran the code without plugging
>> anything in, and yet the voltage value I'm printing says 1.6 instead of 0.
>> Below shows the code, which I got from adafruit. I'm aware that I'm not
>> supposed to connect BBB ADC to anything above 1.8V or below 0V, which I
>> don't believe I have.*
>>
>
> Ok, somehow I managed to miss this paragraph when I first posted. So
> Chelsea, if you have not enabled the internal pulldown for the ADC pin in
> question, where you're getting 1.6v. That makes perfect sense. These pins
> will return a value in the mid to high range values when left floating.
> Typically when I did experimentation I would read between 2500's and
> 4500's.
>
> *I've also been reading somewhere that I may have to enable the ADC before
>> I can read it??*
>>
>
> I really do not see how you can be getting any values out of the ADC at
> all if it's not already enabled. ut here is a short "primer" I wrote
> concerning the onchip ADC:
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
>
> On Sat, Feb 13, 2016 at 1:36 AM, TJF  wrote:
>
>> Hi Chelsea Orefice!
>>
>> 1V6 at an open pin looks good. AIN7 is connected to 1V65 at the board
>> (half of power line) and that voltage pulls up the other pins, when open.
>> When connecting P9_40 to ADC_GND you should see a values close to zero.
>>
>> You could use the libpruio <http://beagleboard.org/project/libpruio/>
>> example oszi
>> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaOszi>
>> to study the ADC behaviour.
>>
>> BR
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] sd card debian console image first sector

[William Hermans]

>
> *BTW, 8192 is all mostly tied to fat, which we don't use anymore by
> default...*
>
> *
> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
> *
>
> * under: "FAT optimization"*


Some people seem to think that 8192 sectors is where an sdcard needs to
start in order to perform the best, and to keep from "destroying" the card.
Something to do with where erase blocks start and all that but . . . I've
been using 2048 now for 3 years with this hardware using the same sdcard,
and have written at least 50 fresh images to it . . .

It's not as though this hardwares sdcard controller is the fastest around
either . . . because it's not. From what I've read for performance specs of
the rPI's sdcard. This one is about half as fast. BUt the rPI also does not
have an on board eMMC either.

Anyway, there seems to be a lot of concern about prematurely killing sdcard
using wrong sector values, and perhaps that is true, but I've yet to see a
card failure yet on our BBB's  . . .

On Sun, Feb 14, 2016 at 5:47 PM, Robert Nelson 
wrote:

> On Sun, Feb 14, 2016 at 6:43 PM, Robert Nelson 
> wrote:
> > On Sun, Feb 14, 2016 at 6:26 PM, joelk  wrote:
> >>
> >> I downloaded the debian 7.9 console image
> >> (bone-debian-7.9-console-armhf-2015-11-03-2gb.img) and wrote it to a
> micro
> >> sd card using dd:
> >>
> >> dd bs=4M if=bone-debian-7.9-console-armhf-2015-11-03-2gb.img of=/dev/sdb
> >>
> >> I notice that after flashing, the sdb1 partition on the card begins at
> >> sector 2048.  The original formatting of these cards have the data area
> >> beginning at sector 8192 and other sd card images that I've written
> (e.g.
> >> Raspbian Jessie) also start at sector 8192.  I was under the impression
> that
> >> this was done to reduce the number of pages that have to be rewritten
> when
> >> data is saved to the card.
>
> BTW, 8192 is all mostly tied to fat, which we don't use anymore by
> default...
>
>
> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
>
> under: "FAT optimization"
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] sd card debian console image first sector

[William Hermans]

Oh, and right . . . http://lwn.net/Articles/428584/

Read if you're really worried *that* much.

On Sun, Feb 14, 2016 at 6:02 PM, William Hermans  wrote:

> *BTW, 8192 is all mostly tied to fat, which we don't use anymore by
>> default...*
>>
>> *
>> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
>> <https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey>*
>>
>> * under: "FAT optimization"*
>
>
> Some people seem to think that 8192 sectors is where an sdcard needs to
> start in order to perform the best, and to keep from "destroying" the card.
> Something to do with where erase blocks start and all that but . . . I've
> been using 2048 now for 3 years with this hardware using the same sdcard,
> and have written at least 50 fresh images to it . . .
>
> It's not as though this hardwares sdcard controller is the fastest around
> either . . . because it's not. From what I've read for performance specs of
> the rPI's sdcard. This one is about half as fast. BUt the rPI also does not
> have an on board eMMC either.
>
> Anyway, there seems to be a lot of concern about prematurely killing
> sdcard using wrong sector values, and perhaps that is true, but I've yet to
> see a card failure yet on our BBB's  . . .
>
> On Sun, Feb 14, 2016 at 5:47 PM, Robert Nelson 
> wrote:
>
>> On Sun, Feb 14, 2016 at 6:43 PM, Robert Nelson 
>> wrote:
>> > On Sun, Feb 14, 2016 at 6:26 PM, joelk  wrote:
>> >>
>> >> I downloaded the debian 7.9 console image
>> >> (bone-debian-7.9-console-armhf-2015-11-03-2gb.img) and wrote it to a
>> micro
>> >> sd card using dd:
>> >>
>> >> dd bs=4M if=bone-debian-7.9-console-armhf-2015-11-03-2gb.img
>> of=/dev/sdb
>> >>
>> >> I notice that after flashing, the sdb1 partition on the card begins at
>> >> sector 2048.  The original formatting of these cards have the data area
>> >> beginning at sector 8192 and other sd card images that I've written
>> (e.g.
>> >> Raspbian Jessie) also start at sector 8192.  I was under the
>> impression that
>> >> this was done to reduce the number of pages that have to be rewritten
>> when
>> >> data is saved to the card.
>>
>> BTW, 8192 is all mostly tied to fat, which we don't use anymore by
>> default...
>>
>>
>> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
>>
>> under: "FAT optimization"
>>
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] sd card debian console image first sector

[William Hermans]

One I forgot to mention that is fairly important. First, in units, MiB is
*NOT* equivalent to MB. One is Mebi, the other is Mega. That is, 1024
versus 1000 bytes - per unit. So when you see people saying that the first
erase block group should be at 4MiB on an sdcard. They are probably wrong.
OEM venders in the consumer market typically do not use Mebibyte as a size
measurement. They use Mega, giga kilo, etc.

On Sun, Feb 14, 2016 at 6:04 PM, William Hermans  wrote:

> Oh, and right . . . http://lwn.net/Articles/428584/
>
> Read if you're really worried *that* much.
>
> On Sun, Feb 14, 2016 at 6:02 PM, William Hermans 
> wrote:
>
>> *BTW, 8192 is all mostly tied to fat, which we don't use anymore by
>>> default...*
>>>
>>> *
>>> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
>>> <https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey>*
>>>
>>> * under: "FAT optimization"*
>>
>>
>> Some people seem to think that 8192 sectors is where an sdcard needs to
>> start in order to perform the best, and to keep from "destroying" the card.
>> Something to do with where erase blocks start and all that but . . . I've
>> been using 2048 now for 3 years with this hardware using the same sdcard,
>> and have written at least 50 fresh images to it . . .
>>
>> It's not as though this hardwares sdcard controller is the fastest around
>> either . . . because it's not. From what I've read for performance specs of
>> the rPI's sdcard. This one is about half as fast. BUt the rPI also does not
>> have an on board eMMC either.
>>
>> Anyway, there seems to be a lot of concern about prematurely killing
>> sdcard using wrong sector values, and perhaps that is true, but I've yet to
>> see a card failure yet on our BBB's  . . .
>>
>> On Sun, Feb 14, 2016 at 5:47 PM, Robert Nelson 
>> wrote:
>>
>>> On Sun, Feb 14, 2016 at 6:43 PM, Robert Nelson 
>>> wrote:
>>> > On Sun, Feb 14, 2016 at 6:26 PM, joelk  wrote:
>>> >>
>>> >> I downloaded the debian 7.9 console image
>>> >> (bone-debian-7.9-console-armhf-2015-11-03-2gb.img) and wrote it to a
>>> micro
>>> >> sd card using dd:
>>> >>
>>> >> dd bs=4M if=bone-debian-7.9-console-armhf-2015-11-03-2gb.img
>>> of=/dev/sdb
>>> >>
>>> >> I notice that after flashing, the sdb1 partition on the card begins at
>>> >> sector 2048.  The original formatting of these cards have the data
>>> area
>>> >> beginning at sector 8192 and other sd card images that I've written
>>> (e.g.
>>> >> Raspbian Jessie) also start at sector 8192.  I was under the
>>> impression that
>>> >> this was done to reduce the number of pages that have to be rewritten
>>> when
>>> >> data is saved to the card.
>>>
>>> BTW, 8192 is all mostly tied to fat, which we don't use anymore by
>>> default...
>>>
>>>
>>> https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
>>>
>>> under: "FAT optimization"
>>>
>>> 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.
>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black USB webcam trouble

[William Hermans]

>
> *RT plays with a lot of things to try and make the kernel tasks operate*
> * in Real Time...  It's a work and progress, looking at your dmesg, your*
> * camera driver had issues with it.  It was still 50/50 that it would*
> * help, we just got lucky..*


More than that, I seriously doubt an RT kernel is going to help with this
type of situation. RT kernels are meant to help with real time situations,
and camera applications do not to my knowledge do not need, or even want
real time operation. In fact, I do believe if you do the research a real
time kernel can potentially slow down disk access, disk caching, and the
like.

On Mon, Feb 15, 2016 at 4:17 PM, Robert Nelson 
wrote:

> On Mon, Feb 15, 2016 at 5:09 PM, joelk  wrote:
> > @John: Yes, I will try a Debian image, after I try the kernel Robert
> > suggested.  Maybe I can give him some useful feedback.
> >
> > Also, I'd rather not bog things down with a desktop environment that I
> don't
> > need.  The latest Jessie image seems to have LXDE and enough other stuff
> to
> > fill up 4GB.  Is there a console image of Jessie hidden away somewhere?
> >
> > @Robert:
> > Before switching the kernel I ran apt-get update and apt-get upgrade.
> Hit a
> > little snag at the end of the update.  I just want to document this here
> in
> > case things get worse:
> >
> >> Processing triggers for initramfs-tools
> >> (0.103ubuntu4.2-1rcnee1~bpo1404+20151007+1) ...
> >> update-initramfs: Generating /boot/initrd.img-4.4.0-armv7-x3
> >> WARNING: missing /lib/modules/4.4.0-armv7-x3
> >> Device driver support needs thus be built-in linux image!
> >> depmod: ERROR: could not open directory /lib/modules/4.4.0-armv7-x3: No
> >> such file or directory
> >> depmod: FATAL: could not search modules: No such file or directory
> >> depmod: WARNING: could not open
> >> /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.order: No
> such
> >> file or directory
> >> depmod: WARNING: could not open
> >> /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.builtin: No
> such
> >> file or directory
>
> That's nothing to worry about, it's dual board base image,
> 4.4.0-armv7-x3 is the kernel for the beagleboard xM...
>
> >>
> >
> > apt-get does not offer to upgrade anything else at this point.  Rebooted
> OK.
> > /boot contains initrd.img-4.4.0-armv7-x3 with size == 2122190 and
> > timestamped just 10 minutes ago.  I don't know what's missing or how
> > important it is.
> >
> > Before changing kernel, uname -r gives 4.1.15-ti-rt-r40
> > Updating the kernel was uneventful.
> > Rebooted OK.
> >
> > Robert, you're a hero.  motion runs & its http server sends a stream over
> > the web.  same goes for koudevoeten, although I had to kill -9 to stop
> it.
> > So far so good.
> >
> > So please tell me -- what is this evil RT patchset that's been causing so
> > much grief?  And how will I know which kernels have it and which don't?
> > Which Debian images (preferable console-only) can I use?
>
> RT plays with a lot of things to try and make the kernel tasks operate
> in Real Time...  It's a work and progress, looking at your dmesg, your
> camera driver had issues with it.  It was still 50/50 that it would
> help, we just got lucky..
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

You need to see what raw values are being read out of the ADC. If they're
higher than 4095, then you've got a problem - Which I'd guess would be a
bad ADC.

Passed that . . .

voltage = ( raw_value / 4095 ) * scale

Where scale =  highest possible voltage to be read in. Then of course max
voltage on the ADC must not exceed 1.8v, ever.

Anyway, I figure you probably know most of this already, but do need to
know that raw values over 4095 is very likely going to be bad news . . .

On Tue, Feb 16, 2016 at 7:23 AM, hllpc  wrote:

> Hi everybody,
> for a university project I'm using a bbb with Linux 3.8.13 bone49, for a
> couple of months I was acquiring analog input using the internal adc of the
> beaglebone and the pruss, using as a starting point Derek Molloy's example
> (exploringbeaglebone/chapter13) and ADCCollector.c /ADCCollector.p files,
> basically I sample the signal at tevery front end of a pru clock with a
> fixed frequency.
>
> Before running my program I always load the two overlays
> EBB-PRU-Example.dtbo and BB-ADC.dtbo and modprobe uio_pruss.
>
> I've no idea what's happened yesterday night but today I'm not able
> anymore to get coerents values from the ADC (AIN0 and ground), with a
> positive sinusoid of 1 V module I'm getting values that after the
> conversion (*1.8/4095) are around 11 V. The code has not being modified
> andI'm 100% that strangely enough the problem is not in the prus overlay,
> since I'm monitoring the 'sampling-clock' using an oscilloscope.
>
> Any idea about what is going on?
> /
> I've rebooted and resetted the bbb, removed and loaded the overlays, I
> don't have the /sys/devices/platform/tsc directory and doing:
>
> cat: /sys/bus/iio/devices/iio:device0/in_voltage: No such file or
> directory.
>
> dmesg:
> root@arm:/home/debian# dmesg
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpu
> [0.00] Linux version 3.8.13-bone49 (root@imx6q-wandboard-2gb-0)
> (gcc
> ver
> sion 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri May 2 06:36:13 UTC 2014
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
> cr=50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instructio
> n cache
> [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
> AM335x
> BeagleBone
> [0.00] Memory policy: ECC disabled, Data cache writeback
> [0.00] On node 0 totalpages: 130816
> [0.00] free_area_init_node: node 0, pgdat c0828540, node_mem_map
> c08a300
> 0
> [0.00]   Normal zone: 1024 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 129792 pages, LIFO batch:31
> [0.00] AM335X ES1.0 (neon )
> [0.00] PERCPU: Embedded 9 pages/cpu @c0cb3000 s14080 r8192 d14592
> u36864
> [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096
> [0.00] pcpu-alloc: [0] 0
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
> Total
> pag
> es: 129792
> [0.00] Kernel command line: console=ttyO0,115200n8
> capemgr.disable_partn
> o=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-SPI01-01
> root=UUID=df5f218f-c512-4a0a-84fd-9
> 224c752d1e9 ro rootfstype=ext4 rootwait fixrtc ip= quiet
> init=/lib/systemd/syste
> md
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
> bytes)
> [0.00] __ex_table already sorted, skipping sort
> [0.00] allocated 1048576 bytes of page_cgroup
> [0.00] please try 'cgroup_disable=memory' option if you don't want
> memor
> y cgroups
> [0.00] Memory: 511MB = 511MB total
> [0.00] Memory: 506200k/506200k available, 18088k reserved, 0K
> highmem
> [0.00] Virtual kernel memory layout:
>vector  : 0x - 0x1000   (   4 kB)
>fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
>vmalloc : 0xe080 - 0xff00   ( 488 MB)
>lowmem  : 0xc000 - 0xe000   ( 512 MB)
>pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>modules : 0xbf80 - 0xbfe0   (   6 MB)
>  .text : 0xc0008000 - 0xc0766d14   (7548 kB)
>  .init : 0xc0767000 - 0xc07a2700   ( 238 kB)
>  .data : 0xc07a4000 - 0xc082b500   ( 542 kB)
>   .bss : 0xc082b500 - 0xc08a2c40   ( 478 kB)
> [0.00] Hierarchical RCU implementation.
> [0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
> [0.00] NR_IRQS:0 nr_irqs:0 0
> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
> interrup
> ts
> [0.00] Total of 128 interrupts on 1 active controller
> [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz
> [0.00] sched_clock: 32 bits at 2

Re: [beagleboard] Re: R or Python cross compiler for beaglebone

[William Hermans]

>
> *Since debugging and testing may also require more resources than are
> available on the BeagleBone Black, cross-compilation can be less involved
> and less prone to errors than native compilation.*
>

This is incorrect. Cross compiling anything introduces added complexity,
and thus is more prone to errors. The main problem with compiling natively
is the time it takes for the beaglebone hardware to finish compiling from
source. Another problem is the minimal amount of RAM on the system, which
can be mitigated *some* by using a USB hard drive, as a swap drive.

Anyway, I think I know what you're saying. So know that when compiling
"natively" you're not limited to using a beaglebone only. "Natively" in
this context would mean anything that can run, or is running the same OS,
using the same ABI. Which in this case the ABI is armhf. In other words . .
. most / all armv7 systems. Such as the rPI 2, wanderboard, Beagleboard
X15, etc. Can be made to natively compile a binary for the Beaglebone
black. This works great, but does take some time to setup perhaps, and does
cost additional monies( to purchase another board ).

Additionally. I personally write C applications in x86 / i386 a lot. These
applications will also 99% of the time directly port to an ARM system with
nothing more than copying, and compiling the source to / on that system. C
is a true compiled language, where Python, and R( as far as I know ), are
byte code / interpreted languages. The point here is that if C can be used
in this manner, surely Python, and R can too.

What does this mean ? This means that once you have a run-time working on a
platform, for an interpreted language. Code written on one system should
run just fine on another. Assuming there are no major version barriers
interfering. As mentioned above by Dennis. Debian, regardless of ABI is
going to have a Python interpreter period. As Python, C, and ruby are all
needed in order to build, install and otherwise setup a new Debian( and
very probably any Linux system ).

So this means you already have a Python run-time available at minimum
through the APT package manager. Probably R too but let's have a look . . .
googling "debian R runtime"

https://packages.debian.org/wheezy/r-base-core
william@beaglebone:~$ *apt-cache search r-base-core*
r-base-core - GNU R core of statistical computation and graphics system
r-base-core-dbg - GNU R debug symbols for statistical comp. language and
environment

So you need to cross compile what / why ?



On Tue, Feb 16, 2016 at 10:43 AM,  wrote:

> Thank you for replying.
>
> BBB has limited resources to make build and install R packages (R-base and
> some ML packages, or any other packages for that matter). Also, I would
> like to test the build before actually porting the binaries to BBB. Since
> debugging and testing may also require more resources than are available on
> the BeagleBone Black, cross-compilation can be less involved and less prone
> to errors than native compilation.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

>
> *I have been wondering the same thing, would the BeagleBoard-X15 make a
> reasonable system for developing on a native ARM platform?  Are there other
> more cost effective alternatives?*
>
> *Thanks,*
>
*Adi*

Anything that has an armv7 processor. Other ARM core types too, but the
original Raspberry PI for instance would not work. It has an outdated ARM
core, which barely anyone support, in the context of Linux distributions.

rPI 2, wanderboard, Beagleboard X15 are 3 different boards, with the rPI 2
probably being the cheapest in terms of cost. However it is limited to
sdcard / usb media for storage. The wanderboard / X15 both have SATA.

 Here is another alternative that has SATA and is inexpensive:
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware

You can ask Robert about the LIME2, as he has built images for these in the
past.

Something to be aware of though. Most of the less expensive alternatives
are going to be missing a nice feature or have limited resources. Such as
no SATA, or only having 1GB RAM versus 2GB or more. Here, this is why cross
compiling can be very attractive, as an x86-64 system can have 16GB or
more, of which more than half can be dedicated to a tmpfs RAM disk. Which
can help speed up large source compiles drastically.

Anyway, google, and you'll probably run into many more options


On Tue, Feb 16, 2016 at 11:41 AM, John Syne  wrote:

> It depends on what you want. If you are only interested in an ARM
> platform, then there are alternatives that are less expensive. If you are
> interested in using Dual CortexA15s, Dual DSP cores, Dual CortexM4s, quad
> PRUs, etc then there is nothing like this monster.
>
> Regards,
> John
>
>
>
>
> On Feb 16, 2016, at 7:02 AM, Adi Linden  wrote:
>
> I have been wondering the same thing, would the BeagleBoard-X15 make a
> reasonable system for developing on a native ARM platform?  Are there other
> more cost effective alternatives?
>
> Thanks,
> Adi
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

>
> *Here, this is why cross compiling can be very attractive, as an x86-64
> system can have 16GB or more, of which more than half can be dedicated to a
> tmpfs RAM disk. Which can help speed up large source compiles drastically.*
>

Sorry I kind of jumped the gun here, and left out some information. When
compiling more than just a small personal project. 1-2GB is ideal, but
always the more you have, the better off you are. For me personally, I
consider 4GB the sweet spot, but have used virtual machines with 10GB of
RAM dedicated to them in order to compile the Linux kernel all in memory.
Which for the record, without using the RAM disk would take around an hour
or slightly longer to finish. When using a RAM disk to compile, it takes
about 15 minutes.

On Tue, Feb 16, 2016 at 12:35 PM, William Hermans  wrote:

> *I have been wondering the same thing, would the BeagleBoard-X15 make a
>> reasonable system for developing on a native ARM platform?  Are there other
>> more cost effective alternatives?*
>>
>> *Thanks,*
>>
> *Adi*
>
> Anything that has an armv7 processor. Other ARM core types too, but the
> original Raspberry PI for instance would not work. It has an outdated ARM
> core, which barely anyone support, in the context of Linux distributions.
>
> rPI 2, wanderboard, Beagleboard X15 are 3 different boards, with the rPI 2
> probably being the cheapest in terms of cost. However it is limited to
> sdcard / usb media for storage. The wanderboard / X15 both have SATA.
>
>  Here is another alternative that has SATA and is inexpensive:
> https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware
>
> You can ask Robert about the LIME2, as he has built images for these in
> the past.
>
> Something to be aware of though. Most of the less expensive alternatives
> are going to be missing a nice feature or have limited resources. Such as
> no SATA, or only having 1GB RAM versus 2GB or more. Here, this is why cross
> compiling can be very attractive, as an x86-64 system can have 16GB or
> more, of which more than half can be dedicated to a tmpfs RAM disk. Which
> can help speed up large source compiles drastically.
>
> Anyway, google, and you'll probably run into many more options
>
>
> On Tue, Feb 16, 2016 at 11:41 AM, John Syne  wrote:
>
>> It depends on what you want. If you are only interested in an ARM
>> platform, then there are alternatives that are less expensive. If you are
>> interested in using Dual CortexA15s, Dual DSP cores, Dual CortexM4s, quad
>> PRUs, etc then there is nothing like this monster.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 16, 2016, at 7:02 AM, Adi Linden  wrote:
>>
>> I have been wondering the same thing, would the BeagleBoard-X15 make a
>> reasonable system for developing on a native ARM platform?  Are there other
>> more cost effective alternatives?
>>
>> Thanks,
>> Adi
>>
>> --
>> 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.
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

OK, so define "way higher". Higher than 4095 ?

On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:

> Yes I know about the conversion raw values-> real values, two days ago the
> raw values where in the range0-2000 as they should have been, now they are
> way way higher
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

Anyway, two possibilities here if the raw values are higher than 4095.

1) Your ADC need to be calibrated. I believe there is info in the TRM on
this, but I have yet to fully understand this process myself. So see the
TRM for details.

2) your ADC is damaged, and very likely irreversibly.

On Tue, Feb 16, 2016 at 12:43 PM, William Hermans  wrote:

> OK, so define "way higher". Higher than 4095 ?
>
> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
>
>> Yes I know about the conversion raw values-> real values, two days ago
>> the raw values where in the range0-2000 as they should have been, now they
>> are way way higher
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

OK, so another possibility does come to mind. The values you're reading are
somehow becoming corrupt before you check them. So humor me here, and
honestly this is probably in your best interest anyhow. . .


   1. Reset your board, which is to say, reboot it, and make sure none of
   your stuff for the ADC loads at boot.
   2. Follow my guide here, but keep in mind it is based on 4.x kernels. So
   adjustments may have to be made
   http://www.embeddedhobbyist.com/2015/10/beaglebone-black-ad
   3. Use the sysfs method of reading values out of the ADC, single shot to
   double check raw values.

So, again, my guide above is meant for kernels 4.x but should work for the
most part. File locations, and in where to echo to load capes is different,
and I'm not sure what else. The point is that you need an alternate way of
testing your ADC, and making sure it is not somehow your code. Let me know
if this fixes the values read out, and if it does, we'll have to pour
through your code.

On Tue, Feb 16, 2016 at 12:53 PM, hllpc  wrote:

>
> Higher like 40k, in the firt piat i wrote that the "translated" value is
> 11 volt.
> But it's variable, start from 0 and then invrease. Or somethime it's all
> zeroes, or only numbers repeated like 11 12 14 all over again
> Il giorno martedì 16 febbraio 2016 20:43:21 UTC+1, William Hermans ha
> scritto:
>>
>> OK, so define "way higher". Higher than 4095 ?
>>
>> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
>>
>>> Yes I know about the conversion raw values-> real values, two days ago
>>> the raw values where in the range0-2000 as they should have been, now they
>>> are way way higher
>>>
>>> --
>>> 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...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

Just in case this somehow helps. ADC values are represented in a 32bit bit
field. But this bitfield actually has 3 fields inside of it. You can double
check to make sure I'm remembering correctly. But the first 12 bits is the
actual ADC value, the next 4 bits is the ADC identifier( channel ), and the
last 16 bits is "reserved", meaning it's not used.

SO if your bit alignment has somehow gone out of alignment . . . this could
very well explain high / bad raw values.

On Tue, Feb 16, 2016 at 1:39 PM, William Hermans  wrote:

> OK, so another possibility does come to mind. The values you're reading
> are somehow becoming corrupt before you check them. So humor me here, and
> honestly this is probably in your best interest anyhow. . .
>
>
>1. Reset your board, which is to say, reboot it, and make sure none of
>your stuff for the ADC loads at boot.
>2. Follow my guide here, but keep in mind it is based on 4.x kernels.
>So adjustments may have to be made
>http://www.embeddedhobbyist.com/2015/10/beaglebone-black-ad
>3. Use the sysfs method of reading values out of the ADC, single shot
>to double check raw values.
>
> So, again, my guide above is meant for kernels 4.x but should work for the
> most part. File locations, and in where to echo to load capes is different,
> and I'm not sure what else. The point is that you need an alternate way of
> testing your ADC, and making sure it is not somehow your code. Let me know
> if this fixes the values read out, and if it does, we'll have to pour
> through your code.
>
> On Tue, Feb 16, 2016 at 12:53 PM, hllpc  wrote:
>
>>
>> Higher like 40k, in the firt piat i wrote that the "translated" value is
>> 11 volt.
>> But it's variable, start from 0 and then invrease. Or somethime it's all
>> zeroes, or only numbers repeated like 11 12 14 all over again
>> Il giorno martedì 16 febbraio 2016 20:43:21 UTC+1, William Hermans ha
>> scritto:
>>>
>>> OK, so define "way higher". Higher than 4095 ?
>>>
>>> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
>>>
>>>> Yes I know about the conversion raw values-> real values, two days ago
>>>> the raw values where in the range0-2000 as they should have been, now they
>>>> are way way higher
>>>>
>>>> --
>>>> 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...@googlegroups.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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: R or Python cross compiler for beaglebone

[William Hermans]

>
> *@William*
> *Thanks for clarifying in detail. Yes, I have checked that the Python code*
> *written in x86 can be run on ARM system by just copying the code.*
>

Ok, so what you need to understand. Is that a run-time is just an
abstraction layer. It's this abstraction layer that handles all the system
level gory details. So once it is in place, everything else being equal,
it'll "just work" As Robert eluded to however, and I think I also mentioned
in my last post. Compiler / run-time versions need to be the same, or very
close for the best results.

*There are certain barriers as you pointed out, like slow compiling and
> limited RAM size.*
> *In my algorithm, I have to deal with a continuous data stream so limited
> ram size may affect the *
> *computation heavily. And, fast computation of large dataset is badly
> needed in my algorithm.*
> *That is why, I was thinking about cross-compiling.*
>

So, compilers, toolchains etc are getting very complex now days. Sometime,
just setting up a cross compile system for a certain situation can take a
considerable amount of time. So one needs to weight this possibility
against how long it might actually take to compile natively. If neither
possibility is acceptable, then one should look into buying a "bigger and
better" system to use as a build system for the beaglebone. It's been done,
and is what is refereed to as solving a problem by "throwing" more money at
the problem. A perfectly acceptable practice, for some.


> *And also, as you suggested to use swap drive like virtual memory concept,
> can you elaborate on how to implement it?*
>

This is something I would have to write a guide for, and put up on my blog
site, and which I might actually do soon. The problem here is that because
this is not a PC type computer system. The guides for that on the internet
will not work for this situation. These guides can be modified . . . but it
can be complex. Better for me to write and test a guide I know that will
work. One thing to keep in mind however. The USB drive has to has it's own
power supply. As the beaglebone will not supply enough power for the drive,
especially at "spin up". Where some drives can draw as much as 3A  . . .

On Tue, Feb 16, 2016 at 1:56 PM, Robert Nelson 
wrote:

> On Tue, Feb 16, 2016 at 2:51 PM,   wrote:
> > @William
> > Thanks for clarifying in detail. Yes, I have checked that the Python code
> > written in x86 can be run on ARM system by just copying the code.
> >
> > There are certain barriers as you pointed out, like slow compiling and
> > limited RAM size.
> > In my algorithm, I have to deal with a continuous data stream so limited
> ram
> > size may affect the
> > computation heavily. And, fast computation of large dataset is badly
> needed
> > in my algorithm.
> > That is why, I was thinking about cross-compiling.
>
> "cross-compiling" isn't going to help you there, as you still need to
> run your "algorithm" on the ARM system right???
>
> In the end, native vs cross building should give you the same final
> binary (assuming your cross/native compilers are the same
> version/etc..)
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: R or Python cross compiler for beaglebone

[William Hermans]

Another thing to point out, that I forgot to mention in my last post.
Depending on what you're doing with said code, Python can be dog slow. When
compared to many other languages for several situations. Performance wise,
Python is way down the list. I only mention this, as it seems to me that
you have a performance constraint for your situation. R I would assume will
not be much better, but possibly better than Python. Honestly 99% of the
other languages out there will outperform Python in many cases.

So, if you really need performance, you're probably going to want to use
another language. But to put  things in order . . .


   1. Assembly
   2. C
   3. Sometimes C++ Sometimes Javascript ( V8 engine ).

Seriously, Javascript in the context of googles V8 engine ( Nodejs ) really
is that fast. However, one thing I have noticed personally. Nodejs, when
written to run as a command line executable does have noticeable latency.
Meaning, if you need a tool that executes once when run, and then it
exists. Nodejs probably is not the best tool for that type of Job. If the
code is run once, and runs for long periods of time however . . . Nodejs
will perform really well. Still not as fast as C, and depending on what the
code is doing, perhaps not as fast as C++ either.


Anyway, C is probably the best well known for being the universal embedded
language of choice for many embedded developers. So perhaps you may want to
consider which language you use. C++ is also making it's way  into many
embedded projects. On a personal note however, I think C++ is a great
language especially when it comes to generics, and templates. However
because of all this "coolness" C++ brings it also bring complexity with it.
So for me personally, I tend to stick with straight C whenever possible.
Which has worked out to always for me.

On Tue, Feb 16, 2016 at 2:15 PM, William Hermans  wrote:

> *@William*
>> *Thanks for clarifying in detail. Yes, I have checked that the Python
>> code*
>> *written in x86 can be run on ARM system by just copying the code.*
>>
>
> Ok, so what you need to understand. Is that a run-time is just an
> abstraction layer. It's this abstraction layer that handles all the system
> level gory details. So once it is in place, everything else being equal,
> it'll "just work" As Robert eluded to however, and I think I also mentioned
> in my last post. Compiler / run-time versions need to be the same, or very
> close for the best results.
>
> *There are certain barriers as you pointed out, like slow compiling and
>> limited RAM size.*
>> *In my algorithm, I have to deal with a continuous data stream so limited
>> ram size may affect the *
>> *computation heavily. And, fast computation of large dataset is badly
>> needed in my algorithm.*
>> *That is why, I was thinking about cross-compiling.*
>>
>
> So, compilers, toolchains etc are getting very complex now days. Sometime,
> just setting up a cross compile system for a certain situation can take a
> considerable amount of time. So one needs to weight this possibility
> against how long it might actually take to compile natively. If neither
> possibility is acceptable, then one should look into buying a "bigger and
> better" system to use as a build system for the beaglebone. It's been done,
> and is what is refereed to as solving a problem by "throwing" more money at
> the problem. A perfectly acceptable practice, for some.
>
>
>> *And also, as you suggested to use swap drive like virtual memory
>> concept, can you elaborate on how to implement it?*
>>
>
> This is something I would have to write a guide for, and put up on my blog
> site, and which I might actually do soon. The problem here is that because
> this is not a PC type computer system. The guides for that on the internet
> will not work for this situation. These guides can be modified . . . but it
> can be complex. Better for me to write and test a guide I know that will
> work. One thing to keep in mind however. The USB drive has to has it's own
> power supply. As the beaglebone will not supply enough power for the drive,
> especially at "spin up". Where some drives can draw as much as 3A  . . .
>
> On Tue, Feb 16, 2016 at 1:56 PM, Robert Nelson 
> wrote:
>
>> On Tue, Feb 16, 2016 at 2:51 PM,   wrote:
>> > @William
>> > Thanks for clarifying in detail. Yes, I have checked that the Python
>> code
>> > written in x86 can be run on ARM system by just copying the code.
>> >
>> > There are certain barriers as you pointed out, like slow compiling and
>> > limited RAM size.
>> > In my algorithm, I have to deal with a continuous data stream so
>> limited ram
>> &g

Re: [beagleboard] Slew rate when toggling Enhanced GPIO pins in the PRU?

[William Hermans]

>
> *When I seperate each command by a delay, the rising edge of the clock
> takes ~90ns to go from 0V to 3.3V. I was under the impression that this
> operation would be performed at around ~5ns. I have attached the reading
> from my oscilloscope. My question is, is what I am seeing normal or am I
> doing something wrong?*
>

What kind of a delay are you using ? But if this delay has to interact with
an on chip timer of the L3 interconnect . . . it's going to take a lot
longer than ~5NS. Which is what I would think you're finding out now, but
I'm no expert . . .

On Tue, Feb 16, 2016 at 2:08 PM, John M  wrote:

> Hello All,
>
> I'm trying to create a clock using the PRU, and I have it working to an
> extent, but I am noticing a discrepancy between what I read in the TRM and
> what I'm seeing. When I use a series of SET CLR SET CLR commands on a pin,
> they do not resolve completely before the next command. When I seperate
> each command by a delay, the rising edge of the clock takes ~90ns to go
> from 0V to 3.3V. I was under the impression that this operation would be
> performed at around ~5ns. I have attached the reading from my oscilloscope.
> My question is, is what I am seeing normal or am I doing something wrong?
>
> Thank you.
>
>
> 
>
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: R or Python cross compiler for beaglebone

[William Hermans]

>
> *@William, please do share your blog site when you will *
> *finish writing the guide. That will be a great help.*


http://www.embeddedhobbyist.com/ is my blog. I've actually been thinking
about adding a different kind of blog for the last couple days, but this
one should not take too long. a couple hours maybe. Perhaps I'll get around
to that tonight. We'll see. No promises.

On Tue, Feb 16, 2016 at 2:38 PM,  wrote:

> Thank you @William and @Robert
> The thing is pretty clear to me now.
> As the code has to run in BeagleBone, so it doesn't matter
> where the binary file has been created.
>
> @William, please do share your blog site when you will
> finish writing the guide. That will be a great help.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Slew rate when toggling Enhanced GPIO pins in the PRU?

[William Hermans]

John,

Just a random thought here . . . perhaps adding a NOP or two would be
better than using a delay function. A Single NOP would / should be exactly
5ns . . .

On Tue, Feb 16, 2016 at 2:42 PM, William Hermans  wrote:

> *When I seperate each command by a delay, the rising edge of the clock
>> takes ~90ns to go from 0V to 3.3V. I was under the impression that this
>> operation would be performed at around ~5ns. I have attached the reading
>> from my oscilloscope. My question is, is what I am seeing normal or am I
>> doing something wrong?*
>>
>
> What kind of a delay are you using ? But if this delay has to interact
> with an on chip timer of the L3 interconnect . . . it's going to take a lot
> longer than ~5NS. Which is what I would think you're finding out now, but
> I'm no expert . . .
>
> On Tue, Feb 16, 2016 at 2:08 PM, John M  wrote:
>
>> Hello All,
>>
>> I'm trying to create a clock using the PRU, and I have it working to an
>> extent, but I am noticing a discrepancy between what I read in the TRM and
>> what I'm seeing. When I use a series of SET CLR SET CLR commands on a pin,
>> they do not resolve completely before the next command. When I seperate
>> each command by a delay, the rising edge of the clock takes ~90ns to go
>> from 0V to 3.3V. I was under the impression that this operation would be
>> performed at around ~5ns. I have attached the reading from my oscilloscope.
>> My question is, is what I am seeing normal or am I doing something wrong?
>>
>> Thank you.
>>
>>
>> <https://lh3.googleusercontent.com/-HgSaQGizihc/VsOPr4eIEPI/CwA/fJOdPU4KSlo/s1600/LeCroy.png>
>>
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Slew rate when toggling Enhanced GPIO pins in the PRU?

[William Hermans]

Sorry . .  I forgot to mention that I've read *somewhere* that the TI ASM
compiler / language does not make use of the ARM NOP instruction. In this
case though . . .

mov r0, r0

Would probably work as well. Here is some discussion on the subject.
http://stackoverflow.com/questions/1875491/nop-for-iphone-binaries

On Tue, Feb 16, 2016 at 2:49 PM, William Hermans  wrote:

> John,
>
> Just a random thought here . . . perhaps adding a NOP or two would be
> better than using a delay function. A Single NOP would / should be exactly
> 5ns . . .
>
> On Tue, Feb 16, 2016 at 2:42 PM, William Hermans 
> wrote:
>
>> *When I seperate each command by a delay, the rising edge of the clock
>>> takes ~90ns to go from 0V to 3.3V. I was under the impression that this
>>> operation would be performed at around ~5ns. I have attached the reading
>>> from my oscilloscope. My question is, is what I am seeing normal or am I
>>> doing something wrong?*
>>>
>>
>> What kind of a delay are you using ? But if this delay has to interact
>> with an on chip timer of the L3 interconnect . . . it's going to take a lot
>> longer than ~5NS. Which is what I would think you're finding out now, but
>> I'm no expert . . .
>>
>> On Tue, Feb 16, 2016 at 2:08 PM, John M  wrote:
>>
>>> Hello All,
>>>
>>> I'm trying to create a clock using the PRU, and I have it working to an
>>> extent, but I am noticing a discrepancy between what I read in the TRM and
>>> what I'm seeing. When I use a series of SET CLR SET CLR commands on a pin,
>>> they do not resolve completely before the next command. When I seperate
>>> each command by a delay, the rising edge of the clock takes ~90ns to go
>>> from 0V to 3.3V. I was under the impression that this operation would be
>>> performed at around ~5ns. I have attached the reading from my oscilloscope.
>>> My question is, is what I am seeing normal or am I doing something wrong?
>>>
>>> Thank you.
>>>
>>>
>>> <https://lh3.googleusercontent.com/-HgSaQGizihc/VsOPr4eIEPI/CwA/fJOdPU4KSlo/s1600/LeCroy.png>
>>>
>>>
>>> --
>>> 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.
>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

4095. It's zero based, so 0 is counted too. The bitfield is LSB as far as
I'm aware, but just standard bit  manipulation in C should present no
problems. As I've experienced none myself.

On Tue, Feb 16, 2016 at 3:06 PM, Harvey White 
wrote:

> On Tue, 16 Feb 2016 12:45:18 -0700, you wrote:
>
> >Anyway, two possibilities here if the raw values are higher than 4095.
> >
> >1) Your ADC need to be calibrated. I believe there is info in the TRM on
> >this, but I have yet to fully understand this process myself. So see the
> >TRM for details.
> >
> >2) your ADC is damaged, and very likely irreversibly.
>
> 3) 4096?
>
> If the registers are 16 bits, can the result be (by program) shifted
> to be left justified or right justified?  In many microprocessors this
> is possible.  If it's left justified, then > 4096 is just about
> guaranteed.
>
> Harvey
>
>
> >
> >On Tue, Feb 16, 2016 at 12:43 PM, William Hermans 
> wrote:
> >
> >> OK, so define "way higher". Higher than 4095 ?
> >>
> >> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
> >>
> >>> Yes I know about the conversion raw values-> real values, two days ago
> >>> the raw values where in the range0-2000 as they should have been, now
> they
> >>> are way way higher
> >>>
> >>> --
> >>> 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.
> >>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] R or Python cross compiler for beaglebone

[William Hermans]

First, "the interface" is slow: meaning the run time. But if you have to
"reinvent" a Python API / BCL because it is slow - And do that in C. Why
not just use C to begin with ?

Aside from Python forcing coding guidelines on it users, it's a fine
language. What it is  not though, is a good language when you need pure all
out performance. But not all code needs to be fast. Sometimes, fast enough
works. Probably even most of the time.

On Tue, Feb 16, 2016 at 3:36 PM, John Syne  wrote:

> The benefit of Python is the easy interface to C code, which means that
> when your algorithm is slow, you can reimplement that code in C but keep
> the benefit of writing in a more feature rich language like Python.
>
> Regards,
> John
>
>
>
>
> On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote:
>
> @William, I love to work with C.
> But, the thing is I want to implement machine learning algorithms in
> BeagleBone.
> So, it is quite easier to implement them with Python or R, as their are
> some
> dedicated packages to analyze the data.
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] R or Python cross compiler for beaglebone

[William Hermans]

>
> *The OP said he has algorithms already written in Python so I was pointing
> out that if he need to improve performance, it is easy to do. Anyway, you
> know that most build systems like Openembedded, yocto, etc, all use Python?
> If it was so slow, they wouldn’t be using it. Now I’m wondering why they
> just don’t write the whole thing in C ;-)*
> *Regards,*
>
*John*

I kind of like the idea behind interfaces in C for Python . . . I just
don't like Python. So John, if you read my posts above you'd know that I
know that Python is a requirement for building Linux systems. Python Perl,
and C are all required. I said "Ruby" above, but meant Perl. In my mind
they're both equivalent( garbage, but useful I guess ), hence my mistake
Anyway . . .

There are machine learning libraries for C . . . No idea if a specific one
out there would fit the bill for the OP though. Not my job to look into all
that.


On Tue, Feb 16, 2016 at 4:45 PM, John Syne  wrote:

> The OP said he has algorithms already written in Python so I was pointing
> out that if he need to improve performance, it is easy to do. Anyway, you
> know that most build systems like Openembedded, yocto, etc, all use Python?
> If it was so slow, they wouldn’t be using it. Now I’m wondering why they
> just don’t write the whole thing in C ;-)
>
> Regards,
> John
>
>
>
>
> On Feb 16, 2016, at 3:21 PM, William Hermans  wrote:
>
> First, "the interface" is slow: meaning the run time. But if you have to
> "reinvent" a Python API / BCL because it is slow - And do that in C. Why
> not just use C to begin with ?
>
> Aside from Python forcing coding guidelines on it users, it's a fine
> language. What it is  not though, is a good language when you need pure all
> out performance. But not all code needs to be fast. Sometimes, fast enough
> works. Probably even most of the time.
>
> On Tue, Feb 16, 2016 at 3:36 PM, John Syne  wrote:
>
>> The benefit of Python is the easy interface to C code, which means that
>> when your algorithm is slow, you can reimplement that code in C but keep
>> the benefit of writing in a more feature rich language like Python.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote:
>>
>> @William, I love to work with C.
>> But, the thing is I want to implement machine learning algorithms in
>> BeagleBone.
>> So, it is quite easier to implement them with Python or R, as their are
>> some
>> dedicated packages to analyze the data.
>>
>> --
>> 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.
>> 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.
>> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

I don't know. I've compiled Nodejs from source on the BBB and it does not
take too long. A bit over an hour. My buddy here compiled Wireshark on the
BBB though, and that took half a day or more. Plus we had to setup a USB
hard drive as swap in order for it to succeed.

However, my thinking is this. My buddy spent several days trying to figure
out how to cross compile Wireshark for armhf, and ultimately failed. By
comparison, he setup a build system, on the BBB, then initially failed
because of oom, then asked me what he could do. Where I suggested he setup
a USB Hard drive as swap, and it worked. SO maybe 1.5-2 days total time
investment.

So the thinking is, you could spend a very long time attempting to setup a
cross compile system for one thing or another( and yes they're all
different ), but ultimately fail. *Or* you can set things up on the BBB,
and let is run off in the corner for a day or two to do it's thing, and be
done.

Now, If you can find exact step instructions, or have a reasonably easy
time setting a cross compile system for whatever. I say go for it. a Good
guide already exists for compiling the kernel etc. And yes there are a few
other decent guides for various other things too. But if all you need is a
one time compile for somethign that does not exist, or needs to be
recompiled for a specific feature . . . don't waste your life away trying
to figure out how to cross compile a complex project yourself . . . life is
too short.

On Tue, Feb 16, 2016 at 5:17 PM, Adi Linden  wrote:

> I am thinking that something with more RAM and some high speed disk
> option, USB3 or SATA, would make sense.  Compiling anything but the
> smallest projects on a BBB or original Raspberry Pi is painfully slow.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help! ADC 'stopped working' overnight

[William Hermans]

well, if you have issues finding the bug, post the code. I'm sure someone
will be able to spot / find it.

On Wed, Feb 17, 2016 at 3:10 AM, hllpc  wrote:

> Apologies for the delay,
> I spilled coffee on my notebook and it died.
>
> BBB rebooted
>
> root@arm:/home/debian# ls /lib/firmware/ | grep ADC
> BB-ADC-00A0.dtbo
>
> root@arm:/home/debian# sudo sh -c "echo 'BB-ADC' >
> /sys/devices/bone_capemgr.9/slots"
>
> root@arm:~# dmesg | grep BB-ADC
> [  214.438002] bone-capemgr bone_capemgr.9: part_number 'BB-ADC', version
> 'N/A'
> [  214.438290] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
> Name,00A0,Override Manuf,BB-ADC'
> [  214.438792] bone-capemgr bone_capemgr.9: slot #7: Requesting part
> number/version based 'BB-ADC-00A0.dtbo
> [  214.444710] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
> 'BB-ADC-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [  214.444798] bone-capemgr bone_capemgr.9: slot #7: dtbo
> 'BB-ADC-00A0.dtbo' loaded; converting to live tree
>
> root@arm:~# lsmod
> Module  Size  Used by
> g_multi47670  0
> libcomposite   14299  1 g_multi
> arc41660  2
> rtl8192cu  73560  0
> rtlwifi63798  1 rtl8192cu
> rtl8192c_common51523  1 rtl8192cu
> mac80211  411868  3 rtlwifi,rtl8192c_common,rtl8192cu
> cfg80211  344277  2 mac80211,rtlwifi
> rfkill 16656  2 cfg80211
> uio_pruss   3865  0
>
> no adc module!
> but there is an entrz in the devices durectorz, so I think the module has
> been loaded correctly:
> root@arm:/sys/bus/iio/devices/iio:device0# ls
> dev  in_voltage2_raw  in_voltage5_raw  name   uevent
> in_voltage0_raw  in_voltage3_raw  in_voltage6_raw  power
> in_voltage1_raw  in_voltage4_raw  in_voltage7_raw  subsystem
>  with no input:
> root@arm:/sys/bus/iio/devices/iio:device0# cat in_voltage0_raw
> 3760
>
> compiling test.c with time iI got the awaited result:
> ..
> 3883 3898 3914 3912 3918 3913 3913 3919 3914 3916
> real 3.826  user 0.002  sys 2.639   pcpu 69.01
>
>
> So I guess the problem lies in the program..
>
>
>
>
>
> Il giorno martedì 16 febbraio 2016 21:40:06 UTC+1, William Hermans ha
> scritto:
>>
>> OK, so another possibility does come to mind. The values you're reading
>> are somehow becoming corrupt before you check them. So humor me here, and
>> honestly this is probably in your best interest anyhow. . .
>>
>>
>>1. Reset your board, which is to say, reboot it, and make sure none
>>of your stuff for the ADC loads at boot.
>>2. Follow my guide here, but keep in mind it is based on 4.x kernels.
>>So adjustments may have to be made
>>http://www.embeddedhobbyist.com/2015/10/beaglebone-black-ad
>>3. Use the sysfs method of reading values out of the ADC, single shot
>>to double check raw values.
>>
>> So, again, my guide above is meant for kernels 4.x but should work for
>> the most part. File locations, and in where to echo to load capes is
>> different, and I'm not sure what else. The point is that you need an
>> alternate way of testing your ADC, and making sure it is not somehow your
>> code. Let me know if this fixes the values read out, and if it does, we'll
>> have to pour through your code.
>>
>> On Tue, Feb 16, 2016 at 12:53 PM, hllpc  wrote:
>>
>>>
>>> Higher like 40k, in the firt piat i wrote that the "translated" value is
>>> 11 volt.
>>> But it's variable, start from 0 and then invrease. Or somethime it's all
>>> zeroes, or only numbers repeated like 11 12 14 all over again
>>> Il giorno martedì 16 febbraio 2016 20:43:21 UTC+1, William Hermans ha
>>> scritto:
>>>>
>>>> OK, so define "way higher". Higher than 4095 ?
>>>>
>>>> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
>>>>
>>>>> Yes I know about the conversion raw values-> real values, two days ago
>>>>> the raw values where in the range0-2000 as they should have been, now they
>>>>> are way way higher
>>>>>
>>>>> --
>>>>> 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 g

Re: [beagleboard] regarding how to make beaglebone as a web server to turn on/off led onboard.

[William Hermans]

What it boils down to short and simple with Nodejs is Nodejs + express +
filesystemWrite(). Then you just write 0 or 1 to the appropriate gpio sysfs
file handle. From here you may / may not run into permissions "issues" but
thats a separate subject. But to keep it simple, you put the user the
Nodejs app runs as in the same group that has permissions for the sysfs
pseudo files for gpio . .. or you can run the Nodejs app as root, short
term to test.

On Wed, Feb 17, 2016 at 12:01 PM, John Syne  wrote:

> I don’t know php, but doing the same with Node.js is very simple. Simply
> search google for “beaglebone node.js gpio” for examples.
>
> Regards,
> John
>
>
>
>
> On Feb 17, 2016, at 1:52 AM, cynid...@gmail.com wrote:
>
> i wanted to turn on and off my onboard led by making beaglebone board only
> as a central server by making a php web page and turn on/off the led
> through that php web server so how can i made this and also how can i just
> turn the led on/ off through a smart phone, please be needful, i am
> literally stuck around this..
>
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] R or Python cross compiler for beaglebone

[William Hermans]

quick worklog, but do note that I used a 4GB USB thumb drive to make things
easier( so as not to have to format an existing USB hard drive ).
http://pastebin.com/1zEFAYM3

Do note that the only thing you need to fstab is:



*UUID=1808bf31-3313-44e6-b063-2d4d81f02e9e none swap sw,pri=5 0 0*
But do keep in mind your UUID will be different.

Anyway, I'll probably write up a blog on this to have a link for additional
queries. But It'll probably at minimum take me a few hours to get around to
it.

On Tue, Feb 16, 2016 at 5:14 PM, William Hermans  wrote:

> *The OP said he has algorithms already written in Python so I was pointing
>> out that if he need to improve performance, it is easy to do. Anyway, you
>> know that most build systems like Openembedded, yocto, etc, all use Python?
>> If it was so slow, they wouldn’t be using it. Now I’m wondering why they
>> just don’t write the whole thing in C ;-)*
>> *Regards,*
>>
> *John*
>
> I kind of like the idea behind interfaces in C for Python . . . I just
> don't like Python. So John, if you read my posts above you'd know that I
> know that Python is a requirement for building Linux systems. Python Perl,
> and C are all required. I said "Ruby" above, but meant Perl. In my mind
> they're both equivalent( garbage, but useful I guess ), hence my mistake
> Anyway . . .
>
> There are machine learning libraries for C . . . No idea if a specific one
> out there would fit the bill for the OP though. Not my job to look into all
> that.
>
>
> On Tue, Feb 16, 2016 at 4:45 PM, John Syne  wrote:
>
>> The OP said he has algorithms already written in Python so I was pointing
>> out that if he need to improve performance, it is easy to do. Anyway, you
>> know that most build systems like Openembedded, yocto, etc, all use Python?
>> If it was so slow, they wouldn’t be using it. Now I’m wondering why they
>> just don’t write the whole thing in C ;-)
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 16, 2016, at 3:21 PM, William Hermans  wrote:
>>
>> First, "the interface" is slow: meaning the run time. But if you have to
>> "reinvent" a Python API / BCL because it is slow - And do that in C. Why
>> not just use C to begin with ?
>>
>> Aside from Python forcing coding guidelines on it users, it's a fine
>> language. What it is  not though, is a good language when you need pure all
>> out performance. But not all code needs to be fast. Sometimes, fast enough
>> works. Probably even most of the time.
>>
>> On Tue, Feb 16, 2016 at 3:36 PM, John Syne  wrote:
>>
>>> The benefit of Python is the easy interface to C code, which means that
>>> when your algorithm is slow, you can reimplement that code in C but keep
>>> the benefit of writing in a more feature rich language like Python.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote:
>>>
>>> @William, I love to work with C.
>>> But, the thing is I want to implement machine learning algorithms in
>>> BeagleBone.
>>> So, it is quite easier to implement them with Python or R, as their are
>>> some
>>> dedicated packages to analyze the data.
>>>
>>> --
>>> 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.
>>> 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.
>>> 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.
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can't connect through 192.168.7.2.

[William Hermans]

>
> *Smart people believe, that not sharing knowledge will keep you smarter
> then anyone else.*
>

"Smart people" also probably know the difference between *then* and *than, *and
know when it is appropriate to use one rather than the other.

On Wed, Feb 17, 2016 at 2:41 PM, Rudie van Willigen 
wrote:

> Smart people believe, that not sharing knowledge will keep you smarter
> then anyone else.
>
>
> 2016-02-17 22:34 GMT+01:00 Rudie van Willigen :
>
>>  Forget it, thanks
>>
>> 2016-02-14 19:33 GMT+01:00 Rudie van Willigen :
>>
>>> can't connect through 192.168.7.2.
>>> reset doesn't help
>>> Led's:
>>> USR0 blinks fast(faster then the usual heartbeat)
>>> USR2 blinks 2x the speed of  USR0
>>>
>>> BBB 1 week old and has worked properly all the time with putty
>>> and BB.org homepage "Getting started" and VNCserver
>>> only connection is USB, no SD and original Debian-Linux OS and nothing
>>> changed
>>>
>>>
>>> --
>>> 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/Rinhtx40QEk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to set WIFI in Debian?

[William Hermans]

Jason,

Perhaps a Nodejs app linked in the getting started pages. That have
"button" to switch on / off desired behavior. g_ether, g_serial, etc.

Another thing I was curious about. Is why does a wireless network device
need a network manager running at all ? I don't know . . .I've always used
/ preferred wired networking.

Additionally, perhaps it is time to stop trying to automate DNS, and just
have instructions on how to manually set gateway / IP address on each
possible host system type ? This way, you manually set USB0 as 192.168.7.2,
and the host gets set to 192.168.7.1 manually by the user at setup time. Or
perhaps have a script for the 3 main OSes to set this up automatically ?
Linux and OSX should be easy, but Windows . .. no idea how this could be
done with powershell . . .

Anyway, just thinking out loud.

On Wed, Feb 17, 2016 at 2:39 PM, Brian Anderson  wrote:

> Jason, this is excellent!  Having something along the lines of what you
> call out here out of the box would be great, especially if it was very
> clear how to "configure" said setup w/o having to resort to "legacy" (e.g.
> ifup/down/config) tools.
>
> This would also be especially useful with future/planned boards that have
> builtin WiFi and/or BT.  And as a stretch, maybe even an iOS/Android
> companion app to help with setup/onboarding.  I understand that the BBB is
> supposed to be an embedded systems "learning" platform, so maybe having
> something so consumer friendly is asking a lot.  Even so, there seems to be
> an inordinate number of issues posted here concerning initial networking
> setup, so maybe something like this isn't so far off track as many people
> struggle with this.  Addressing the whole "onboarding" issue is also a huge
> deal for anyone considering what it takes to make a consumer friendly
> device.  A reference implementation would be a great learning experience.
> There are not a lot (maybe no) open source solutions to this problem.  I do
> know that the AllJoyn folks have defined an OnBoarding service spec to help
> address this, but there isn't much as far as implementation here yet.
> There may be other efforts (OIC?), but I am unaware of them.
>
> Good thoughts!
>
> ba
>
> On Wednesday, February 17, 2016 at 8:39:24 AM UTC-8, Jason Kridner wrote:
>>
>> Perhaps we need to fully define the requirement such that experts can
>> provide the lowest memory and least complex solution?
>>
>> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to set WIFI in Debian?

[William Hermans]

@Robert,

That not the point I was attempting to convey. I've never setup a wireless
device in Linux *ever*, so I've no idea if it is as simple as setting up
ethernet connections. With ethernet, I *always* manually set IP, gateway,
network, and all that in the interfaces file.

Anything stopping one from doing the same with wireless adapters ?

On Wed, Feb 17, 2016 at 3:00 PM, Robert Nelson 
wrote:

> On Wed, Feb 17, 2016 at 3:56 PM, William Hermans 
> wrote:
> > Jason,
> >
> > Perhaps a Nodejs app linked in the getting started pages. That have
> "button"
> > to switch on / off desired behavior. g_ether, g_serial, etc.
> >
> > Another thing I was curious about. Is why does a wireless network device
> > need a network manager running at all ? I don't know . . .I've always
> used /
> > preferred wired networking.
>
> I've seen a "device" with only wireless and usb-otg...
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to set WIFI in Debian?

[William Hermans]

Hmm, I guess no one knows then. Either that, or I'm dealing with a bunch of
"smart people" here . . . heh.

On Wed, Feb 17, 2016 at 3:10 PM, William Hermans  wrote:

> @Robert,
>
> That not the point I was attempting to convey. I've never setup a wireless
> device in Linux *ever*, so I've no idea if it is as simple as setting up
> ethernet connections. With ethernet, I *always* manually set IP, gateway,
> network, and all that in the interfaces file.
>
> Anything stopping one from doing the same with wireless adapters ?
>
> On Wed, Feb 17, 2016 at 3:00 PM, Robert Nelson 
> wrote:
>
>> On Wed, Feb 17, 2016 at 3:56 PM, William Hermans 
>> wrote:
>> > Jason,
>> >
>> > Perhaps a Nodejs app linked in the getting started pages. That have
>> "button"
>> > to switch on / off desired behavior. g_ether, g_serial, etc.
>> >
>> > Another thing I was curious about. Is why does a wireless network device
>> > need a network manager running at all ? I don't know . . .I've always
>> used /
>> > preferred wired networking.
>>
>> I've seen a "device" with only wireless and usb-otg...
>>
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] R or Python cross compiler for beaglebone

[William Hermans]

OK so further checking, the listing in fstab does not seem to work. I'll
have to look into it when I get some free time.

On Wed, Feb 17, 2016 at 2:42 PM, William Hermans  wrote:

> quick worklog, but do note that I used a 4GB USB thumb drive to make
> things easier( so as not to have to format an existing USB hard drive ).
> http://pastebin.com/1zEFAYM3
>
> Do note that the only thing you need to fstab is:
>
>
>
> *UUID=1808bf31-3313-44e6-b063-2d4d81f02e9e none swap sw,pri=5 0 0*
> But do keep in mind your UUID will be different.
>
> Anyway, I'll probably write up a blog on this to have a link for
> additional queries. But It'll probably at minimum take me a few hours to
> get around to it.
>
> On Tue, Feb 16, 2016 at 5:14 PM, William Hermans 
> wrote:
>
>> *The OP said he has algorithms already written in Python so I was
>>> pointing out that if he need to improve performance, it is easy to do.
>>> Anyway, you know that most build systems like Openembedded, yocto, etc, all
>>> use Python? If it was so slow, they wouldn’t be using it. Now I’m wondering
>>> why they just don’t write the whole thing in C ;-)*
>>> *Regards,*
>>>
>> *John*
>>
>> I kind of like the idea behind interfaces in C for Python . . . I just
>> don't like Python. So John, if you read my posts above you'd know that I
>> know that Python is a requirement for building Linux systems. Python Perl,
>> and C are all required. I said "Ruby" above, but meant Perl. In my mind
>> they're both equivalent( garbage, but useful I guess ), hence my mistake
>> Anyway . . .
>>
>> There are machine learning libraries for C . . . No idea if a specific
>> one out there would fit the bill for the OP though. Not my job to look into
>> all that.
>>
>>
>> On Tue, Feb 16, 2016 at 4:45 PM, John Syne  wrote:
>>
>>> The OP said he has algorithms already written in Python so I was
>>> pointing out that if he need to improve performance, it is easy to do.
>>> Anyway, you know that most build systems like Openembedded, yocto, etc, all
>>> use Python? If it was so slow, they wouldn’t be using it. Now I’m wondering
>>> why they just don’t write the whole thing in C ;-)
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Feb 16, 2016, at 3:21 PM, William Hermans  wrote:
>>>
>>> First, "the interface" is slow: meaning the run time. But if you have to
>>> "reinvent" a Python API / BCL because it is slow - And do that in C. Why
>>> not just use C to begin with ?
>>>
>>> Aside from Python forcing coding guidelines on it users, it's a fine
>>> language. What it is  not though, is a good language when you need pure all
>>> out performance. But not all code needs to be fast. Sometimes, fast enough
>>> works. Probably even most of the time.
>>>
>>> On Tue, Feb 16, 2016 at 3:36 PM, John Syne  wrote:
>>>
>>>> The benefit of Python is the easy interface to C code, which means that
>>>> when your algorithm is slow, you can reimplement that code in C but keep
>>>> the benefit of writing in a more feature rich language like Python.
>>>>
>>>> Regards,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote:
>>>>
>>>> @William, I love to work with C.
>>>> But, the thing is I want to implement machine learning algorithms in
>>>> BeagleBone.
>>>> So, it is quite easier to implement them with Python or R, as their are
>>>> some
>>>> dedicated packages to analyze the data.
>>>>
>>>> --
>>>> 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.
>>>> 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 

Re: [beagleboard] R or Python cross compiler for beaglebone

[William Hermans]

It's in relation to using a UUID instead of  /dev/sdx. I've never had good
luck using UUID's, probably because I do not really know much in way of
using them properly.

Also I used the drive object directly when I probably should have targeted
the partition instead.



On Wed, Feb 17, 2016 at 4:17 PM, William Hermans  wrote:

> OK so further checking, the listing in fstab does not seem to work. I'll
> have to look into it when I get some free time.
>
> On Wed, Feb 17, 2016 at 2:42 PM, William Hermans 
> wrote:
>
>> quick worklog, but do note that I used a 4GB USB thumb drive to make
>> things easier( so as not to have to format an existing USB hard drive ).
>> http://pastebin.com/1zEFAYM3
>>
>> Do note that the only thing you need to fstab is:
>>
>>
>>
>> *UUID=1808bf31-3313-44e6-b063-2d4d81f02e9e none swap sw,pri=5 0 0*
>> But do keep in mind your UUID will be different.
>>
>> Anyway, I'll probably write up a blog on this to have a link for
>> additional queries. But It'll probably at minimum take me a few hours to
>> get around to it.
>>
>> On Tue, Feb 16, 2016 at 5:14 PM, William Hermans 
>> wrote:
>>
>>> *The OP said he has algorithms already written in Python so I was
>>>> pointing out that if he need to improve performance, it is easy to do.
>>>> Anyway, you know that most build systems like Openembedded, yocto, etc, all
>>>> use Python? If it was so slow, they wouldn’t be using it. Now I’m wondering
>>>> why they just don’t write the whole thing in C ;-)*
>>>> *Regards,*
>>>>
>>> *John*
>>>
>>> I kind of like the idea behind interfaces in C for Python . . . I just
>>> don't like Python. So John, if you read my posts above you'd know that I
>>> know that Python is a requirement for building Linux systems. Python Perl,
>>> and C are all required. I said "Ruby" above, but meant Perl. In my mind
>>> they're both equivalent( garbage, but useful I guess ), hence my mistake
>>> Anyway . . .
>>>
>>> There are machine learning libraries for C . . . No idea if a specific
>>> one out there would fit the bill for the OP though. Not my job to look into
>>> all that.
>>>
>>>
>>> On Tue, Feb 16, 2016 at 4:45 PM, John Syne  wrote:
>>>
>>>> The OP said he has algorithms already written in Python so I was
>>>> pointing out that if he need to improve performance, it is easy to do.
>>>> Anyway, you know that most build systems like Openembedded, yocto, etc, all
>>>> use Python? If it was so slow, they wouldn’t be using it. Now I’m wondering
>>>> why they just don’t write the whole thing in C ;-)
>>>>
>>>> Regards,
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 16, 2016, at 3:21 PM, William Hermans  wrote:
>>>>
>>>> First, "the interface" is slow: meaning the run time. But if you have
>>>> to "reinvent" a Python API / BCL because it is slow - And do that in C. Why
>>>> not just use C to begin with ?
>>>>
>>>> Aside from Python forcing coding guidelines on it users, it's a fine
>>>> language. What it is  not though, is a good language when you need pure all
>>>> out performance. But not all code needs to be fast. Sometimes, fast enough
>>>> works. Probably even most of the time.
>>>>
>>>> On Tue, Feb 16, 2016 at 3:36 PM, John Syne  wrote:
>>>>
>>>>> The benefit of Python is the easy interface to C code, which means
>>>>> that when your algorithm is slow, you can reimplement that code in C but
>>>>> keep the benefit of writing in a more feature rich language like Python.
>>>>>
>>>>> Regards,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote:
>>>>>
>>>>> @William, I love to work with C.
>>>>> But, the thing is I want to implement machine learning algorithms in
>>>>> BeagleBone.
>>>>> So, it is quite easier to implement them with Python or R, as their
>>>>> are some
>>>>> dedicated packages to analyze the data.
>>>>>
>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You

Re: [beagleboard] How to set WIFI in Debian?

[William Hermans]

>
> *I guess I’m not one of those “smart people"*
>

hah !

I think ideally I'd much rather set wifi up manually if it was not too much
of a hassle. Time is one thing, but pulling what's left of your hair out
for a week is not really my idea of fun.

As for googling, I would probably not use beaglebone for a keyword at all,
and just start googling "linux manual wifi setup" or some such keywords.
But if it's like bluetooth, which is also somewhat complicated. It can be
done.

On Wed, Feb 17, 2016 at 4:18 PM, John Syne  wrote:

> Setting up Wifi is way more complicated that ethernet because of the
> wireless settings and then there is the security setup like WPA2, etc and
> that is done before you start with the regular IP settins. Best to search
> Google “beaglebone wifi setup” which has lots of examples. I know the first
> time I did this, it took me all day, but that was years ago ;-) I guess I’m
> not one of those “smart people"
>
> Regards,
> John
>
>
>
>
> On Feb 17, 2016, at 2:53 PM, William Hermans  wrote:
>
> Hmm, I guess no one knows then. Either that, or I'm dealing with a bunch
> of "smart people" here . . . heh.
>
> On Wed, Feb 17, 2016 at 3:10 PM, William Hermans 
> wrote:
>
>> @Robert,
>>
>> That not the point I was attempting to convey. I've never setup a
>> wireless device in Linux *ever*, so I've no idea if it is as simple as
>> setting up ethernet connections. With ethernet, I *always* manually set IP,
>> gateway, network, and all that in the interfaces file.
>>
>> Anything stopping one from doing the same with wireless adapters ?
>>
>> On Wed, Feb 17, 2016 at 3:00 PM, Robert Nelson 
>> wrote:
>>
>>> On Wed, Feb 17, 2016 at 3:56 PM, William Hermans 
>>> wrote:
>>> > Jason,
>>> >
>>> > Perhaps a Nodejs app linked in the getting started pages. That have
>>> "button"
>>> > to switch on / off desired behavior. g_ether, g_serial, etc.
>>> >
>>> > Another thing I was curious about. Is why does a wireless network
>>> device
>>> > need a network manager running at all ? I don't know . . .I've always
>>> used /
>>> > preferred wired networking.
>>>
>>> I've seen a "device" with only wireless and usb-otg...
>>>
>>> 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.
>>> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to set WIFI in Debian?

[William Hermans]

The biggest problem I have with using network managers is that "they" tend
to get into the way too much. I really do not like a bit of software( be is
scripts, or whatever ) thinking it is smarter than I. So when I "put my
foot down" and do something manually, I mean it, and want it in place. But
that's not how these network managers seem to work . . .

On Wed, Feb 17, 2016 at 5:00 PM, William Hermans  wrote:

> *I guess I’m not one of those “smart people"*
>>
>
> hah !
>
> I think ideally I'd much rather set wifi up manually if it was not too
> much of a hassle. Time is one thing, but pulling what's left of your hair
> out for a week is not really my idea of fun.
>
> As for googling, I would probably not use beaglebone for a keyword at all,
> and just start googling "linux manual wifi setup" or some such keywords.
> But if it's like bluetooth, which is also somewhat complicated. It can be
> done.
>
> On Wed, Feb 17, 2016 at 4:18 PM, John Syne  wrote:
>
>> Setting up Wifi is way more complicated that ethernet because of the
>> wireless settings and then there is the security setup like WPA2, etc and
>> that is done before you start with the regular IP settins. Best to search
>> Google “beaglebone wifi setup” which has lots of examples. I know the first
>> time I did this, it took me all day, but that was years ago ;-) I guess I’m
>> not one of those “smart people"
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 17, 2016, at 2:53 PM, William Hermans  wrote:
>>
>> Hmm, I guess no one knows then. Either that, or I'm dealing with a bunch
>> of "smart people" here . . . heh.
>>
>> On Wed, Feb 17, 2016 at 3:10 PM, William Hermans 
>> wrote:
>>
>>> @Robert,
>>>
>>> That not the point I was attempting to convey. I've never setup a
>>> wireless device in Linux *ever*, so I've no idea if it is as simple as
>>> setting up ethernet connections. With ethernet, I *always* manually set IP,
>>> gateway, network, and all that in the interfaces file.
>>>
>>> Anything stopping one from doing the same with wireless adapters ?
>>>
>>> On Wed, Feb 17, 2016 at 3:00 PM, Robert Nelson 
>>> wrote:
>>>
>>>> On Wed, Feb 17, 2016 at 3:56 PM, William Hermans 
>>>> wrote:
>>>> > Jason,
>>>> >
>>>> > Perhaps a Nodejs app linked in the getting started pages. That have
>>>> "button"
>>>> > to switch on / off desired behavior. g_ether, g_serial, etc.
>>>> >
>>>> > Another thing I was curious about. Is why does a wireless network
>>>> device
>>>> > need a network manager running at all ? I don't know . . .I've always
>>>> used /
>>>> > preferred wired networking.
>>>>
>>>> I've seen a "device" with only wireless and usb-otg...
>>>>
>>>> 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.
>>>> 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.
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

> I wonder if the memory of a rPI2 would be an advantage over the BBB?

In the context of a build system, Of course it is. In the context of
running every day doing *something* embedded . . . It really depends, but
most of the time it would make very little if any difference.

On Wed, Feb 17, 2016 at 7:52 PM, Adi Linden  wrote:

> USB3 SSD sounds quite reasonable.  I wonder if the memory of a rPI2 would
> be an advantage over the BBB?
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

>
> *Definitely looking at it from a build system point of view.  For every
> day I have found 512MB more then plenty except for the occasional need of a
> ramdisk where more is better, I suppose.*
>

My experiences over the last 3 or so years with the BBB lead me to believe
that if you're smart, the amount of memory this board has does not really
matter.

That is for example. I wrote an application in C that would read from the
CANBUS, decode the data coming over that bus at 1Mbit/s, format it, and
then send the decoded / formated data out over a websocket. All in all,
this was 4 separate processes, working towards that end. 3 Of those process
were used to read individual fastpacket 2000 PGN's. One unique PGN per
process, while the fourth process was a web/websocket server written in C(
using libmongoose ).

All these processes were pretty busy, using up a a good bit of processor
time if I let them. But the processes hardly ever used more than ~85MB ram
unless I was doing some sort of "system maintenance" while these processes
were running.

Anyway, my point here is that I think that for most situations, you can use
up half the BBB's RAM ( 256MB ), and still be in very good shape. But you
can not be doing something silly like running a full blown desktop - At the
same time.

On Wed, Feb 17, 2016 at 8:03 PM, Adi Linden  wrote:

>
> In the context of a build system, Of course it is. In the context of
>> running every day doing *something* embedded . . . It really depends, but
>> most of the time it would make very little if any difference.
>>
>
> Definitely looking at it from a build system point of view.  For every day
> I have found 512MB more then plenty except for the occasional need of a
> ramdisk where more is better, I suppose.
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 as a Build Machine

[William Hermans]

Well, I mean you can in many cases use up haf the RAM for a tmpfs ramdisk.
So in the context of running a web server, you could theoretically do that
without ever touching the onboard flash media, or sdcard.

On Wed, Feb 17, 2016 at 8:23 PM, William Hermans  wrote:

> *Definitely looking at it from a build system point of view.  For every
>> day I have found 512MB more then plenty except for the occasional need of a
>> ramdisk where more is better, I suppose.*
>>
>
> My experiences over the last 3 or so years with the BBB lead me to believe
> that if you're smart, the amount of memory this board has does not really
> matter.
>
> That is for example. I wrote an application in C that would read from the
> CANBUS, decode the data coming over that bus at 1Mbit/s, format it, and
> then send the decoded / formated data out over a websocket. All in all,
> this was 4 separate processes, working towards that end. 3 Of those process
> were used to read individual fastpacket 2000 PGN's. One unique PGN per
> process, while the fourth process was a web/websocket server written in C(
> using libmongoose ).
>
> All these processes were pretty busy, using up a a good bit of processor
> time if I let them. But the processes hardly ever used more than ~85MB ram
> unless I was doing some sort of "system maintenance" while these processes
> were running.
>
> Anyway, my point here is that I think that for most situations, you can
> use up half the BBB's RAM ( 256MB ), and still be in very good shape. But
> you can not be doing something silly like running a full blown desktop - At
> the same time.
>
> On Wed, Feb 17, 2016 at 8:03 PM, Adi Linden  wrote:
>
>>
>> In the context of a build system, Of course it is. In the context of
>>> running every day doing *something* embedded . . . It really depends, but
>>> most of the time it would make very little if any difference.
>>>
>>
>> Definitely looking at it from a build system point of view.  For every
>> day I have found 512MB more then plenty except for the occasional need of a
>> ramdisk where more is better, I suppose.
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can't connect through 192.168.7.2.

[William Hermans]

So, with this problem, there are so many possible different causes for this
specific failure there is no way anyone can answer this question without
more information.

It's a bit like me saying "Hey someone help me, my car does not work . .
.r"

Doesn't work how ? What have you( I ) done so far to troubleshoot the issue
?  We're not mind readers . . .

On Thu, Feb 18, 2016 at 4:47 AM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Wed, Feb 17, 2016 at 4:41 PM, Rudie van Willigen
>  wrote:
> > Smart people believe, that not sharing knowledge will keep you smarter
> then
> > anyone else.
> >
> I'm actually curious what happened and how you solved your
> problem---could you find a moment to explain this, for others'
> benefit? I hope you don't take the above as your personal credo...
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

>
> *Is it possible to write pure assembler code like with the PASM and make
> the code work for the newer remoteproc? Or can I write assembly code in
> CodeComposer Studio with the TI compiler? I couldn't figure out yet how I
> can do that. Is there a Tutorial somewhere?*
>

So just like any other language in Linux, I'm sure you could write
remoteproc completely in assembly. But there is no Assembler like
originally for PRU's, that I'm aware of.

However, I think the more important question would be why on earth would
you want to write code for remoteproc / rpmsg in assembler ? The whole idea
of remoteproc / rpmsg is to abstract many of those low level details, to
make using multiple processors in this way much easier.

On Fri, Feb 19, 2016 at 1:05 PM, John Syne  wrote:

> I recommend that you develop your code in C and then hand optimize the
> assembler where required. This helps document your code and make it more
> manageable. I have used CCSV6 for developing PRU apps and I think the
> support is pretty good. Make sure you use the scripts to configure the
> processor memory map and bring the PRU out of reset or you will have all
> kinds of issues when debugging. I have used both XDS200 and Blackhawk
> USB560M JTAG emulators and they both work without issue.
>
> Regards,
> John
>
>
>
>
> On Feb 19, 2016, at 10:34 AM, n.dam...@web.de wrote:
>
>
> Hi,
>
> I'm using the AM335X Starter Kit from TI with an AM3359 SoC and I use the
> TI Processor SDK Linux version 02.00.01.07. I managed to get remoteproc
> driver working, then I removed the Display module and used the flatflex
> connector to breakout some GPIOs of PRU1 to hook up some LEDs. I wrote a
> blink-led firmware in CCS v6 as described in the PRU HandsOn Lab and
> successfully bootet the PRU1 to let my LEDs blink.
>
> Now I need to write a very fast code so I have to write it in Assembly
> language. I would like to use the AM335x PRU-ICSS Reference Guide to write
> my code and use the PASM compiler.
>
> Is it possible to write pure assembler code like with the PASM and make
> the code work for the newer remoteproc? Or can I write assembly code in
> CodeComposer Studio with the TI compiler? I couldn't figure out yet how I
> can do that. Is there a Tutorial somewhere?
>
> I read that TI does not support PRU so good so this is why I ask here.
>
> Regards
> Nico
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] AM5718

[William Hermans]

>
> *Although every board has an appropriate niche, the problem with the X15
> from the PoV of BBB users is that its niche is not the BBB's niche.*
>

As has been stated many times over now. The X15 is not in the same "class"
as the Beaglebone boards, but in the same class as the original
beagleboards. With much newer and updated features of course. Cost wise,
beagleboards have always been higher than beaglebones . . .

Another thing to consider is that the X15 has so many features, and
features that far surpass those on the beaglebones, it makes the beaglebone
boards look like toys. So in other words is something more along the lines
of a dev board for the professional, and not the hobbyist.

With al that said, I too have a "dream" of a board I'd like to see as well.
an  AM5718 with networking, and USB only as "out of the box" peripherals
only. With the rest of the on chip peripherals out to some form of a high
density pin header. Granted, onboard eMMC, ad an sdcard reader would
probably be good too now that I think of that.

Anyhow, a minimal board, something like the beaglebone black, but without
hdmi would be awesome. Size for me would not be too important though. As
the X15 really is not all that big to begin with. Anyhow, my "dream" board
seems pretty close to the already existing x15 . . .

On Fri, Feb 19, 2016 at 11:42 AM, 'Morgaine' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Drew writes:
> *> BeagleBone Plaid... I sense a best seller! :)*
>
> I wouldn't hold that against it.  A haggis in the box would be a step too
> far though. :P
>
> On Fri, Feb 19, 2016 at 6:26 PM, Morgaine 
> wrote:
>
>> Although every board has an appropriate niche, the problem with the X15
>> from the PoV of BBB users is that its niche is not the BBB's niche.
>>
>> While the X15 is certainly interesting, it's not going to help those BBB
>> users who would like a little more power at a little more cost within the
>> BBB form factor.  X15 comes in at a much higher price point, and this puts
>> it out of contention for many small IoT tasks where the BBB's cost is seen
>> as reasonable.
>>
>> BBB has become very popular and a lot of people would like to see the
>> line extended with an upgraded processor, as you know since it's been a
>> regular suggestion here.  I'm sure you would fill this product space if you
>> could, but I suppose TI's "$5 AM335x" launch many moons ago was a one-off.
>> Pity.
>>
>> Morgaine.
>>
>>
>> On Fri, Feb 19, 2016 at 5:21 PM, Gerald Coley 
>> wrote:
>>
>>> A lot bigger than the BBG, more expensive than the BBG, no support for
>>> the expansion connectors on the BBG and most likely, a different color.
>>>
>>> A lot smaller than the X15, less expensive than the X15, no support for
>>> the expansion connectors on the X15, and most likely a plaid color.
>>>
>>>
>>> Gerald.
>>>
>>> On Fri, Feb 19, 2016 at 11:17 AM, 'Morgaine' via BeagleBoard <
>>> beagleboard@googlegroups.com> wrote:
>>>
 Jason writes:
 *> If someone contributed an open design, that might help push the idea
 along. Not sure how much cheaper it could be than X15. *

 How would the costs look if you took the BBG board design (or a BBB
 minus its graphics components), ripped out the AM3358 and its PMIC, and
 designed in an AM5718 and its PMIC instead?

 I suspect such a barebones redesign would satisfy a lot of BBB users
 who would like to see a simple and least-cost upgrade to the very
 successful BeagleBone line.

 Morgaine.


 --
 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.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>>> --
>>> 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.
>>> 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.
> 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 
t

Re: [beagleboard] Help with Enabling SPI?

[William Hermans]

>
> *Delete any lines that may appear in uEnv.txt and add the following and
> save.  This change will tell the board to apply the SPI0 Device Tree
> Overlay we created on startup.*
>

The above is very, very bad advice. The uEnv.txt is a very important file
for booting the beaglebone black( or any beagle hardware ), and arbitrarily
deleting lines from, or the whole file is not very smart at all. I would
suggest in the future to avoid any advice, guide, or whatever from that
blog site.

So, if you board is now in an unbootable state, you're options are rather
limited. In either case, you will need an sdcard, with either a standalone,
or flashing image on it. Then boot from that. With a standalone image,
you'll have to reinstate the uEnv.txt file back to the original contents
before you followed that bad advice from that blog site. If you do not know
how to do this, then perhaps your best option is to reflash the entire eMMC.

If you have data on the eMMC that you need / want to keep. You can back
that up fairly easily before reflashing . . .

On Fri, Feb 19, 2016 at 4:44 PM, Audrey  wrote:

> Hi everyone,
>
> I want to enable SPI0 on beaglebone black, and I've been following
> resources online:
>
>
> http://embedded-basics.blogspot.com/2014/10/enabling-spi0-on-beaglebone-black.html
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> after changing uEnv.txt and rebooting bbb however, bbb doesn't come back
> online. All 4 of the usr LEDs are on, and I can no longer connect back to
> beaglebone.
>
> Firstly, a few clarifications, in My Computer > BeagleBone Getting
> Started, I did not find any uEnv.txt file, but nfs-uEnv.txt. The contents
> of nfs-uEnv.txt are:
>
> ##Rename as: uEnv.txt to boot via nfs
>> ##https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>> ##SERVER: sudo apt-get install tftpd-hpa
>> ##SERVER: TFTP_DIRECTORY defined in /etc/default/tftpd-hpa
>> ##SERVER: zImage/*.dtb need to be located here:
>> ##SERVER: TFTP_DIRECTORY/zImage
>> ##SERVER: TFTP_DIRECTORY/dtbs/*.dtb
>> ##client_ip needs to be set for u-boot to try booting via nfs
>> client_ip=192.168.1.101
>> #u-boot defaults: uncomment and override where needed
>> #server_ip=192.168.1.100
>> #gw_ip=192.168.1.1
>> #netmask=255.255.255.0
>> #hostname=
>> #device=eth0
>> #autoconf=off
>> #root_dir=/home/userid/targetNFS
>> #nfs_options=,vers=3
>> #nfsrootfstype=ext4 rootwait fixrtc
>>
>
> In the embedded-linux blog, he suggested to delete everything in the file
> and put in
>
> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01
>>
>>
> I however followed the instructions from elinux, and just copied the the
> above line. After that, I changed the name of the file from nfs-uEnv.txt to
> just uEnv.txt and rebooted bbb by typing reboot on the terminal, and now I
> don't think bbb works.
>
> Any ideas on what I'm doing wrong?
>
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help with Enabling SPI?

[William Hermans]

>
> *After that, I changed the name of the file from nfs-uEnv.txt to just
> uEnv.txt and rebooted bbb by typing reboot on the terminal, and now I don't
> think bbb works.*
>

Ok, I missed this part originally. Yes, you're attempting to boot from an
nfs share, so unless you have an nfs share, setup exactly like how is
implied in the uEnv,txt file. Changing nfs-uEnv.txt to uEnv.txt without
modification will fail.

On Fri, Feb 19, 2016 at 4:59 PM, William Hermans  wrote:

> *Delete any lines that may appear in uEnv.txt and add the following and
>> save.  This change will tell the board to apply the SPI0 Device Tree
>> Overlay we created on startup.*
>>
>
> The above is very, very bad advice. The uEnv.txt is a very important file
> for booting the beaglebone black( or any beagle hardware ), and arbitrarily
> deleting lines from, or the whole file is not very smart at all. I would
> suggest in the future to avoid any advice, guide, or whatever from that
> blog site.
>
> So, if you board is now in an unbootable state, you're options are rather
> limited. In either case, you will need an sdcard, with either a standalone,
> or flashing image on it. Then boot from that. With a standalone image,
> you'll have to reinstate the uEnv.txt file back to the original contents
> before you followed that bad advice from that blog site. If you do not know
> how to do this, then perhaps your best option is to reflash the entire eMMC.
>
> If you have data on the eMMC that you need / want to keep. You can back
> that up fairly easily before reflashing . . .
>
> On Fri, Feb 19, 2016 at 4:44 PM, Audrey  wrote:
>
>> Hi everyone,
>>
>> I want to enable SPI0 on beaglebone black, and I've been following
>> resources online:
>>
>>
>> http://embedded-basics.blogspot.com/2014/10/enabling-spi0-on-beaglebone-black.html
>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>>
>> after changing uEnv.txt and rebooting bbb however, bbb doesn't come back
>> online. All 4 of the usr LEDs are on, and I can no longer connect back to
>> beaglebone.
>>
>> Firstly, a few clarifications, in My Computer > BeagleBone Getting
>> Started, I did not find any uEnv.txt file, but nfs-uEnv.txt. The contents
>> of nfs-uEnv.txt are:
>>
>> ##Rename as: uEnv.txt to boot via nfs
>>> ##https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>>> ##SERVER: sudo apt-get install tftpd-hpa
>>> ##SERVER: TFTP_DIRECTORY defined in /etc/default/tftpd-hpa
>>> ##SERVER: zImage/*.dtb need to be located here:
>>> ##SERVER: TFTP_DIRECTORY/zImage
>>> ##SERVER: TFTP_DIRECTORY/dtbs/*.dtb
>>> ##client_ip needs to be set for u-boot to try booting via nfs
>>> client_ip=192.168.1.101
>>> #u-boot defaults: uncomment and override where needed
>>> #server_ip=192.168.1.100
>>> #gw_ip=192.168.1.1
>>> #netmask=255.255.255.0
>>> #hostname=
>>> #device=eth0
>>> #autoconf=off
>>> #root_dir=/home/userid/targetNFS
>>> #nfs_options=,vers=3
>>> #nfsrootfstype=ext4 rootwait fixrtc
>>>
>>
>> In the embedded-linux blog, he suggested to delete everything in the file
>> and put in
>>
>> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01
>>>
>>>
>> I however followed the instructions from elinux, and just copied the the
>> above line. After that, I changed the name of the file from nfs-uEnv.txt to
>> just uEnv.txt and rebooted bbb by typing reboot on the terminal, and now I
>> don't think bbb works.
>>
>> Any ideas on what I'm doing wrong?
>>
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

>
> *This is an excellent explanation of the workings of Remoteproc/RPMSG.
> Thanks for sharing.*
>
> *Regards,*
> *John*
>

Yeah I've seen that, or something similar it is pretty good, except there
is still one problem. That explanation  implies it instructs us how to use
the PRU hardware with rpmsg, and I suppose on some level it really does.
But what it does not explain, is how to interact with the rest of the on
chip hardware through this mechanism.

Sending text messages between ARM, and PRU processors is a good intro
demonstration of the software, but it is not really the least bit useful in
the real world.

Anyway, people like me who are very experienced with writing code, will be
put off using rpmsg etc because of this. Is it really so much to ask for
example code to demonstrate how to interact with the on die hardware ?
Without having to download 1GB of pretty much useless library . . .

On Sat, Feb 20, 2016 at 12:23 PM, John Syne  wrote:

>
> On Feb 20, 2016, at 8:11 AM, Greg  wrote:
>
> The support from TI is quite extensive:
>
> http://processors.wiki.ti.com/index.php/PRU-ICSS
>
> Download the C compiler manual.  There is a section which describes
> several ways to incorporate assembly code.
> This looks like a very detailed manual, which combined with the examples
> in the pru support package should be very helpful.
>
> I'm still coming up to speed on all of this, and it's complicated because
> you have to think about what is going on with the C compiler, remoteproc,
> rpmsg, and
> all of the details of what is going with these sort of kernel processes
> and the virtIO bus mechanism.  Too much going on for a Linux newbie, I've
> had to retreat
> and study some of the fundamentals before getting back to this (I hope!).
>
> You need to be aware the PASM is no longer supported.  The path forward is
> clpru, which is the C compiler which works with the included assembler
> (asmpru?).
> There are some differences in the way assembly code is written for the
> newer assembler (there are notes on this in the command line package
> download).
>
> I was also able to get the examples going with the PRU cape using
> remoteproc and version 4 kernel (Robert Nelson's testing image).  This
> massively simplified the process
> compared to what you see the in the TI "Hands On Labs" tutorial.  Pretty
> much everything with regards to remoteproc and the clpru compiler is
> ready-to-run.  You don't need cross-compilation
> or the IDE, all can be done at the command line on the BBB.  If you prefer
> to operate at the command line all the tools are there.
>
> Please correct me if I've got this wrong, but I think it's fair to say
> that TI has provided a wealth of information for the PRU, however, they
> expect further support to be coming from the community.
>
> Here's another really great contribution by TI:
>
> http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg
>
> This is an excellent explanation of the workings of Remoteproc/RPMSG.
> Thanks for sharing.
>
> Regards,
> John
>
>
> Regards,
> Greg
>
>
> --
> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] AM5718

[William Hermans]

Yeah, well . . . Gerald has already made it clear that an X15 Beaglebone
equivalent is not going to happen. I can understand why, after his
explanation of what he's gone through doing the two beaglebone boards.

But the cool thing is that the hardware is opensource, and *someone* out
there is able to use the existing design to do whatever they want with it.
Which means *maybe* someone can create a SFF version of the X15 ? However,
I do know that there would be many obstacles in the way of such a project.
Cost being a big one.

On Sat, Feb 20, 2016 at 7:28 AM, 'Morgaine' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> William writes:
> *> Anyhow, a minimal board, something like the beaglebone black, but
> without hdmi would be awesome.*
>
> Which of course is the focus of this thread, exploring whether the AM5718
> could take us there.  Apparently the answer is "No", although the
> question that I actually posed was "*How would the costs look*" if AM3358
> + PMIC were replaced by AM5718 + PMIC.  It's clear that it's "more", but
> it would be interesting to have some idea of the magnitude.
>
> As you rightly point out, *"**The X15 is not in the same 'class' as the
> Beaglebone boards, but in the same class as the original beagleboards"*.
> That makes X15 advocacy inapplicable in a BBB or BBG context since X15
> misses the BeagleBone price niche by a large margin.  This will usually put
> it out of the running for those typically cost-constrained IoT applications
> where BBB found a good home.
>
> Morgaine.
>
>
> On Fri, Feb 19, 2016 at 10:20 PM, William Hermans 
> wrote:
>
>> *Although every board has an appropriate niche, the problem with the X15
>>> from the PoV of BBB users is that its niche is not the BBB's niche.*
>>>
>>
>> As has been stated many times over now. The X15 is not in the same
>> "class" as the Beaglebone boards, but in the same class as the original
>> beagleboards. With much newer and updated features of course. Cost wise,
>> beagleboards have always been higher than beaglebones . . .
>>
>> Another thing to consider is that the X15 has so many features, and
>> features that far surpass those on the beaglebones, it makes the beaglebone
>> boards look like toys. So in other words is something more along the lines
>> of a dev board for the professional, and not the hobbyist.
>>
>> With al that said, I too have a "dream" of a board I'd like to see as
>> well. an  AM5718 with networking, and USB only as "out of the box"
>> peripherals only. With the rest of the on chip peripherals out to some form
>> of a high density pin header. Granted, onboard eMMC, ad an sdcard reader
>> would probably be good too now that I think of that.
>>
>> Anyhow, a minimal board, something like the beaglebone black, but without
>> hdmi would be awesome. Size for me would not be too important though. As
>> the X15 really is not all that big to begin with. Anyhow, my "dream" board
>> seems pretty close to the already existing x15 . . .
>>
>> On Fri, Feb 19, 2016 at 11:42 AM, 'Morgaine' via BeagleBoard <
>> beagleboard@googlegroups.com> wrote:
>>
>>> Drew writes:
>>> *> BeagleBone Plaid... I sense a best seller! :)*
>>>
>>> I wouldn't hold that against it.  A haggis in the box would be a step
>>> too far though. :P
>>>
>>> On Fri, Feb 19, 2016 at 6:26 PM, Morgaine <
>>> morgaine.din...@googlemail.com> wrote:
>>>
>>>> Although every board has an appropriate niche, the problem with the X15
>>>> from the PoV of BBB users is that its niche is not the BBB's niche.
>>>>
>>>> While the X15 is certainly interesting, it's not going to help those
>>>> BBB users who would like a little more power at a little more cost within
>>>> the BBB form factor.  X15 comes in at a much higher price point, and this
>>>> puts it out of contention for many small IoT tasks where the BBB's cost is
>>>> seen as reasonable.
>>>>
>>>> BBB has become very popular and a lot of people would like to see the
>>>> line extended with an upgraded processor, as you know since it's been a
>>>> regular suggestion here.  I'm sure you would fill this product space if you
>>>> could, but I suppose TI's "$5 AM335x" launch many moons ago was a one-off.
>>>> Pity.
>>>>
>>>> Morgaine.
>>>>
>>>>
>>>> On Fri, Feb 

Re: [beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

>
> *I hope I’m answering your question. *
>

No, not even close. I need an answer that gives an example in code, how to
use on die peripherals, through the PRU's, when using remoteproc / rpmsg.
Passed that, I do not want to download a couple gigs of data for software I
do not need, or even want.

What would be really good, would be a github example. Blinking an on board
LED or toggling a GPIO would be the simplest, but anything demonstrating
using the onboard peripherals. ADC, I2C, CAN, or even just GPIO -
whichever. The ARM processor side code would not exactly be so important,
except it would be a good example of how the two sides of software interact
with one another.

On Sat, Feb 20, 2016 at 1:01 PM, John Syne  wrote:

> Hi William,
>
> So here is how I like to use this. The PRU is performing some function and
> I send commands to modify that function. An example would be controlling
> the position of a stepper motor. The ARM app sends a new position and the
> PRU takes care of stepping the motor to that new location. I think of the
> PRU as being good at doing low latency stuff and I use RPMSG/Remoteproc to
> send instructions and then I get feedback on measurements from the PRU. The
> interface isn’t fast enough to do anything more that this. Simply flashing
> an LED by sending a command isn’t the best use of this technology. Changing
> the flashing rate or the duty cycle is more appropriate. I hope I’m
> answering your question.
>
> Regards,
> John
>
>
>
>
> On Feb 20, 2016, at 11:45 AM, William Hermans  wrote:
>
> *This is an excellent explanation of the workings of Remoteproc/RPMSG.
>> Thanks for sharing.*
>>
>> *Regards,*
>> *John*
>>
>
> Yeah I've seen that, or something similar it is pretty good, except there
> is still one problem. That explanation  implies it instructs us how to use
> the PRU hardware with rpmsg, and I suppose on some level it really does.
> But what it does not explain, is how to interact with the rest of the on
> chip hardware through this mechanism.
>
> Sending text messages between ARM, and PRU processors is a good intro
> demonstration of the software, but it is not really the least bit useful in
> the real world.
>
> Anyway, people like me who are very experienced with writing code, will be
> put off using rpmsg etc because of this. Is it really so much to ask for
> example code to demonstrate how to interact with the on die hardware ?
> Without having to download 1GB of pretty much useless library . . .
>
> On Sat, Feb 20, 2016 at 12:23 PM, John Syne  wrote:
>
>>
>> On Feb 20, 2016, at 8:11 AM, Greg  wrote:
>>
>> The support from TI is quite extensive:
>>
>> http://processors.wiki.ti.com/index.php/PRU-ICSS
>>
>> Download the C compiler manual.  There is a section which describes
>> several ways to incorporate assembly code.
>> This looks like a very detailed manual, which combined with the examples
>> in the pru support package should be very helpful.
>>
>> I'm still coming up to speed on all of this, and it's complicated because
>> you have to think about what is going on with the C compiler, remoteproc,
>> rpmsg, and
>> all of the details of what is going with these sort of kernel processes
>> and the virtIO bus mechanism.  Too much going on for a Linux newbie, I've
>> had to retreat
>> and study some of the fundamentals before getting back to this (I hope!).
>>
>> You need to be aware the PASM is no longer supported.  The path forward
>> is clpru, which is the C compiler which works with the included assembler
>> (asmpru?).
>> There are some differences in the way assembly code is written for the
>> newer assembler (there are notes on this in the command line package
>> download).
>>
>> I was also able to get the examples going with the PRU cape using
>> remoteproc and version 4 kernel (Robert Nelson's testing image).  This
>> massively simplified the process
>> compared to what you see the in the TI "Hands On Labs" tutorial.  Pretty
>> much everything with regards to remoteproc and the clpru compiler is
>> ready-to-run.  You don't need cross-compilation
>> or the IDE, all can be done at the command line on the BBB.  If you
>> prefer to operate at the command line all the tools are there.
>>
>> Please correct me if I've got this wrong, but I think it's fair to say
>> that TI has provided a wealth of information for the PRU, however, they
>> expect further support to be coming from the community.
>>
>> Here's another really great contribution by TI:
>>
>> http://processors.wiki.ti.co

Re: [beagleboard] Can't get BBB to image below 4.1? Really want PWM :\

[William Hermans]

>
> *PWM, should be working on v4.1, what software stack are you using to
> interface to the pwm's?*
>
> *Regards,*
>
@Robert, he said here:
> I had installed Debian 8.3 (the image provided on the beaglebone page,
running the 4.1 kernel) kernel on it and tried to >get PWM working without
success (apparently both the adafruit and greycat python bbio libraries
only work on 3.8), >interestingly enough bonescript also refuses to work.

Which is adafruits python library, and Alexander Haim's pybbio libraries.
Both are Python. Also, neither are 100% up to date with the newer kernels,
but I understand Alexander is working on updating his.





On Sat, Feb 20, 2016 at 2:35 PM, Robert Nelson 
wrote:

>
> On Feb 20, 2016 2:47 PM,  wrote:
> >
> > Hi There,
> >
> > Im trying to get a basic servo project running on my BBB
> >
> > I had installed Debian 8.3 (the image provided on the beaglebone page,
> running the 4.1 kernel) kernel on it and tried to get PWM working without
> success (apparently both the adafruit and greycat python bbio libraries
> only work on 3.8), interestingly enough bonescript also refuses to work.
> >
> >
> > I have tried reverting to earlier images via microsd without success:
> > -The Device doesnt become reachable via ping to 192.168.7.2 after
> several hours and attempting to power cycle
> > -The "External Drive" does not connect to windows upon boot
> > -While attempting to flash the emmc, the USRleds do not cycle in the
> 'cylon' style.
> >
> > I've tried to make the Debian 8.3 image work, via trying to install an
> older kernel via apt without success (the device appears to be operating
> but is unreachable via USB/ping/etc):
> > "sudo apt-get install linux-image-3.8.13-bone70
> linux-headers-3.8.13-bone70 mt7601u-modules-3.8.13-bone70"
> >
> >
> > I really DON'T know what to do -- I would have hoped that PWM would work
> out of the box on the default Debian 8.3 image. Perhaps there's something I
> need to do to make it work that isn't apparent to a novice like me.
> >
> > Unfortunately, rolling back to a 3.8 kernel via imaging or apt doesn't
> seem to allow the BBB to communicate with my windows machine after
> attempting to do so, and only 4.1 kernel images seem to work successfully
> in that sense, with the caveat that PWM doesnt work.
>
> PWM, should be working on v4.1, what software stack are you using to
> interface to the pwm's?
>
> Regards,
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

>
>
>
>
> *The PRU examples that I have pointed out several times do exactly what
> you are asking for. Also, several other posters have shown how to build
> these examples without CCSV6. After you build the PRU code, you have to
> place it in /lib/firmware so that Remoteproc can load it into the PRU,
> configure resources and start the PRU code. Regards,John*


We'll just have to agree to disagree. Since I'm a very experienced
programmer who has not had any problems setting up, or writing / using
software for multiple other aspects of the hardware. Somehow, it must be my
fault.

On Sat, Feb 20, 2016 at 2:08 PM, John Syne  wrote:

> The PRU examples that I have pointed out several times do exactly what you
> are asking for. Also, several other posters have shown how to build these
> examples without CCSV6. After you build the PRU code, you have to place it
> in /lib/firmware so that Remoteproc can load it into the PRU, configure
> resources and start the PRU code.
>
> Regards,
> John
>
>
>
>
> On Feb 20, 2016, at 12:29 PM, William Hermans  wrote:
>
> *I hope I’m answering your question. *
>>
>
> No, not even close. I need an answer that gives an example in code, how to
> use on die peripherals, through the PRU's, when using remoteproc / rpmsg.
> Passed that, I do not want to download a couple gigs of data for software I
> do not need, or even want.
>
> What would be really good, would be a github example. Blinking an on board
> LED or toggling a GPIO would be the simplest, but anything demonstrating
> using the onboard peripherals. ADC, I2C, CAN, or even just GPIO -
> whichever. The ARM processor side code would not exactly be so important,
> except it would be a good example of how the two sides of software interact
> with one another.
>
> On Sat, Feb 20, 2016 at 1:01 PM, John Syne  wrote:
>
>> Hi William,
>>
>> So here is how I like to use this. The PRU is performing some function
>> and I send commands to modify that function. An example would be
>> controlling the position of a stepper motor. The ARM app sends a new
>> position and the PRU takes care of stepping the motor to that new location.
>> I think of the PRU as being good at doing low latency stuff and I use
>> RPMSG/Remoteproc to send instructions and then I get feedback on
>> measurements from the PRU. The interface isn’t fast enough to do anything
>> more that this. Simply flashing an LED by sending a command isn’t the best
>> use of this technology. Changing the flashing rate or the duty cycle is
>> more appropriate. I hope I’m answering your question.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 20, 2016, at 11:45 AM, William Hermans  wrote:
>>
>> *This is an excellent explanation of the workings of Remoteproc/RPMSG.
>>> Thanks for sharing.*
>>>
>>> *Regards,*
>>> *John*
>>>
>>
>> Yeah I've seen that, or something similar it is pretty good, except there
>> is still one problem. That explanation  implies it instructs us how to use
>> the PRU hardware with rpmsg, and I suppose on some level it really does.
>> But what it does not explain, is how to interact with the rest of the on
>> chip hardware through this mechanism.
>>
>> Sending text messages between ARM, and PRU processors is a good intro
>> demonstration of the software, but it is not really the least bit useful in
>> the real world.
>>
>> Anyway, people like me who are very experienced with writing code, will
>> be put off using rpmsg etc because of this. Is it really so much to ask for
>> example code to demonstrate how to interact with the on die hardware ?
>> Without having to download 1GB of pretty much useless library . . .
>>
>> On Sat, Feb 20, 2016 at 12:23 PM, John Syne  wrote:
>>
>>>
>>> On Feb 20, 2016, at 8:11 AM, Greg  wrote:
>>>
>>> The support from TI is quite extensive:
>>>
>>> http://processors.wiki.ti.com/index.php/PRU-ICSS
>>>
>>> Download the C compiler manual.  There is a section which describes
>>> several ways to incorporate assembly code.
>>> This looks like a very detailed manual, which combined with the examples
>>> in the pru support package should be very helpful.
>>>
>>> I'm still coming up to speed on all of this, and it's complicated
>>> because you have to think about what is going on with the C compiler,
>>> remoteproc, rpmsg, and
>>> all of the details of what is going with these sort of kernel processes
>>> and the virtIO bus mechanism.  Too much going on for a L

Re: Re[2]: [beagleboard] AM5718

[William Hermans]

>
> *Have a look at the Cherry Blossom from Arrow Altech. It is a BBB but with
> no HDMI and no network.*
>

Actually for the sake of this discussion, we do not really care about the
BBB, except in dimension, and cost. But while we're on the subject of a
"headless" BB "replacement". the BBG is a much better offering than the one
you suggest. Which is of course in my opinion. The biggest factor here, a
beaglebone without ethernet is a waste of a board.

On Sat, Feb 20, 2016 at 9:11 AM, Marius  wrote:

>
>
>
> William writes:
> *> Anyhow, a minimal board, something like the beaglebone black, but
> without hdmi would be awesome.*
>
> Which of course is the focus of this thread, exploring whether the AM5718
> could take us there.  Apparently the answer is "No", although the
> question that I actually posed was "*How would the costs look*" if AM3358
> + PMIC were replaced by AM5718 + PMIC.  It's clear that it's "more", but
> it would be interesting to have some idea of the magnitude.
>
>
> Have a look at the Cherry Blossom from Arrow Altech. It is a BBB but with
> no HDMI and no network.
>
> http://www.arrow.altech.co.za/
>
> http://www.arrow.altech.co.za/sites/arrow/files/Cherry%20Blossom%20TI%20Am%20Module.pdf
>
>
>
>
> As you rightly point out, *"**The X15 is not in the same 'class' as the
> Beaglebone boards, but in the same class as the original beagleboards"*.
> That makes X15 advocacy inapplicable in a BBB or BBG context since X15
> misses the BeagleBone price niche by a large margin.  This will usually put
> it out of the running for those typically cost-constrained IoT applications
> where BBB found a good home.
>
> Morgaine.
>
>
> On Fri, Feb 19, 2016 at 10:20 PM, William Hermans 
> wrote:
>
>> *Although every board has an appropriate niche, the problem with the X15
>>> from the PoV of BBB users is that its niche is not the BBB's niche.*
>>>
>>
>> As has been stated many times over now. The X15 is not in the same
>> "class" as the Beaglebone boards, but in the same class as the original
>> beagleboards. With much newer and updated features of course. Cost wise,
>> beagleboards have always been higher than beaglebones . . .
>>
>> Another thing to consider is that the X15 has so many features, and
>> features that far surpass those on the beaglebones, it makes the beaglebone
>> boards look like toys. So in other words is something more along the lines
>> of a dev board for the professional, and not the hobbyist.
>>
>> With al that said, I too have a "dream" of a board I'd like to see as
>> well. an  AM5718 with networking, and USB only as "out of the box"
>> peripherals only. With the rest of the on chip peripherals out to some form
>> of a high density pin header. Granted, onboard eMMC, ad an sdcard reader
>> would probably be good too now that I think of that.
>>
>> Anyhow, a minimal board, something like the beaglebone black, but without
>> hdmi would be awesome. Size for me would not be too important though. As
>> the X15 really is not all that big to begin with. Anyhow, my "dream" board
>> seems pretty close to the already existing x15 . . .
>>
>> On Fri, Feb 19, 2016 at 11:42 AM, 'Morgaine' via BeagleBoard <
>> beagleboard@googlegroups.com> wrote:
>>
>>> Drew writes:
>>> *> BeagleBone Plaid... I sense a best seller! [image: :)] *
>>>
>>> I wouldn't hold that against it.  A haggis in the box would be a step
>>> too far though. [image: :P]
>>>
>>> On Fri, Feb 19, 2016 at 6:26 PM, Morgaine <
>>> morgaine.din...@googlemail.com> wrote:
>>>
>>>> Although every board has an appropriate niche, the problem with the X15
>>>> from the PoV of BBB users is that its niche is not the BBB's niche.
>>>>
>>>> While the X15 is certainly interesting, it's not going to help those
>>>> BBB users who would like a little more power at a little more cost within
>>>> the BBB form factor.  X15 comes in at a much higher price point, and this
>>>> puts it out of contention for many small IoT tasks where the BBB's cost is
>>>> seen as reasonable.
>>>>
>>>> BBB has become very popular and a lot of people would like to see the
>>>> line extended with an upgraded processor, as you know since it's been a
>>>> regular suggestion here.  I'm sure you would fill this product space if you
>>>> could, but I suppose TI

Re: [beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

>
> *William,*
>
> * I must be missing something, because I see remoteproc as a*
> * communication and management mechanism for code on CPUs other than the*
> * main processor. The actual code that you are running on those*
> * subsidiary processors does not depend on the mechanism you use for*
> * talking to it (other than the parts that do the talking, of course).*
>
> * In particular, running ADC, I2C or GPIO should be the same, regardless*
> * whether you use remoteproc or not---what changes is how you tell this*
> * code what to do.*
>
> * Does it make sense to you?*


What it is suppose to do hs always made sense to me. How exactlyit is done,
is another story.

with uio_prussdrv, you have a driver module, which sets various things up,
loads the PRU binary, and then enables / runs the PRU(s). On the PRU side,
the code runs, communicates with various peripherals as needed( usually
one, if any ), and then the PRU code performs it's function as specified in
assembly. Sometimes, dumping data into ddr3( as per the example ), and
sometimes not.

Anyway, the above is a fairly rough description, but how each aspect
communicates with the other is abundantly clear in code. Some have even
attempted to describe what happens, but if you ask me inadequately. No
matter though the code is pretty clear.

With remoteproc, the Documentation/*txt documentation is very minimal, and
does not describe the process in which it works very well. However, the
code is fairly clear as to how the ARM, and PRU sides communicate with one
another( rpmsg ). However, what is not clear, is how the PRU code actually
manipulates the physics on system hardware. Additionally, to confuse
matters even more, the assembler has changed to a compiler( C - clpru ),
and there is something like "map" files for hardware configuration that do
not seem to be very well documented. Just some examples, that are not very
clear as to how, or why these are even needed.

So here I am, attempting to learn a few things new to me. Documentation is
very poor, TI refuses to answer any questions in relation to PRUs on their
e2e forums(" go to beagleboard.org google groups . . ." ). I spend several
days learning about everything PRU related, and immediately pick up the
concept of uio_prussdrv. Still having a hard time with the TI C compiler on
the PRU side of things, largely due to these mysterious configuration
files. But no matter, the TI Assembler is fairly straight forward, the PRU
instruction set is a minimal Cortex M3 set, and easy.

Anyway, for context of my competence level. Not long ago I wrote a set of
processes / applications to read from the CANBUS in realtime, decode the
CANBUS data, and shuffle this decoded data out over a websocket. This
required me learning several aspect of Linux systems programming from
scratch. Including POSIX shared memory files, socketCAN, and process
spawning / management. All from scratch, since this was my first major
Linux application. All of this including reverse engineering parts of the
high level CANBUS protocol took me around a month. The point here is, I
have no problem picking up / understanding technologies, and / or API's,
libraries, and such that I've previously have had no experience with. *So
long* as there is at least a little decent documentation on the subject, or
I can talk to someone who does understand things that may be confusing to
me.

Additionally, I'm not saying exactly that remoteproc can't be made to work,
because obviously it can. What I am saying is that since the concept is so
poorly documented, is still in experimental phase, and now I learn that it
is slower than traditional prussdrv drivers / methods. That it's just not
worth my time to even attempt to get working.

That and I *have* spent some time ( roughly a week ), *just because* I'm
the type that does not mind experimenting with new technology in software.
But only new technology that is not too argumentative. As my time is far
too valuable to me than to screw around with technology that honestly makes
very little sense to me.

Also for what it is worth. remoteproc / rpmsg in my own mind is far more
useful in cases where a processor may have multiple application / general
purpose cores. In that one core can be made to run Linux, while the others
can be made to run bare metal - Simultaneously. Less useful on the case of
the PRUs since we already have a software layer that is well documented,
works very well, and quite honestly far superior to remoteproc / rpmsg in
this case. If nothing else. Speed.


On Sat, Feb 20, 2016 at 9:45 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Sat, Feb 20, 2016 at 2:45 PM, William Hermans 
> wrote:
> > Is it really so much to ask for example code to demonstrate how to
> interact
> > with the on die hardware ? Without having to download 1GB of pretty much
> >

Re: [beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

[William Hermans]

I do expect that TI will improve the documentation on their implementation
of remoteproc / rpmsg sometime in the future  though. As in the case of the
X15, there are not only 4 on die PRU's, but there are 4 IPU's( 2 usable for
general purpose ), and two DSP's( on the dual core A15 ). I've no idea what
TI has compiler / assembler wise for these DSP's but the IPU's from what I
understand are fairly new( in the context of general purpose ). So I'd
assume this is where remoteproc / rpmsg will make the most sense. the on
die IPU's

On Sat, Feb 20, 2016 at 10:39 PM, William Hermans  wrote:

> *William,*
>>
>> * I must be missing something, because I see remoteproc as a*
>> * communication and management mechanism for code on CPUs other than the*
>> * main processor. The actual code that you are running on those*
>> * subsidiary processors does not depend on the mechanism you use for*
>> * talking to it (other than the parts that do the talking, of course).*
>>
>> * In particular, running ADC, I2C or GPIO should be the same, regardless*
>> * whether you use remoteproc or not---what changes is how you tell this*
>> * code what to do.*
>>
>> * Does it make sense to you?*
>
>
> What it is suppose to do hs always made sense to me. How exactlyit is
> done, is another story.
>
> with uio_prussdrv, you have a driver module, which sets various things up,
> loads the PRU binary, and then enables / runs the PRU(s). On the PRU side,
> the code runs, communicates with various peripherals as needed( usually
> one, if any ), and then the PRU code performs it's function as specified in
> assembly. Sometimes, dumping data into ddr3( as per the example ), and
> sometimes not.
>
> Anyway, the above is a fairly rough description, but how each aspect
> communicates with the other is abundantly clear in code. Some have even
> attempted to describe what happens, but if you ask me inadequately. No
> matter though the code is pretty clear.
>
> With remoteproc, the Documentation/*txt documentation is very minimal, and
> does not describe the process in which it works very well. However, the
> code is fairly clear as to how the ARM, and PRU sides communicate with one
> another( rpmsg ). However, what is not clear, is how the PRU code actually
> manipulates the physics on system hardware. Additionally, to confuse
> matters even more, the assembler has changed to a compiler( C - clpru ),
> and there is something like "map" files for hardware configuration that do
> not seem to be very well documented. Just some examples, that are not very
> clear as to how, or why these are even needed.
>
> So here I am, attempting to learn a few things new to me. Documentation is
> very poor, TI refuses to answer any questions in relation to PRUs on their
> e2e forums(" go to beagleboard.org google groups . . ." ). I spend
> several days learning about everything PRU related, and immediately pick up
> the concept of uio_prussdrv. Still having a hard time with the TI C
> compiler on the PRU side of things, largely due to these mysterious
> configuration files. But no matter, the TI Assembler is fairly straight
> forward, the PRU instruction set is a minimal Cortex M3 set, and easy.
>
> Anyway, for context of my competence level. Not long ago I wrote a set of
> processes / applications to read from the CANBUS in realtime, decode the
> CANBUS data, and shuffle this decoded data out over a websocket. This
> required me learning several aspect of Linux systems programming from
> scratch. Including POSIX shared memory files, socketCAN, and process
> spawning / management. All from scratch, since this was my first major
> Linux application. All of this including reverse engineering parts of the
> high level CANBUS protocol took me around a month. The point here is, I
> have no problem picking up / understanding technologies, and / or API's,
> libraries, and such that I've previously have had no experience with. *So
> long* as there is at least a little decent documentation on the subject, or
> I can talk to someone who does understand things that may be confusing to
> me.
>
> Additionally, I'm not saying exactly that remoteproc can't be made to
> work, because obviously it can. What I am saying is that since the concept
> is so poorly documented, is still in experimental phase, and now I learn
> that it is slower than traditional prussdrv drivers / methods. That it's
> just not worth my time to even attempt to get working.
>
> That and I *have* spent some time ( roughly a week ), *just because* I'm
> the type that does not mind experimenting with new technology in software.
> But only new technology that is not too ar

Re: [beagleboard] Help with Enabling SPI?

[William Hermans]

>
> *Hi William,*
>
> *Thanks for your reply. I'm trying to flash bbb now. Could I ask what's
the difference between flashing an image vs flashing the eMMC? I thought
flashing the bbb meant flashing everything. *

Flashing the eMMC is flashing everything.


*I do not currently have anything that I want to keep on bbb. What's the
> difference between booting from an nfs share vs booting normally? *
>
> *Also, what do you suggest I do in the future? I didn't follow the blog
> guy's advice and had simply added the line, although I did change the file
> name from nfs-uEnv.txt to uEnv.txt. Should I leave the file name as
> nfs-uEnv.txt next time?*
>
> *Thanks.*
>
Don't bother with NFS shares for now. They're fairly complicated, and quite
honestly you do not sound like you're experienced enough with linux yet.
But the difference is, NFS boot is "booting" over a network. Or if you
prefer it is loading the root file system over a network.

In the future you should make a backup of any important files, or those
you're not sure of.

On Sat, Feb 20, 2016 at 10:44 PM, Audrey  wrote:

> Hi William,
>
> Thanks for your reply. I'm trying to flash bbb now. Could I ask what's the
> difference between flashing an image vs flashing the eMMC? I thought
> flashing the bbb meant flashing everything.
>
> I do not currently have anything that I want to keep on bbb. What's the
> difference between booting from an nfs share vs booting normally?
>
> Also, what do you suggest I do in the future? I didn't follow the blog
> guy's advice and had simply added the line, although I did change the file
> name from nfs-uEnv.txt to uEnv.txt. Should I leave the file name as
> nfs-uEnv.txt next time?
>
> Thanks.
>
> On Friday, February 19, 2016 at 7:04:16 PM UTC-5, William Hermans wrote:
>>
>> *After that, I changed the name of the file from nfs-uEnv.txt to just
>>> uEnv.txt and rebooted bbb by typing reboot on the terminal, and now I don't
>>> think bbb works.*
>>>
>>
>> Ok, I missed this part originally. Yes, you're attempting to boot from an
>> nfs share, so unless you have an nfs share, setup exactly like how is
>> implied in the uEnv,txt file. Changing nfs-uEnv.txt to uEnv.txt without
>> modification will fail.
>>
>> On Fri, Feb 19, 2016 at 4:59 PM, William Hermans 
>> wrote:
>>
>>> *Delete any lines that may appear in uEnv.txt and add the following and
>>>> save.  This change will tell the board to apply the SPI0 Device Tree
>>>> Overlay we created on startup.*
>>>>
>>>
>>> The above is very, very bad advice. The uEnv.txt is a very important
>>> file for booting the beaglebone black( or any beagle hardware ), and
>>> arbitrarily deleting lines from, or the whole file is not very smart at
>>> all. I would suggest in the future to avoid any advice, guide, or whatever
>>> from that blog site.
>>>
>>> So, if you board is now in an unbootable state, you're options are
>>> rather limited. In either case, you will need an sdcard, with either a
>>> standalone, or flashing image on it. Then boot from that. With a standalone
>>> image, you'll have to reinstate the uEnv.txt file back to the original
>>> contents before you followed that bad advice from that blog site. If you do
>>> not know how to do this, then perhaps your best option is to reflash the
>>> entire eMMC.
>>>
>>> If you have data on the eMMC that you need / want to keep. You can back
>>> that up fairly easily before reflashing . . .
>>>
>>> On Fri, Feb 19, 2016 at 4:44 PM, Audrey  wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I want to enable SPI0 on beaglebone black, and I've been following
>>>> resources online:
>>>>
>>>>
>>>> http://embedded-basics.blogspot.com/2014/10/enabling-spi0-on-beaglebone-black.html
>>>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>>>>
>>>> after changing uEnv.txt and rebooting bbb however, bbb doesn't come
>>>> back online. All 4 of the usr LEDs are on, and I can no longer connect back
>>>> to beaglebone.
>>>>
>>>> Firstly, a few clarifications, in My Computer > BeagleBone Getting
>>>> Started, I did not find any uEnv.txt file, but nfs-uEnv.txt. The contents
>>>> of nfs-uEnv.txt are:
>>>>
>>>> ##Rename as: uEnv.txt to boot via nfs
>>>>> ##https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
>&g

Re: [beagleboard] Cannot restart or shutdown from CLI

[William Hermans]

william@beaglebone:~$ *sudo shutdown now -r*

Broadcast message from root@beaglebone (pts/0) (Sat Feb 20 23:00:51 2016):
The system is going down for reboot NOW!
william@beaglebone:~$ Connection to 192.168.254.167 closed by remote host.
Connection to 192.168.254.167 closed.


On Sat, Feb 20, 2016 at 5:23 PM,  wrote:

> Greets!
>
> I grabbed a recent image (cat /etc/dogtag is BeagleBoard.org Debian Image
> 2016-01-24) and it is Jessie 8. One of the issues I am working is that I
> cannot restart or shutdown from CLI with
> shutdown -r now
>
> or
> shutdown -h now
>
> What happens when I try to restart is my putty SSH continues to wait and
> does not lose connection, and when I look at my BBB (version C) the
> heartbeat keeps beating. I have to manually shut it down and reboot. Halt
> is the same thing.
>
> I never had this problem with previous versions of Debian. I did see
> something about a patch here... chroot: make sure to patch systemd in
> console images
> 
>  but
> I cannot find scripts/chroot.sh so not sure what to patch.
>
> This is important to me, because I often shell into the BBB from remote
> and would like control over reboots from that remote location.
>
> I hope I didn't ask again what was already posted. I searched but all I
> found was... "it doesn't work" without elaborating.
>
> Thank you for your time!
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Cannot restart or shutdown from CLI

[William Hermans]

I'm not terribly familiar with Jessie, I'm actually using Debian 7.8
wheezy, but . . . You may have to use *reboot*, and *halt* commands. Of
course you'll need elevated permissions.

On Sat, Feb 20, 2016 at 11:01 PM, William Hermans  wrote:

> william@beaglebone:~$ *sudo shutdown now -r*
>
> Broadcast message from root@beaglebone (pts/0) (Sat Feb 20 23:00:51 2016):
> The system is going down for reboot NOW!
> william@beaglebone:~$ Connection to 192.168.254.167 closed by remote host.
> Connection to 192.168.254.167 closed.
>
>
> On Sat, Feb 20, 2016 at 5:23 PM,  wrote:
>
>> Greets!
>>
>> I grabbed a recent image (cat /etc/dogtag is BeagleBoard.org Debian Image
>> 2016-01-24) and it is Jessie 8. One of the issues I am working is that I
>> cannot restart or shutdown from CLI with
>> shutdown -r now
>>
>> or
>> shutdown -h now
>>
>> What happens when I try to restart is my putty SSH continues to wait and
>> does not lose connection, and when I look at my BBB (version C) the
>> heartbeat keeps beating. I have to manually shut it down and reboot. Halt
>> is the same thing.
>>
>> I never had this problem with previous versions of Debian. I did see
>> something about a patch here... chroot: make sure to patch systemd in
>> console images
>> <https://github.com/beagleboard/image-builder/commit/0b7dcfbd5ddd852116288c80106f20e1af5c4987>
>>  but
>> I cannot find scripts/chroot.sh so not sure what to patch.
>>
>> This is important to me, because I often shell into the BBB from remote
>> and would like control over reboots from that remote location.
>>
>> I hope I didn't ask again what was already posted. I searched but all I
>> found was... "it doesn't work" without elaborating.
>>
>> Thank you for your time!
>>
>> --
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can't get BBB to image below 4.1? Really want PWM :\

[William Hermans]

Jeff, is there any reason why you need to use python ? Because this should
be really easy ( under 20 lines of code ) to get the PWM set, and running
in C. Through using Linux sysfs

On Sat, Feb 20, 2016 at 6:49 PM, Jeff Pedlow  wrote:

> Hello again,
>
> As an addendum -- I tried installing the greycat labs bbio via apt-get.
> Sadly, every time that I try importing it via python, i get an immediate
> seg fault.
>
> cannot for the life of me figure out how to make PWM work. It's
> frustrating as someone who really wants to learn the platform but isn't a
> linux ninja :\
>
> Banging my head on the wall :(
>
> Any and all input is appreciated
>
> -
>
> On Sat, Feb 20, 2016 at 4:53 PM, Jeff Pedlow  wrote:
>
>> Hello Robert,
>>
>> Thank you very kindly for getting back to me.
>>
>> To clarify, do you mean I should install the greycatlabs bbio package?
>> and its compatible with 4.1? :)
>>
>> Reading:
>> https://github.com/graycatlabs/PyBBIO/wiki/Installing-PyBBIO
>>
>> it appears that it is not compatible with anything higher than 3.8?
>>
>>
>> Tried a couple things without much success:
>>
>> Wanted to see if it was installed from the getgo (as the adafruit library
>> was) First tried:
>> >>from bbio import * #
>> https://github.com/graycatlabs/PyBBIO/wiki/Using-PyBBIO
>>
>> And got a seg fault
>> Then further tried to see if the module was actually installed via:
>> >>help('modules')
>> and
>> pydoc modules
>>
>> and both seg faulted.
>>
>> I apologize for being 'a little slow' on this front.
>>
>> Thanks kindly! :)
>>
>> On Sat, Feb 20, 2016 at 2:08 PM, Robert Nelson 
>> wrote:
>>
>>>
>>> On Feb 20, 2016 3:54 PM, "Jeff Pedlow"  wrote:
>>> >
>>> > Hi Robert,
>>> >
>>> > Thank you VERY kindly for getting back to me. I am a little new to
>>> linux, but am trying to learn as I go here, so apologies if I'm not
>>> answering very well.
>>> >
>>> > OS:
>>> > EMMC flash image:
>>> https://rcn-ee.com/rootfs/2016-02-11/flasher/BBB-eMMC-flasher-debian-8.3-console-armhf-2016-02-11-2gb.img.xz
>>> > SD image:
>>> https://debian.beagleboard.org/images/bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img.xz
>>> >
>>> >
>>> > Using the stock installed python and adafruit python bbio library
>>> included on the SD image.
>>> >
>>> > First step was to see if I could make a PIN go hi/low to flash an LED
>>> using python (simple enough)
>>> > import Adafruit_BBIO.GPIO as GPIO
>>> > GPIO.setup("P8_10", GPIO.OUT)
>>> > GPIO.output("P8_10", GPIO.HIGH)
>>> > GPIO.output("P8_10", GPIO.LOW)
>>> >
>>> > And the LED hooked to P8_10 works and I can make it blink. Life is
>>> good. Huzzah!
>>> >
>>> >
>>> >
>>> > Next step.. was to TRY to run this in python: (from the adafruit bbb
>>> servo tutorial)
>>> > import Adafruit_BBIO.PWM as PWM
>>> > PWM.start("P8_13", 95.0, 60)
>>> > PWM.set_duty_cycle("P8_13", 97.0) #This Errors with: "IOError: [Errno
>>> 2] No such file or directory: '/slots'"
>>> > PWM.stop("P8_13")
>>> > PWM.cleanup() #This Errors with: "IOError: [Errno 2] No such file or
>>> directory: '/slots'"
>>>
>>> There's a patch for this but it breaks, 3.8..
>>>
>>> For now us pybbio lib.
>>>
>>> >
>>> > And nothing happens.
>>> >
>>> > From this point I've become successful at horribly confusing myself
>>> about listings in /sys/class and /lib/firmware and .dtbo files and
>>> /sys/devices/platform/bone_capemgr/slots and have NO idea where to go to
>>> get PWM to work in python, let alone how to successfully troubleshoot the
>>> issue.
>>> >
>>> > Any and all input appreciated. Really humbling experience thus far.
>>> >
>>> > Thanks
>>> >
>>> > -Jeff
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Feb 20, 2016 at 1:35 PM, Robert Nelson <
>>> robertcnel...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Feb 20, 2016 2:47 PM,  wrote:
>>> >> >
>>> >> > Hi There,
>>> >> >
>>> >> > Im trying to get a basic servo project running on my BBB
>>> >> >
>>> >> > I had installed Debian 8.3 (the image provided on the beaglebone
>>> page, running the 4.1 kernel) kernel on it and tried to get PWM working
>>> without success (apparently both the adafruit and greycat python bbio
>>> libraries only work on 3.8), interestingly enough bonescript also refuses
>>> to work.
>>> >> >
>>> >> >
>>> >> > I have tried reverting to earlier images via microsd without
>>> success:
>>> >> > -The Device doesnt become reachable via ping to 192.168.7.2 after
>>> several hours and attempting to power cycle
>>> >> > -The "External Drive" does not connect to windows upon boot
>>> >> > -While attempting to flash the emmc, the USRleds do not cycle in
>>> the 'cylon' style.
>>> >> >
>>> >> > I've tried to make the Debian 8.3 image work, via trying to install
>>> an older kernel via apt without success (the device appears to be operating
>>> but is unreachable via USB/ping/etc):
>>> >> > "sudo apt-get install linux-image-3.8.13-bone70
>>> linux-headers-3.8.13-bone70 mt7601u-modules-3.8.13-bone70"
>>> >> >
>>> >> >
>>> >> > I really DON'T know what to do -- I would have hoped