Re: [beagleboard] Python 3.7/3.7.1 in latest image based on Debian 9.5?

[Greg]

Excellent!  This gives me the incentive to upgrade.
Python is deploying compelling new features.  Time to exercise them!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0897e2c8-3214-4943-89a8-30fd402a8b36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Python 3.7/3.7.1 in latest image based on Debian 9.5?

[Greg]

Hello, I am thinking about a Beaglebone project which will require Python 
3.7.
Does the latest image based on Debian 9.5 include, or available via apt, 
this latest version of Python?

I want the latest and greatest "event loop" with async and await features 
from asyncio module.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ccc88e6b-5909-42ba-a092-11e0ab5357cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Connecting/configuring ublox M8n GPS to Mission Planner Passthrough with BBBlu

[greg]

I'm reading through all of this and I just feel like I am very close.

When I try 

config-pin P9.21 uart
config-pin P9.22 uart

I get 

bash: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state: No such file or 
directory
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state

Same thing if I try sudo in front of the command.


The P9 output from 

sudo perl /opt/scripts/device/bone/show-pins.pl | grep P9.

is as follows (if it helps)

P9.15 16 R13 fast rx down 7 gpio 1.16
ocp/P9_15_pinmux (pinmux_P9_15_default_pin)
P9.23 17 V14 fast rx down 7 gpio 1.17
ocp/P9_23_pinmux (pinmux_P9_23_default_pin)
P9.14 18 U14 fast rx down 7 gpio 1.18
ocp/P9_14_pinmux (pinmux_P9_14_default_pin)
P9.16 19 T14 fast rx down 7 gpio 1.19
ocp/P9_16_pinmux (pinmux_P9_16_default_pin)
P9.11 28 T17 fast rx down 6 uart 4 rxd   
serial@481aa000 (pinmux_bb_uart4_pins)
P9.13 29 U17 fastdown 6 uart 4 txd   
serial@481aa000 (pinmux_bb_uart4_pins)
P9.12 30 U18 fast rx down 7 gpio 1.28
ocp/P9_12_pinmux (pinmux_P9_12_default_pin)
P9.15 34 T13 fast rx  up  7 gpio 2.00
P9.22 / spi boot clk  84 A17 fast rx down 1 uart 2 rxd   
serial@481a6000 (pinmux_bb_uart2_pins)
P9.21 / spi boot in   85 B17 fastdown 1 uart 2 txd   
serial@481a6000 (pinmux_bb_uart2_pins)
P9.18 / spi boot out  86 B16 fast rx down 7 gpio 0.04
ocp/P9_18_pinmux (pinmux_P9_18_default_pin)
P9.17 / spi boot cs   87 A16 fast rx down 7 gpio 0.05
ocp/P9_17_pinmux (pinmux_P9_17_default_pin)
P9.42a89 C18 fast rx down 7 gpio 0.07
ocp/P9_42_pinmux (pinmux_P9_42_default_pin)
P9.20 / cape i²c sda  94 D18 fast rx  up  3 i²c 2 sda
ocp/P9_20_pinmux (pinmux_P9_20_default_pin)
P9.19 / cape i²c scl  95 D17 fast rx  up  3 i²c 2 scl
ocp/P9_19_pinmux (pinmux_P9_19_default_pin)
P9.26 96 D16 fast rx down 0 uart 1 rxd   
serial@48024000 (pinmux_bb_uart1_pins)
P9.24 97 D15 fastdown 0 uart 1 txd   
serial@48024000 (pinmux_bb_uart1_pins)
P9.31 / hdmi audio clk   100 A13 fast rx down 7 gpio 3.14
ocp/P9_31_pinmux (pinmux_P9_31_default_pin)
P9.29 / hdmi audio fs101 B13 fast rx down 7 gpio 3.15
ocp/P9_29_pinmux (pinmux_P9_29_default_pin)
P9.30102 D12 fast rx down 7 gpio 3.16
ocp/P9_30_pinmux (pinmux_P9_30_default_pin)
P9.28 / hdmi audio data  103 C12 fast rx down 7 gpio 3.17
ocp/P9_28_pinmux (pinmux_P9_28_default_pin)
P9.42b   104 B12 fast rx down 7 gpio 3.18
ocp/P9_92_pinmux (pinmux_P9_92_default_pin)
P9.27105 C13 fast rx down 7 gpio 3.19
ocp/P9_27_pinmux (pinmux_P9_27_default_pin)
P9.41106 D13 fast rx down 7 gpio 3.20
ocp/P9_91_pinmux (pinmux_P9_91_default_pin)
P9.25 / audio osc107 A14 fast rx down 7 gpio 3.21
ocp/P9_25_pinmux (pinmux_P9_25_default_pin)
P9.41 / jtag emu3109 D14 fast rx down 7 gpio 0.20
ocp/P9_41_pinmux (pinmux_P9_41_default_pin)

On Tuesday, June 27, 2017 at 5:39:17 PM UTC-5, Timothy Litvin wrote:
>
> Greetings from the steep learning curve.  I’m setting up my first 
> Arduplane while learning Linux on my first AP (BBBlue) with my first GCS 
> (Mission Planner) on Windows 10, for use in a custom vessel. Practically 
> speaking, it's been a recipe for delayed gratification, uncomfortably akin 
> to a monkey with a typewriter. 
>
> I now have blue-arduplane running on the Bone (sudo 
> /usr/bin/ardupilot/blue-arduplane -C udp:192.168.8.132:14550 -B 
> /dev/ttyO5 with telemetry reporting via wifi to my Windows 10 laptop, but 
> no signal arrives from the GPS (booted, with flashing blue led). My GPS is 
> a generic ublox neo-M8n (with compass), plugged into the GPS jst-sh (wired 
> according to attached jpeg). Windows Device Manager reports ublox Virtual 
> Com Port on COM5. 
>
> I’m guessing the GPS needs to be further configured 
> , i.e., I 
> need to either download/install or create a new ublox-M8 configuration file
> . I've installed u-center to configure the GPS; u-center reports nothing.  
> That 
> feed seems to imply/require a Passthrough connection in Mission Planner 
> while running blue-arduplane) so, in the Flight Data screen, ctrl-F:
>
>- It’s unclear whether the “MAVSerial pass” button is activated on 
>click (doesn’t toggle color, just grays temporarily on rollover & click). 
>- u-center 8.25 doesn’t detect GPS on any port. Tried also creating a 
>TCP connection 

[beagleboard] Re: Just starting - looking for some guidance in development direction to take C# or C++

['Greg Matthews' via BeagleBoard]

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/446356ef-064e-401d-a15a-d3c29b8751a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Just starting - looking for some guidance in development direction to take C# or C++

['Greg Matthews' via BeagleBoard]

We have an application running on Azure servers. We need to see if we can 
do the same in the more finite resources of an embedded Linux system. 
Looking to use the BeagleBone Black Wireless - as we need Bluetooth and 
WiFi to get data from the outside world. No GUI needed.

Azure application is written in C#? Can we still use that or do we have to 
go C++?
Is Debian the best approach? (that might be asking what is the best 
religion...)
Is cloud9 IDE the way to go?
What profiling tools are there to see that the high watermarks are for CPU, 
memory, and for measuring task processing times?

Any advice would be welcome.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bef8f3eb-7a50-495d-b92a-dbb0cce8a541%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] problem flashing beagle-bone black

[Greg Jorgensen]

 can you use usb port(P3)? or is it necessary to use J1 to view boot log?



On Thu, Feb 15, 2018 at 11:37 AM, Robert Nelson 
wrote:

> On Thu, Feb 15, 2018 at 1:16 PM, grjjl  wrote:
> > We have been using a micro sd to flash a new image to a debian
> beagle-bone
> > black board.(pressing the boot button when power is applied with micro
> sd)
> >
> > we ordered more boards(same supplier same part number) and tried flashing
> > them with the same method. we have been unable to successfully flash any
> of
> > the boards. The user LED's never turn on when we try to flash the board.
> >
> > any suggestions/tips would be helpful.
>
> Please plug in a usb-serial adapter into the J1 header
>
> https://elinux.org/Beagleboard:BeagleBone_Black_Serial
>
> And please attach a boot log of a working and non-working board to the
> list for us to look at..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAAP3VynW9ymzFgaySz%3DsQSk5WRjTDz7Z2q24ThBDHR3fhfApYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using a device table overlay to disable the onboard RTC on the beaglebone black

[Greg]

I think that is what I am looking for to replace the typical "hack" 
solution I found described in a few places with a search.
The hack solution uses a systemd service and a script to force the system 
clock to the value read from the hardware clock rtc1 shortly after boot.

This works, somewhat, but I noticed the hwclock was drifting several 
seconds per day, even after connecting the board to the internet with 
network time
and allowing the drift adjustment to work.  I suspected the drift 
adjustment is not being applied to the external clock rtc1.

Note that there is a kernel option to change the hardware clock to rtc1. 
 The default is of course rtc0.  So if you are building or re-building the 
kernel this would be the easiest solution.

I'll try your device tree fragments soon and report what happens.  Thanks 
for the work on this, the clock drift problem is the last piece of one of 
my projects still not resolved.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4f7803c9-6775-4e2d-991d-c6d1e89dac53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Using a BeagleBone as a Kerberos Key Distribution Center

[Greg]

Here's the documentation for a project I've been working on:

https://github.com/Greg-R/BeagleBoneKerberosKDC

This is perhaps an unusual application of a BeagleBone.  What it does is 
act as a third-party authentication server in an NFSv4 based network.
The protocol is called Kerberos, which originated at MIT in the 1980s.

I've been running this on my home system for a few months now, and the 
BeagleBone + Debian console distro is a perfect match for this application.
It's a bit unusual for a BeagleBone project, as there is no embedded device 
code, only a complex configuration required!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e87c17ca-15c7-4678-8e23-7eb685f8879b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: How to boot from microSD card image, not from the onboard flash?

[Greg]

I'm curious, why the difference versus Debian?

I looked at the Ubuntu uEnv.txt and it has the flasher line commented just 
like Debian.
I made a bad assumption that this functionality was the same in both 
distros.

On Sunday, August 6, 2017 at 1:33:34 PM UTC-4, RobertCNelson wrote:
>
>
> > What's the difference between the "microSD" and "flasher" images? 
>
> Those are explained here: 
>
> http://elinux.org/BeagleBoardUbuntu 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6d1e0670-b37c-4eaf-bd1c-f65c80e07fba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to boot from microSD card image, not from the onboard flash?

[Greg]

I think you are probably reading some outdated information on the web, and 
there is plenty of that!

The default mode of the images should be to boot from microSD.  This is 
controlled by commenting/uncommenting a line in the file uEnv.txt:

http://beagleboard.org/latest-images

"To turn these images into eMMC flasher images, edit the /boot/uEnv.txt 
file on the Linux partition on the microSD card and remove the '#' on the 
line with 'cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh'. 
Enabling this will cause booting the microSD card to flash the eMMC. Images 
are no longer provided here for this to avoid people accidentally 
overwriting their eMMC flash."

Look at the very last line in the file

/boot/uEnv.txt

I have a Ubuntu desktop, and I can mount the image file and modify the 
file, then flash to the microSD.
Typically I develop something booting from the microSD, and later uncomment 
the line in uEnv.txt and flash to eMMC when whatever I am developing is 
ready to be permanent.
One word of advice, don't buy cheap microSDs.  Get the more robust devices 
designed for heavy duty usage.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/846ba640-8ff6-41e1-806f-0df80cd7e175%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[Greg]

Look at the link in /dev/rtc:

ls -al | grep rtc

If you got it to point at /dev/rtc1, I would very much like to know how you 
accomplished that!

On Friday, July 28, 2017 at 10:09:19 AM UTC-4, William B wrote:
>
> Greg, it's okay. I was able to make the RTC be recognized as rtc1 in the 
> system. Just turned off the BBB, disconnected everything that was connected 
> to the hardware and starts again. I'm sure the RTC module was properly 
> connected to the BBB, so I believe that there could only be some 
> configuration conflict going on.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/68e625e5-4c56-409a-b330-497e62547cef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[Greg]

Only /dev/rtc0 is going to be updated automatically.  /dev/rtc1 is not 
going to be updated automatically, as far as I can determine, with the 
Debian distributions as published.
You would have to use the config tools to switch from rtc0 to rtc1 and 
compile a new kernel.

So the common scheme you will find, for example, at the Adafruit site uses 
a script which is run by systemd to set the system time from /dev/rtc1.
This will happen soon after boot, but I am not precisely sure when.

An important point is that "system time" is what matters.  That is what you 
will see with the date command.

So the common scripts use the hwclock command with option --rtc /dev/rtc1 
(this is same as -f option) to set the system time.
So you have to assume /dev/rtc1 has been set accurately.

The best way to set the /dev/rtc1 is to use the hwclock -w /dev/rtc1 
command with the device connected to the internet and accurate NTP time 
being in force.
This command writes the system time to the RTC.  So if the system time is 
correct, the RTC time will be correct.  This is like setting any clock. 
 Thanks to the RTC having a battery, it will maintain time with Beagleboard 
power going off.
This can also be done manually at the command line if you don't have an 
internet connection (but you have another accurate time source).

So basically the common scripts floating around out there overwrite the 
system time which was set automatically with the time provided by the RTC 
/dev/rtc1.

Note that there is a compensation system for the RTC which is also included 
in the system.  I'm still working out the details on how to understand and 
manage what it is doing.  What I am doing for now is periodically rebooting 
my BBGW with it connected to the internet + NTP.  The compensation scheme 
is working, but the system time is running a little bit fast.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3ecc7c60-d153-44ee-a593-7e0f50146268%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[Greg]

There is lots of stuff going on, and it is messy.  Check out this link:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785445

I tried the configuration via udev, but as reported in the above link, it 
doesn't work.

Apparently the only way to get the /dev/rtc link to point to rtc1 instead 
of rtc0 is to change the kernel configuration and compile it that way.
I found the configuration setting, but I was too lazy to change it and 
compile a new kernel.  My systemd service seems to be good enough.
And that brings up another point.  Another system getting into the RTC act 
is systemd.  Try this command:

timedatectl

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4b73e1c8-744a-4b23-84aa-2633e6fda0ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RTC's SDA and SCL Resistors

[Greg]

I have 2 of them running here connected to BBGWs and performance is 
satisfactory so far.

On Wednesday, July 26, 2017 at 7:48:18 PM UTC-4, john3909 wrote:
>
> This looks like a much better solution given that this module is powered 
> from 3v3.
>
> Regards,
> John
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/af32f56e-3b32-4739-98b9-3d72b2c5c979%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[Greg]

Here is what I used:

https://www.seeedstudio.com/Grove-High-Precision-RTC-p-2741.html

I'm using the Greens so it conveniently plugs in to the Grove connector. 
 The lithium coin cell was not available at the local stores and I had to 
order via Amazon.
This device uses 3.3V battery and it is plug-n-play with regards to the 
hardware.  The Beagleboard distributions include a driver for it.

In addition to confusion with logic voltages, the Linux ecosystem for RTCs 
is pretty confusing as well.  The man pages have outdated or insufficient 
information.
It was possible to get the RTC to work without touching the Device Tree.

I've got the RTC to work and it is timing my irrigation control system 
reasonably well.  I'm still not confident with what I am doing with the 
hwclock command.
I've documented what I did in the PDF file page 26:

https://github.com/Greg-R/irrigate-control/tree/master/doc/latex

Good luck with the RTC and please share you results here!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/95bd10e9-2888-4a21-baa0-d2df2536cc8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone cape enclosure recommendations

[Greg]

It's a problem with the Greens.

I get the clear plastic one from Seeed Studio and don't use the sides or 
top.  So only the bottom plastic side is used, + 4 spacers and bolts.

https://www.seeedstudio.com/Acrylic-Case-for-BeagleBone-Green-p-2515.html

So you get a little protection for the bottom side of the board when it is 
setting on the desk.  You could put some stick on rubber feet to keep it 
from sliding around.
It might be possible to not use the folding lid.

The problem is even worse with the Green Wireless.

Another thing which will work, but again is not a true enclosure:

https://www.adafruit.com/product/702

This will allow another board to be bolted next to the Beaglebone.  Then 
the assembly can be bolted to something else.
I've got one of these with a BBGW and a solid state switch board mounted, 
and then the whole thing is bolted to the inside of a water tight enclosure.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b69025d2-4802-496f-8b8d-a9117b7191d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: wlan0

[Greg]

Here is a different way to do it, not sure if there are disadvantages, but 
for me easier to toggle the AP on and off.

sudo connmanctl
tether wifi on

or

sudo connmanctl
tether wifi off

In both of the cases above, the connection drops immediately.  In the case 
of tether wifi off, my wireless router picks it up right away.
When using tether wifi on, the router drops the connection, but then I can 
connect peer-to-peer with laptop wifi.  This is great for demos away from 
the home router.

Note that I have the Connman tether lines both set to no in the text file.
I don't get AP and STA modes simultaneously with this method.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/625eb270-90ab-4743-bf09-9742f893f9fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to configure node.js

[Greg]

The default Apache web server directory is usually something like 
/var/www/html.

Apache can "proxy" node.js servers, which is a good idea for security 
reasons.

But, you don't need to involve Apache at all just to experiment.  You can 
build a simple web server with just a few lines of Node.js code.
There are tons of online tutorials on how to do this.  And some very good 
books.

You didn't say how much experience you have with Javascript.  I will inject 
my opinion here, you need to read some basics of ES5, and
in particular the "var" keyword and a concept called "hoisting".  Then, 
jettison that and read about ES6 and never use var again.
But you will understand what is going with var when you see it in legacy 
code.

A very good Javascript (ES6) book which has a brief chapter on Node: 
"Learning Javascript" by Ethan Brown.

Upgrade your board to the latest recommended image.  Also, I would also 
recommend upgrading to the newest Node:

https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

Now the above may totally wreck the Beaglebone Node packages.  But you can 
always go back if you want to use the Beaglebone specific stuff.
Then begin your Node.js adventure.  If you want to see an example project 
here is one of mine:

https://www.hackster.io/Greg-R/beaglebone-green-wireless-irrigation-control-ce7c4b

Node.js+ES6 is really fantastic.  A little bewildering at first, because 
there is some much activity out there it can be hard to determine where to 
start.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d0324df0-53a0-4351-9758-8575c8ed86ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: New Beaglebone with Storage Almost Full

[Greg]

Wow, that's weird.  Are you able to get to a terminal and run this command?

df -h

Here is what my BBGW shows:

Filesystem  Size  Used Avail Use% Mounted on
udev 10M 0   10M   0% /dev
tmpfs98M  2.8M   95M   3% /run
/dev/mmcblk1p1  3.6G  1.7G  1.7G  50% /
tmpfs   245M 0  245M   0% /dev/shm
tmpfs   5.0M 0  5.0M   0% /run/lock
tmpfs   245M 0  245M   0% /sys/fs/cgroup

This is a Debian 8 IOT images, and about half of the storage is used. 
 Plenty for more stuff!

The only thing I can think of is to run the partition expander script:

sudo /opt/scripts/tools/grow_partition.sh

Check before and after running above script.  I hope it helps, but no 
promises.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/142e01d6-18b3-4bd9-96a7-2a83b0ac62f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW crash

[Greg]

I found nodejs to be amazing!  My opinion:  go with the latest and greatest 
Nodejs v8.0 and try Javascript ES6 + HTML5 + WebSockets.
Javascript is now a reasonable language and a lot of the weirdness of 
working with it is gone.
I had good luck with this project:

https://www.hackster.io/Greg-R/beaglebone-green-wireless-irrigation-control-ce7c4b

Once I got the BBGW configured to a simple station, it performed perfectly.
If you have a wireless router in your home system, the AP stuff is only 
going to confuse.  Deactivate it.

On Tuesday, July 4, 2017 at 1:10:10 PM UTC-4, Sebastián Sáez wrote:
>
> yes, I think the same.
>
> I'm going to explore the nodejs world.
>
> thanks 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/714acdf0-c508-4708-a92a-f0aa40965ec4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW | USB hub does not work

[Greg]

That's easy.  Here is before and after plugging in USB flash stick:

debian@beaglebone:~$ lsusb
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
debian@beaglebone:~$ lsusb
Bus 001 Device 003: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
debian@beaglebone:~$ 

So it does detect the USB device.
However, I didn't find the drive mounted in the usual places like /mnt or 
/media.
So that has to be done manually with the mount command?  Or maybe I wasn't 
looking in the correct folder.

Here is snippet of dmesg:

[651120.233538] usb 1-1.3: new high-speed USB device number 3 using 
musb-hdrc
[651120.475757] usb 1-1.3: New USB device found, idVendor=058f, 
idProduct=6387
[651120.475820] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[651120.475854] usb 1-1.3: Product: Mass Storage
[651120.475883] usb 1-1.3: Manufacturer: Generic
[651120.475911] usb 1-1.3: SerialNumber: D339585D
[651120.492014] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[651120.505619] scsi host0: usb-storage 1-1.3:1.0
[651120.637632] usbcore: registered new interface driver uas
[651121.509778] scsi 0:0:0:0: Direct-Access CENTON   
 8.07 PQ: 0 ANSI: 2
[651121.527501] sd 0:0:0:0: [sda] 15667200 512-byte logical blocks: (8.02 
GB/7.47 GiB)
[651121.528032] sd 0:0:0:0: [sda] Write Protect is off
[651121.528080] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[651121.528546] sd 0:0:0:0: [sda] No Caching mode page found
[651121.534237] sd 0:0:0:0: [sda] Assuming drive cache: write through
[651121.701820] sd 0:0:0:0: Attached scsi generic sg0 type 0
[651123.541720]  sda: sda1
[651123.555958] sd 0:0:0:0: [sda] Attached SCSI removable disk

Looks good to me, but this is the first time I ever plugged a USB disk into 
a Beaglebone!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a3059dd9-9661-49bf-9019-503e16e5a77d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW crash

[Greg]

I've got a BBGW bolted to the side of my house exposed to a sub-tropical 
climate.
I'm running without benefit of a UPS.  My home has a "whole" house surge 
suppressor.
I suppose the little 5V "wall wart" switching power supply is providing 
some isolation.

The WIFI is solid and quite reliable.  I have seen a few instances where I 
had to reboot the board when the WIFI dropped, however,
with the board in its remote location I am less motivated to analyze the 
problem.
I reboot by flipping a breaker in the main house panel in the garage.
WIFI has consistently come back up after reboot.

This area is one of the top areas in the world for lightning strikes, and 
the AC power is often very glitchy.

I'm surprised it has survived this long.  I'm totally satisfied with the 
level of reliability so far.
It will be interesting to see if the BBGW survives the long, hot summer.

The kernel info:

Linux beaglebone 4.4.48-ti-r88 #1 SMP Sun Feb 12 01:06:00 UTC 2017 armv7l 
GNU/Linux

I think the above is from the March version IOT Debian image at 
beagleboard.org.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/be8ce839-b927-40f9-b4bc-0f8e4a3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW crash

[Greg]

It looks possible to make the log persist:

https://manpages.debian.org/jessie/systemd/systemd-journald.service.8.en.html

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c09be8e4-ebef-43bb-ad51-0fc0b1d295e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBGW crash

[Greg]

Here is one thing to try:

journalctl -u wifidog-gateway

I hope maybe the above will yield a clue as to the specific failure.  Good 
luck.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d818fe6d-3441-4afb-a55b-ebf734bd9e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can't connect to BBBW with ssh anymore

[Greg]

Get a 3.3V USB serial cable.  You will be glad you did.  This should be 
your #1 tool priority.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d5040d76-fed0-4c31-9f5c-6f6ee5514e4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: using SYSBOOT pins as outputs....not booting from uSD

[Greg]

I had problems with those pins and found that the resistive "loading" at 
boot needs to be quite high.
I did not get this at first, and I had a bipolar transistor switch 
connected which was something on the order of 50kohms input resistance.
Well, that was too low for reliable boot process!  Sometimes it would work, 
sometimes not.  Very confusing until I found the special function of those 
pins.

Another example I had is the PRU cape.  It uses those pins, but the circuit 
attached is MOSFET input gates which are extremely high input resistance.
With this sort of circuit, the boot process is unaffected.  So it can be 
done, just be aware of the circuit you are attaching.

Since none of my projects require more than a few GPIOs, I simply avoid 
using the pins which can impact boot.
That's one nice thing about Beaglebone, it has a lot of GPIOs!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f05e2d36-fa00-41c8-ab1c-b7303d76b5eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU help needed....I don't understand pointers well enough to understand them.

[Greg]

http://icube-icps.unistra.fr/index.php/File:ModernC.pdf#file

Try the above 308 page PDF file for starters.  Click on the bird.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/df8aecc8-eeba-40ed-8fbb-fdfaa00fe492%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] VDD_5V versus SYS_5V Quick Question

[Greg]

Thanks, I did not notice the DNP.
I'll have to revise that.  It seems to work anyway.  Very little current is 
being pulled from the supply.
But I need this to be rock solid.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/65cc71ab-348d-4d32-a3a8-001648086989%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] VDD_5V versus SYS_5V Quick Question

[Greg]

I'm using a Beaglebone Green Wireless with a solid-state-relay which 
requires a 5 volt supply.
I'm trying to make the best choice for long-term longevity with the BBGW 
mounted in a remote location.

Is there any difference at all whether I use VDD_5V or SYS_5V?

>From what I can determine in the documentation, SYS_5V is merely a switched 
version of VDD_5V which is passed through the power management IC
immediately after VDD_5V is applied.

So I think there is only a very tiny difference in the timing of SYS_5V 
coming up after applying 5 volts to the USB connector,
which in the case of the Beaglebone Greens is connected to VDD_5V.

If I have got the above correct, I don't think it will make any difference 
whether I use VDD_5V or SYS_5V.
Also, the supply voltage never returns  back to the Beaglebone from the 
solid-state-relay in normal operation.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6734496a-4a6b-410b-b13f-84292674a8bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Newbie question

[Greg]

The board should have Linux installed when you get it from the distributor.
Usually the version is pretty old and you want to update it.

So you need to get an SD card and write one of the newer "image" files to 
it.

There are two ways you can go.  Run everything off the SD card, or "flash" 
onto the Beaglebone eMMC.

Running off the SD card gives you a lot of flexibility to experiment simply 
by changing cards.
But SD cards are not the best for long-term stability.

So you develop something using the SD card, and then when all is ready you 
flash the eMMC.
A change to a text file is what cause the flash to happen.

The image has a root file system and that is where /boot/uEnv.txt is 
located.
I don't use Windows, so I can't tell you what tools you need to work with 
an image file.
But you should be able to mount the image file and see the folder hierarchy 
and edit files as required.

There is a simple change to cause the flash of the eMMC and this is what 
they are referring to with the /boot/uEnv.txt.

It sounds like you may need to use your Windows machine to re-format the SD 
card and write a new image to it.
After that, you plug the SD card into the Beaglebone and power it up.
Then you have to determine how to connect to and control the board.
If you see a "heartbeat" from one of the blue LEDs you are making progress.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4bc90948-8699-497c-8549-fdd8c969324c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone Blue EduMIP Balancing Robot Assembly Video

[Greg]

Really great!  I will definitely get a Blue and see how it plays.
I think a much larger version of the robot would be a lot of fun.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cc7ad337-5070-40c1-ae5e-fde60bf9e2d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] xz images problem

[Greg]

That's an awesome set of command line tools I had never seen before.  I had 
to install kpartx (Ubuntu 16.04) and reboot.
All works after that.  rootfs even shows up in the GUI file browser.

Thanks!
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8a6a039a-2cc9-42c4-bfbd-34cfdcda2443%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: xz images problem

[Greg]

What OS are you using?  How are you expanding the xz file?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d89a10e1-4614-4874-a6dc-80410f4e4df8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Is there a GPIO status register somewhere?

[Greg]

POSIX type operating systems in general, including GNU/Linux, everything is 
done by reading and/or writing to a file.

The GPIO "files" are in the "virtual" file system located at 
/sys/class/gpio.

An example for header pin P9.14, which is GPIO 50:

cat /sys/class/gpio/gpio50/value

at the command line will return either 0 or 1, indicating the current state.
Python and other languages have "system calls" which can do the same thing.
So you could create an array of the GPIOs you want to scan and loop through 
them and determine their current state.
Different processes (programs) can read the values independent of one 
another, so your "master" will be able to accomplish this.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6c0603be-1dc8-40e9-9b5e-8ac07d539622%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] setting Beagle Bone pinmux directly

[Greg]

The kernel is doing what a kernel does, manager of the resources!
Try this in a terminal:

config-pin -h

Here's an example usage:

config-pin P9.14 low_pd

That set header pin P9.14 to a GPIO direction output and set to LOW and 
with pull-down resistor.
It works great!

Use this extremely useful spreadsheet for reference:
https://github.com/selsinork/beaglebone-black-pinmux

The file is pinmux.ods.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8caf20fa-47d3-49c8-8bb8-4e6e26bcf7ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: how delete or uninstall a software

[Greg]

Hi Eduardo-

The operating systems are based on Debian:

http://www.debian.org/

The manual for the apt system for installing/uninstalling software:

https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html

This manual is very detailed, and probably more than you need.
If you do a few searches on Debian, you can find numerous help guides.
The most common command executed in a terminal is

sudo apt-get install (name of software package)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b00774e3-4b19-4fc7-9b15-ad7382446d27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU timing with __delay_cycles()

[Greg]

1 cycle pulse is 5ns.  What instrument are you using?  Just a guess, but 
won't you need something on the order of 1GHz bandwidth to capture that 
accurately?

I used the delay cycle intrinsic successfully to implement a SPI bus. 
 However, I never attempted a 1 cycle pulse.
Other than that, the function worked perfectly.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/437f709d-9fc0-46ba-a057-889f2d04fd7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru-rproc failing on boot, working manually

[Greg]

This behavior started, I think when the Debian Jessie distribution appeared.
Prior to that, the PRUs started up at boot perfectly as far as I could tell.

Later, post-Jessie, I worked around it with similar methods to what you are 
doing.
I didn't consider it a serious problem since I could start up with either 
.profile or .bashrc.  
My projects are hobby/learning so not for serious embedded deployment.  It 
would be good to understand what is going on!

You can also try this:

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind
echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind

and this

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind
echo "4a338000.pru1"  > /sys/bus/platform/drivers/pru-rproc/unbind

If the above commands work, this might provide an additional clue as to 
what is going on at boot.

I'm hoping to get back on another PRU project soon, would be nice to get 
this mystery resolved!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dd125e46-9c99-4d95-a9b7-ac79c40274a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

[Greg Ercolano]

On 05/17/17 13:42, William Hermans wrote:
> On Tue, May 16, 2017 at 7:41 PM,  > wrote:
> I've been a C and assembly programmer since the 80's, but all of this
> with dtc is still pure greek to me. I'm assuming the original intent
> was to install the latest git version of the dtc compiler, though I'm
> not sure what implications the sed command has, so I'd defer to you or
> the OP's opinions.
> 
> Well device tree overlay source files are not C, or assembly either.
> [..] I tend to view overlay source files more as something like xml,
> or some form of a markup language.


Thanks -- I appreciate the XML analogy.

I did watch Jason Kridner's videos a few weeks ago which preped me
for learning the device tree file format; I was kinda ready for that
hurdle actually.

What I wasn't ready for was dealing with the internals of the
tools themselves. In the case of dtc, errors like "unit_address_vs_reg"
and things like uboot vs boot, and the language of the various tool
version numbers, what's mainline and what isn't..

Just couldn't grok, after only recently emerging from the wringer
of the last several days.

It's not just dtc I was encountering trouble with; it's been days
of hitting walls with other tools as well; my browser history tells
the sad tail of echo commands causing "kernel oops" errors, the pru
loader tossing up "prussdrv_open() failed" errors.. on and on.

The possible solutions to these issues led everywhere; get this
newer kernel, build this newer module, rebuild blobs, tweak boot flags..
it was supremely overwhelming and depressing.

What's wonderful about starting with the OP's disk image + script
is suddenly the sky cleared; having immediate success (minor bumps)
instead of walls of errors -- I could focus on the task at hand;
writing C code to run the PRUs.

Took hours to achieve success, instead of days achieving none.

BTW, this config-pin tool seems like maybe a way to avoid the
device tree stuff a bit; I see the LED flash example uses this.

Seems promising for my end use case where I just need to assign
GPIO pins to be in/out, and under PRU vs linux control. Its options
are kinda exactly what I need.

> C syntax highlighting in your text editor of choice to make your life easier.

Good idea -- I see there's a few vim syntax files for .dts files, e.g.
https://github.com/vim/vim/blob/master/runtime/syntax/dts.vim

In fact, with the OP's resulting disk image (and the one I posted),
using ':syntax on' in vim while viewing a .dts file seems to be
highlighting meaningfully, apparently due to this file:

/usr/share/vim/vim74/syntax/dts.vim

> Understanding the source files though just takes time, and knowledge
> of how pin-muxing, and several hardware aspect on this platform works.

Do you think the config-pin tool is a way around .dts?

If config-pin didn't exist, I'd probably write it just to avoid
having to manually derive hex codes from diagrams. (Huh, it's
a "dash" script.. cool. Was expecting python..!)

I see also someone made a web page that generates .dts,
using pulldown menus to select GPIO pins and in/out.

I like the promise of config-pin because it can be scripted;
end users could read/tweak its arguments, and a script could
check for errors and take alternative execution paths, and
print meaningful warnings on the user's console, instead of
mixed in with the voluminous output of dmesg and the syslog.

> How, I learned how the source files work, was to take one of the
> Universal IO overlay source files, and deleted everything in it
> except the main structure, and a single pin. At this point,
> you see all the different modes a pin can function as, and things
> become a bit clearer.

Cool -- if config-pin doesn't deliver for me, I'll do that!

Sounds like good advice to start with the dts file.. I take
it you mean the dts equivalent of the /lib/firmware/univ-all-00A0?

> It also helps to understand the hardware that you're trying to
> configure. Some of the simpler overlay source files such as for
> RTC, or 1-wire. Studying these should help one understand some
> things too. Such as how to load a driver from an overlay file,
> or how to configure an I2C device bus address from an overlay file.
> In the end it just takes time.

Interesting; I wasn't aware you can control the load of
device driver modules from dtc files.

I'm kinda used to using modprobe/insmod/rmmod commands
so that I can script them to check for 

Re: [beagleboard] Re: Surefire PRU - Setup.

[Greg Ercolano]

On 05/16/17 17:36, Greg Ercolano wrote:
> root@beaglebone:~/dtb-rebuilder# make
>   DTC src/arm/am437x-gp-evm.dtb
> FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
> Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
> make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
> Makefile:84: recipe for target 'all_arm' failed
> make: *** [all_arm] Error 2
> 
> Does anyone know the solution for that?

Google searches weren't helping me solve that one, so I dug into
the Makefile a bit.

Short answer seems to be to change this line in the Makefile:

-DTC_FLAGS += -Wno-unit_address_vs_reg
+#DTC_FLAGS += -Wno-unit_address_vs_reg

..when I did that, it breezed through the build without errors.

Will move onward to try to get an error free result.


DIGRESSION
==

Regarding figuring out how to solve the above, it was obvious 'make'
wasn't showing the commands being used to build the targets, so I wanted
to see what was going on when it failed.

The Makefile comments indicate there's some kind of convention to keeping
the noise of the build down, using two Makefile variables 'quiet' and 'Q'.

I found I could get make to show the commands being executed by changing
this section of the Makefile:

 ifeq ($(KBUILD_VERBOSE),1)
   quiet =
   Q =
 else
-  quiet=quiet_
-  Q = @
+  quiet=
+  Q =
 endif

 With that modification, running 'make' showed the full command
 being executed. So instead of just showing this:


DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 ..it now showed the full commands being executed:


  make ARCH=arm all_arch
  cpp -Wp,-MD,src/arm/.am437x-gp-evm.dtb.d.pre.tmp -nostdinc -Iinclude 
-Isrc/arm -Itestcase-data -undef -D__DTS__ -x assembler-with-cpp -o 
src/arm/.am437x-gp-evm.dtb.dts.tmp src/arm/am437x-gp-evm.dts ; /usr/bin/dtc -O 
dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm -Wno-unit_address_vs_reg -d 
src/arm/.am437x-gp-evm.dtb.d.dtc.tmp src/arm/.am437x-gp-evm.dtb.dts.tmp ; cat 
src/arm/.am437x-gp-evm.dtb.d.pre.tmp src/arm/.am437x-gp-evm.dtb.d.dtc.tmp > 
src/arm/.am437x-gp-evm.dtb.d
  FATAL ERROR: Unrecognized check name "unit_address_vs_reg"


 There's actually three commands being run in one line there;
 cpp, dts, and cat. The 'dts' line is the one that failed:

  /usr/bin/dtc -O dtb -o src/arm/am437x-gp-evm.dtb -b 0 -@ -i src/arm 
-Wno-unit_address_vs_reg -d src/arm/.am437x-gp-evm.dtb.d.dtc.tmp 
src/arm/.am437x-gp-evm.dtb.dts.tmp

 ..and there's the "-Wno-unit_address_vs_reg" flag that dtc was
 complaining about.

 The man page for dtc doesn't describe a -W flag, but I'm assuming
 it's a compiler warning flag of some kind, perhaps like gcc's.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/591BB3A1.5090305%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

[Greg Ercolano]

On 05/16/17 17:17, Greg Ercolano wrote:
> On 05/16/17 16:56, ercolano7...@gmail.com wrote:
>> I did notice a few error messages using the OP's disk image + script..
>> [..]
>> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
>> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
>> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.  
>><--
>> Please install the linux-headers-4.4.27-ti-r62 package,  
>><--
>> or use the --kernelsourcedir option to tell DKMS where it's located  
>><--
>> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.
>><--
>> Please install the linux-headers-4.4.27-ti-r62 package,  
>><--
>> or use the --kernelsourcedir option to tell DKMS where it's located  
>><--
> 
> [..]
>  In my case, after the reboot, I noticed the active kernel was the new one
>  the prep script downloaded (4.4.27), as reported by 'uname -r'..
>  so this seemed to be the appropriate command to install those headers:
> 
>   apt-get install linux-headers-`uname -r`
> [..]
>  Will try to follow up with what I find..

Hmm, so after the new kernel headers were installed, I verified
there's now a 'build' link in the modules directory for that kernel version
that wasn't there before:

# ls -la /lib/modules/4.4.*/build
lrwxrwxrwx 1 root root 36 Oct 26  2016 /lib/modules/4.4.27-ti-r62/build -> 
/usr/src/linux-headers-4.4.27-ti-r62   <--
lrwxrwxrwx 1 root root 35 May  5  2016 /lib/modules/4.4.9-ti-r25/build -> 
/usr/src/linux-headers-4.4.9-ti-r25

..which is good, because I know building device drivers need that link
to exist.

So I then retried making the project the prep_pru.sh command failed to 
build,
but still getting these weird errors:

root@beaglebone:~# export DTB=~/dtb-rebuilder/src/arm
root@beaglebone:~# cd /root/dtb-rebuilder/
root@beaglebone:~/dtb-rebuilder# make clean
  CLEAN   src/arm
root@beaglebone:~/dtb-rebuilder# make
  DTC src/arm/am437x-gp-evm.dtb
FATAL ERROR: Unrecognized check name "unit_address_vs_reg" <--
Makefile:136: recipe for target 'src/arm/am437x-gp-evm.dtb' failed <--
make[1]: *** [src/arm/am437x-gp-evm.dtb] Error 1
Makefile:84: recipe for target 'all_arm' failed
make: *** [all_arm] Error 2

Does anyone know the solution for that?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/591B9AFB.3090004%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Surefire PRU - Setup.

[Greg Ercolano]

On 05/16/17 16:56, ercolano7...@gmail.com wrote:
> I did notice a few error messages using the OP's disk image + script..
> While the script ran, I saw these errors scroll by -- is this something I 
> should ignore?
> _
> [..]
> Unpacking linux-image-4.4.27-ti-r62 (1jessie) ...
> Setting up linux-image-4.4.27-ti-r62 (1jessie) ...
> Error! Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.   
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
> Your kernel headers for kernel 4.4.27-ti-r62 cannot be found. 
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
> Error! Your kernel headers for kernel 4.4.27-ti-r62 cannot be found.  
>   <--
> Please install the linux-headers-4.4.27-ti-r62 package,   
>   <--
> or use the --kernelsourcedir option to tell DKMS where it's located   
>   <--
>[..]


 I think the solution here would be to include an "apt-get" in the prep 
script
 before this point to install the correct linux-headers-x.x. package, 
based
 on whatever new kernel was found during the upgrade process.

 In my case, after the reboot, I noticed the active kernel was the new one
 the prep script downloaded (4.4.27), as reported by 'uname -r'..
 so this seemed to be the appropriate command to install those headers:

apt-get install linux-headers-`uname -r`

 I'll see if I can work that into the prep_pru.sh script, and supply a 
patch.
 I imagine I'll have to replace the `uname -r` with the downloaded linux 
image value,
 as at that time the script is running, 'uname -r' will report the wrong 
kernel version.

 I should probably re-do the imaging procedure, and re-run the prep script
 from scratch with the change applied, as I'm not sure the prep_pru.sh 
script
 is designed to handle being run more than once (at least, not in its 
current
 incarnation, as it appears to append to .bashrc and /etc/rc.local without 
checking
 if the mods are already there..)

 Will try to follow up with what I find..

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/591B96AE.8090805%40seriss.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Creating hotspot in BeagleBone Green Wireless

[Greg]

Here is the inverse.  I might give you some ideas on how to proceed.

https://groups.google.com/forum/#!category-topic/beagleboard/3GBe_ueZ4Z8

I have been using the BBGW to develop a home automation project.  BBGW is a 
perfect fit, working great!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/09c23967-64ee-4427-85ed-2e19ed2e3322%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone black ssh problem

[Greg]

A highly recommended accessory is a USB to serial adapter cable.  It will 
need to be the 3.3volt version, like this example:
https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A/ref=sr_1_4?ie=UTF8=1493243765=8-4=3.3v+serial+to+usb

There is a 6-pin header on the Beagle Bone which you can plug this adapter 
cable into.  The other end is USB, and then you will need a terminal 
program on the computer.
I use a Linux terminal emulator called screen.

When you connect in this way, you will have full access to the file system 
and you can fix whatever it is that got changed.  This method bypasses the 
complex networking stuff like USB or Ethernet.

Another very practical approach is to use the Micro-sd memory cards and do 
not flash to the onboard flash drive.
Be sure to get a ruggedized card and it will be more reliable.  I'm done 
with the cheap cards, they will waste your time.
When you get to the point where your software is solid, you can flash to 
the onboard drive.  This will be the ultimate reliability.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dbc44cf8-dc88-441f-acfc-ae99c0b3acb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[Greg]

You could view the implementation of overlays as an optimization pass.

Greg

On Wednesday, April 26, 2017 at 11:50:02 AM UTC-4, ThomasL wrote:
>
> Edit: This was wrong. Using the config-pin scripts we got everything 
> working even at higher frequencies (30MHz). We are going to have a look at 
> the overlays later. 
> Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL:
>>
>>
>> Also, we presume that when using the cape-universala with pin config we 
>> are doing the toggles trough software with the bone-pinmux-helper instead 
>> of connecting register 30 to the output pads. We only get a toggle speed of 
>> around 2MHz which should be way higher if it was the PRU controlling the 
>> pin directly.
>>
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fcd56bbd-6c9c-4b7e-94a3-612448a5fad0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[Greg]

If the config-pin works, why not put the command(s) in a start-up file and 
be done with it?

Just my opinion, don't touch the device tree blobs unless you absolutely 
have to.
And if you have to, use Robert's scripts to rebuild them.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/048ef0de-23e6-4861-9c66-17328d337955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Greg]

Excellent!  I did a couple of projects with PRU and C code, and this type 
of tutorial is sorely needed.

I would add a link to this:

https://training.ti.com/pru-compiler-tips-tricks

So I wonder how common it is to use a C union and bit selector?
When I first encountered this in the PRU header files, I didn't even think 
it was C code!
In fact, in the information provided by TI in the video and slides, they 
say it is really warped C code.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Availability of the beagleboard blue

[Greg]

https://www.seeedstudio.com/BeagleBone-Blue-p-2809.html

The above is not listed in the sellers on the official page.
Unfortunately, they are back ordered.  I assume they can ship to Denmark, 
but you will have to contact them.

I would assume the supply "pipeline" will take a while to reach capacity.

Good luck finding a Blue.  It looks like a great board!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/065d9ed2-f89e-454e-ad33-e609b5f74359%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Struggling

[Greg]

Caution, I'm not a Mac user, however, the Mac operating system has a 
"shell" which is very similar to the shell in Linux.
So if you can get to the Mac shell, then all of the Linux specific 
information will be useful to you.
If you can open a shell in your Mac, try this with the BBB:

ssh debian@192.168.7.2

The shell should respond with a login dialog.  The user should be debian, 
and password temppwd.

The intro page does say there is a USB driver required, however, I think 
you may have gotten past that.
http://beagleboard.org/getting-started#step3

If your goal is to learn Linux, you need to get familiar working via 
command line in the shell (also called terminal).

Be wary of flaky Micro SD cards.  If you have another spare one, give it a 
try and see if it works.
My experience is that the cheap Micro SD cards are not robust. Once you get 
a working ssh connection and the system is stable
you can do a simple text edit which will cause the SD card to be written to 
the EMMC (flash memory + controller).
Then you can remove the Micro SD and your BBB will be more reliable.

Also I would recommend getting away from the USB as soon as possible.  I'm 
sure your Mac has a LAN connector.  Get a cable and use that instead of the 
USB.

Good luck!
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1f4ea732-dfee-4787-98bd-d02f6325ee4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Robots. Fast. BeagleBone Blue is here!

[Greg]

At Hackster.io:

https://blog.hackster.io/introducing-the-beaglebone-blue-58d040e9f69e#.a9axku66j

Congratulations, this looks like an incredibly capable board!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/597cfe41-cc1b-4376-b649-f1b891143364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Difference between the console image and the IoT image

[Greg]

The console image is minimalist.  It doesn't have application software like 
servers already installed.  This is good if you are developing a board for 
some security application where the "attack surface" should be minimalized.

You will find that you need to install basic stuff like git.  Console is 
not the best starting place for a beginner.  Go with the IOT.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4381c4fe-2a20-4d11-93c2-acaef1cec381%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Loading .out onto PRU

[Greg]

Hi Justyn-

There are of course many ways to work with the PRU, but if you want "latest 
and greatest" that would be via RemoteProc framework.  And if you are 
working with the TI labs, you have already been exposed to it.

I don't work with CCS (might in the future as I saw recently there is no 
longer a license fee), but instead I did everything at the command line via 
SSH.
And I used the Beaglebone Green with Debian based IOT image (TI kernel). 
 If you look at this project, there is a link to a github repository which 
has a PDF file in the doc folder.
There are a couple of sections in the PDF which show how to configure it 
all on the BBG Debian IOT:

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805

RemoteProc framework does the work of loading the PRU firmwares into the 
PRUs and starting the processors.

It's just an example, have a look and it might give you an idea where to go 
next.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ae4abf39-11c3-4438-b6fd-6437526959af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU Development

[Greg]

Hi Mike-
>
>
There are several possible paths.  Since you mentioned Derek Molloy's book, 
here is my project which was inspired by his chapter on the PRU:

https://www.hackster.io/Greg-R/beaglebone-pru-adc-a42a71

If you look at this, you will see that I used the RemoteProc framework. 
 This framework is relatively new and experimental.  I have found that TI 
is supporting this quite well and for the most part it worked well in the 
limited project space I have worked in at this time.

There is also the UIO based framework which is more mature and has many 
successful projects developed with it.

With regards to getting up and running, you need to be aware of some set-up 
you will have to do whatever route you chose.
Here is another project I have published which includes documentation to 
guide you through the set-up of RemoteProc framework.
There are some details which I think would also be useful if you go the UIO 
route:

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805

I am still working on the above project to re-implement the web interface 
using a Node based server.  Or maybe Python.  Not sure yet.

In general if you Google search on the PRU, you are going to find many 
paths which lead you down a dead end.
There is a huge amount of obsolete data information out there.  Even a lot 
of the TI stuff which is outdated was still out there the last time I 
looked.
For example, there are a lot of projects based on the PASM compiler.  This 
is the original compiler for the PRU.  That old compiler is good and used
by many successful project, but it is no longer supported by TI.  The new C 
compiler (which also compiles assembly) is supported, and though similar
to the instruction set of PASM, there are some differences.  So that is 
another decision node.

So that's what I know, good luck with your project!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8904e039-64f5-4bce-96ec-1510681e39e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Is there a web server on the BBB

[Greg]

Take a look at:

/var/www/html

I've got an Apache2 server at (ipaddress):80.
But I don't remember if that was by default or I added Apache2 later.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1a675670-21d6-4c48-8bd0-e13acbce725f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

The am33xx-pruss-rproc.dtsi file has to included to activate the RemoteProc 
framework.
I don't have any good links to the details, however, there are two 
frameworks for working with the PRUs that I know of:
UIO
RemoteProc

UIO is far more mature, and from reading various postings here it seems to 
have some performance advantages.
There are kernel space drivers, and RemoteProc is an example.
There are user-space drivers, and the UIO framework is an example.
You have to start drilling into operating system details, but don't ask me 
as I am going up the learning curve on this stuff slowly.
If you do some searching there is tons of material to read.
This is good stuff, but there are thousands of details.

Anyway, since some are using UIO, and some are using RemoteProc, it is left 
to the user to select the active PRU driver framework.
So that is why you have to edit the dts file and re-compile.

Be cautious when loading overlays.  There is lots of obsolete info out 
there.  You should edit uEnv.txt in the boot directory to accomplish this.
Don't try to use config-pin or the echo slot method which you will find all 
over the web.
It might work, or it might not, but it is not worth messing with it.  Just 
edit uEnv.txt and you will get the job done.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a90be576-70d9-474c-aadf-a97d3d1d5a44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

OK, great!

So exactly which firmware are you using?  In my docs, for set-up purposes I 
suggest the PRUmsg Echo Lab 5.

So this example does not intentionally toggle any GPIO.  The idea is that 
if you can get this lab to work, the PRU RemoteProc kernel drivers are 
completely functional.

The final thing to do with this example is to compile the user-space C 
program and run it.
I think the Makefile handles this, but compiling any C program for 
user-space is easy:

gcc main.c -o pru_msg_test

or something like that.
Running the user-space test program does a simple exercise of the 
RemoteProc messaging character devices.
Lab 6 toggles an LED using the PRU and uses the same character device 
mechanism to control the PRU.
Let me know if you have any more questions.  I think you have gained a lot 
of capability to experiment with the PRUs.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b3082d33-b51d-42e5-8db9-f8b3082f9bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

There are two examples, one for PRU0 and another for PRU1.  So you will get 
rpmsg_pru30 for PRU0, and rpmsg_pru31 for the other.
So if you are seeing rpmsg_pru31, this is a major step forward and you have 
it working!!!
Also note the "c" at the first column of the ls; this indicates a character 
device.  It's good news.

So I think the scripts prumodin and prumodout must be looking for the wrong 
file names.  It is probable they are not consistent as kernel changes are 
rolled out.
So:

ls /sys/bus/platform/devices

Do you see PRU related entries as shown in the set-up documentation?  There 
are probably small differences which are breaking the scripts.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9ba83d52-6d26-473f-ac4d-0ab9a8601e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

I think you are making progress, but I'm having a little trouble following 
the grep pru.

You should end up with 2 firmwares in /lib/firmware with very specific 
names:

am335x-pru0-fw
am335x-pru1-fw

Just do

ls /lib/firmware

and see if they are there.
Also:

ls /dev

If you got through the example from the support package, there should be a 
character device file there:

rpmsg_pru30

If you get the above, that is a very good sign that everything is 
configured and working.
Note that you will probably have to reboot for the character device to 
appear after successfully compiling the firmwares and moving them 
/lib/firmware.

Toggling a GPIO is easy.  You will need to use the __R30 special register 
variable.
Look in the am335x examples directory of the PRU support package:

PRU_gpioToggle

Yes you are correct I didn't use the CCS.  In the case of the PRUs, simple 
projects are not creating libraries of code.
And the C code files for the PRUs are no problem for the BeagleBone itself 
to compile.
If you have used a cross-compiler set-up before, there is a lot of 
configuration required, and probably debugging of problems.
I did see a note that the CCS no longer requires any sort of license.  I 
might go back and look at it in the future,
but for now the command line via SSH is more than adequate for what I want 
to achieve with the PRUs.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e31269c3-803c-4d9b-b177-1cc953ad06b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

I wouldn't update the kernel at this time.  Yes, try the procedure and see 
what happens.  I think you will be successful.  If not, we can work through 
it.

That kernel is the TI version and it should be good to go for sure.  If 
not, there are problems we are not going to solve without help!
It's still not clear to me the differences between the TI and the Bone 
kernels.  The TI kernels definitely support the latest Remoteproc.

If you don't need GUI, stick with the IOT image.  I've had very good luck 
with it.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/50da6b9a-be95-494f-8a21-a179fc1e714c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

I successfully update to the new kernel, it was version 45, not 44 so even 
a little bit newer.

After updating the DT with the pru include, I rebooted.  No ethernet!
Also, I can tell from the LEDs that something is very wrong.
The heartbeat is there, but one of the other LEDs is blinking steadily and 
quickly.

I'll get the USB serial and see what is going on.

Meanwhile, if you decide to re-flash the 16G card, then if you simply leave 
the kernel as it is we can probably make some progress easily enough.
I'm pretty sure the kernel is the same as from the IOT image, and that one 
I am sure works.

This is a good illustration of why I cringe when any Device Tree stuff has 
to be touched!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/090f6582-246d-4543-83d7-a0fdf1f592e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

Can you tell me exactly how you got the kernel 4.4.44-bone16?

I need to replicate this step exactly.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5a438bfb-a522-4cea-9864-f2c53983c56d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

I have the same hardware available here.  I have not tested the LXQT image, 
only the IOT and it was with Beaglebone Green.

I'll try to get the image and written to the SD card later today.  It only 
takes a few minutes for the process including the Device Tree change.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/774b9a00-a1e2-47b6-afea-bf47f28e5a36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

Can you tell me which IOT image you are using?  Which Beaglebone?  Did you 
update the kernel recently?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/93c03ac0-9e5b-478f-b86d-c98c0f30346e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

You are using a very new IOT image.  I'm still using one from December 2016.

If I can get a few minutes later today, I'll try that new image here.
I'm not sure what to suggest to try next.
Hopefully you can get your ethernet running again.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1da038d6-aaea-4bad-8f28-5f560af24350%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

Hi Ashwini-

It's not clear that you have modified the device tree to activate a PRU 
driver framework.
Check out this discussion:

https://groups.google.com/forum/#!category-topic/beagleboard/JQ14qQC-Ggw

If you did in fact activate the driver, then please ignore this message.

Please be aware that lsmod may show a driver, however, that doesn't mean 
that it is active.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6f9926c7-b8c3-41f3-9497-0af2d724cce7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: first steps with BBG

[Greg]

Hi Fabian-

The image does not have a PRU driver activated.  You have to make a very 
small change to the Device Tree in order to activate a driver.

There are two choices:

RemoteProc
UIO

So the link you included discusses the UIO, and the TI examples will need 
RemoteProc.
There are trade-offs with either approach.  I am not familiar with UIO, but 
I have done some experiments with RemoteProc.

Check out this project at Hackster.io:

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805?ref=search_id=remoteproc=1

Follow the link to the Github project, and then get the PDF file 
pru-pid.pdf which is included in the doc directory.
See Chapter 9 for a step-by-step process to enable the RemoteProc driver.
The process for enabling UIO should be similar.
Be sure to be in root mode (sudo su) when you are editing the files.
After you successfully get your driver system running, you should be able 
to get either UIO or Remoteproc examples working.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/94d958f5-4666-4010-8c9b-f4cd2d4348d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can a PRU tell if it's PRU0 or PRU1?

[Greg]

I thought of another way.  Kind of crude, but it might work.  This would 
allow the firmwares to be identical.

Assuming you have a spare PRU GPI in each, you could set the pull-up on one 
pin, and a pull-down on the other.
Then you just read the appropriate value of the bit in __R31.  Of course 
you would have to carefully select the pins so they are the same bit in 
__R31.
So if those pins are spoken for in your application, this isn't going to 
work.

Hopefully someone will know a method which is baked-in to the system.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2516cd7b-d0ab-4a95-85a8-b26b832e8b94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can a PRU tell if it's PRU0 or PRU1?

[Greg]

So you are saying the firmware loaded to both PRUs has to be exactly the 
same?
You can't use a slightly different #define to make a different constant in 
PRU0 vs PRU1?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1ce9e780-9201-46f4-8132-b778c1bdea5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Green Wireless with Debian 8.6 IOT Image any tips on WIFI?

[Greg]

All working now!  Here is an outline of the process.

The goal is to have a working wireless substitute for the ethernet 
connector which does not exist on the BeagleBone Green Wireless.
This is for a "headless" embedded project with the primary access using a 
terminal and ssh.

Download and expand the IOT bone image per Robert's link and flash to 
micro-sd.  I used this one:
bone-debian-8.7-iot-armhf-2017-01-15-4gb.img

Write the image to the micro-sd (I put the micro-sd in a USB adapter 
plugged into my Ubuntu workstation):

sudo dd if=bone-debian-8.7-iot-armhf-2017-01-15-4gb.img of=/def/sdb bs=8M

Eject the micro-sd from workstation and insert in the BBGW micro-sd slot.
Connect a USB 3.3V serial device to the "debug serial header".  The USB 
network connection could be substituted, however, my experience
with this is that using the serial device is solid and will work 
consistently.
Also, since the BBGW doesn't have a dedicated power connector.  It uses the 
micro-USB.
It is my preference to use a high-current dedicated USB power supply and 
ignore this as a possible network connection.

Power-up the BBGW and wait for the boot process to complete.
Open a bash terminal and use screen to connect via the serial USB device.

screen /dev/ttyUSB0 115200

I had to hit enter after the above command to get to the login prompt.
The login user is debian and the password is temppwd.

You may have to install screen:
sudo apt-get install screen

After logging in, a good thing to do first is to run this shell script:

cd /opt/scripts/tools
sudo ./grow_partition.sh

Next:

ifconfig

You should see 4 different network resources (not showing the full output 
here):

SoftAp0
lo
usb0
wlan0

The network resource SoftAp0 represents an "access point".
Apparently the BBGW is configured as a wireless router!
That is not the goal, and fortunately this is easily removed.
As Robert described above, edit the file:

/etc/default/bb-wl18xx

Change the line:
TETHER_ENABLED=yes

to

TETHER_ENABLED=no

Save and exit, and reboot, and login.

ifconfig should now show only 3:  lo, usb0, and wlan0.

Now to configure WIFI!  It is assumed you have a home wireless router and 
you know the SSID and passphrase.
Also that the router is configured for DHCP (automatic assignment of IP 
addresses).

sudo connmanctl
connmanctl> scan wifi
Scan completed for wifi
connmanctl> services
(your router broadcast) (router info)
connmanctl> agent on
Agent registered
connmanctl> connect (copy router info here)
Agent RequestInput (router info)
  Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
  WPS = [ Type=wpspin, Requirement=alternate ]
Passphrase? (your passphrase)
Connected (router info)
connmanctl> quit

The above configuration is permanent and will survive reboot.
An outstanding page with good info on connman:

https://wiki.archlinux.org/index.php/Connman

Another very good thing is to login to your router and use this to 
determine if your BBGW is successfully connected.
And remember the router may have security settings which may block it from 
connecting.
Also, rather than attempting to force a fixed IP address on the BBGW, I 
used the "address reservation" feature
so that the IP address assigned by the router will be the same each time it 
connects.  This is done using the MAC address of the BBGW.

After the above configuration is done, shutdown and remove the USB serial 
device.
Power up the BBGW and wait for it to boot, and then using a terminal and 
ssh you should be able to connect to the BBGW as if an ethernet cable was 
connected:

ssh debian@(the assigned IP address)

After logging in you should have internet connectivity, so don't forget to:

sudo apt-get update

Here is an example USB serial device.  This should be on your tool kit list:
https://www.amazon.com/gp/product/B01AFQ00G2/ref=oh_aui_search_detailpage?ie=UTF8=1

Thanks Robert for the tip on the 8.7 image!  After switching to the new 
image all went very smoothly after that.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/049d039f-ff12-40b4-a339-fbc151a74168%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone Green Wireless with Debian 8.6 IOT Image any tips on WIFI?

[Greg]

I've got a Seeed Studio BBGW and I'm having trouble getting the WIFI to 
function.
The usual searching around was unsuccessful.

I'm into the board with the USB UART device, and all appears well, but the 
ifconfig command shows only usb and local loopback networks.

The file /etc/network/interfaces has some commented lines which suggest 
using "connmanctl", I tried these and only got back strange errors like:

debian@beaglebone:/etc/connman$ connmanctl
connmanctl> enable wifi
Error wifi: Method "SetProperty" with signature "sv" on interface 
"net.connman.Technology" doesn't exist

connmanctl>

Anyway, does anyone have some tips or a tutorial on how to get the BBGW 
WIFI up and running?
I don't want some sort of access point, just a regular ethernet LAN type 
connection.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4f2befd8-805a-4bb1-9514-89f20bc200ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Figure out how to configure correctly modules, pins, and PRU to blink a led

[Greg]

There was nothing particularly practical about that PRU-ADC project.  It 
was a means of learning PRU C programming, SPI bus, RemoteProc framework, 
and user-space C code (and others).
It was an extremely good learning experience!  I want to apply the 
knowledge gained to robotic projects and also I am interested in Software 
Defined Radio.

I'm pretty sure that others have successfully accessed the internal ADCs 
from the PRU.  If you do some searching I think you can find a specific 
instance.
I think it should be possible via the PRU's OCP master port.

On Monday, January 16, 2017 at 10:41:47 AM UTC-5, in...@orionitalia.com 
wrote:
>
> Thank you, Greg!
>
> Device Tree was really confusing to me, probably due to the fact that I 
> was using also examples from 3.8.
>
> By the way, I saw that you used an external ADC in your project, while I 
> am scouting to use the internal ADC via PRU. May I ask why you did not use 
> the internal ADC for your project? Do you know if it is feasible to use the 
> internal one instead of an external?
>
> Regards,
> Lorenzo
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b97cd400-7502-4001-9b8b-34cc060b23ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Figure out how to configure correctly modules, pins, and PRU to blink a led

[Greg]

Lorenzo, nice to hear you are making progress.
The Device Tree configuration is a significant barrier and once you break 
through that things will move quickly.
I think you will find the rest of the examples will work relatively easily.
Good luck and have fun with your project!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e2dd0567-1d66-4242-bbd4-18459f2d7814%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: High speed encoder input capability of BBB?

[Greg]

On Wednesday, October 5, 2016 at 12:11:18 PM UTC-4, beezerlm wrote:
>
> Well I have obtained a BBB along with the PRU cape.  I soldered the Jtag 
> header on and I purchased a blackhawk XDS100v2 JTAG Emulator.  I istalled 
> CCSv6 and I have completed the PRU labs 1 through 4 - found here: 
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Hardware
>  
>
> I am trying to figure out where to go from here.  Libpruio looks 
> promising, but I would like to take the path that would offer the best 
> overall determinism & latency characteristics for reading encoder input and 
> controlling IO accordingly.   I would think the best case scenario would 
> be to program the PRU directly and skip linux altogether.  This may be 
> overkill for my current project, but it seems like it would be useful for 
> more demanding applications I may cross in the future.
>

Here is a simple project which might help you with "where to go from here":

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805?ref=search_id=remoteproc=1

This project uses one of the Encoder modules which the PRU accesses via its 
OCP master.
The PRU has its own encoder, but it has only one pin wired out, and in this 
project that pin is used in PWM mode.
The encoder function must be quadrature (2 wires), so even if the PWM was 
not being used it would have to use an external encoder.

The project uses RemoteProc which you have already encountered in the Labs.
RemoteProc will take care of loading the firmwares as well as provide a 
simple two-way communications channel between the PRUs and user-space.
The most expensive component (besides the Beaglebone) is the motor-encoder 
which you can get from eBay for about $20.

At the very least you can look at the C code for the PRU firmware and you 
can see how the external Quadrature Encoder module is accessed from the PRU.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d9a210a0-944c-4b8d-9338-40318c20f591%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Remoteproc dynamic firmware change. Module in Use Error.

[Greg]

Interesting.  On more recent distributions I did not have to use the -f 
option.
In some earlier TI documentation, rmmod -f was the recommended method to 
remote the PRU RemoteProc module.
But there have been changes since then and the PRU RemoteProc framework has 
continued to mature.

Please see the documentation in this project for another method to control 
RemoteProc from sysfs in user-space:

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805?ref=search_id=remoteproc=1

Follow the link to the github repository.  The documentation is in the doc 
directory.  Look for the PDF file.
Also there is a link to ZeekHuge's github repository where you can find 
more information.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fd0abeb8-e942-4e23-b08e-2cabf18693a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Figure out how to configure correctly modules, pins, and PRU to blink a led

[Greg]

Hi Lorenzo-

An important file to view is the kernel log.  At the command line:

dmesg

You should be able to find messages in this log which indicate success or 
failure of PRU firmware loading.

Did you successfully modify the Device tree in order to enable the 
RemoteProc kernel drivers?  This is a relatively new requirement.
A more recent project includes the steps to enable RemoteProc:

https://github.com/Greg-R/pru-pid-motor

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7ee3dab5-68f5-49a6-896a-d7b2164af949%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Remoteproc dynamic firmware change. Module in Use Error.

[Greg]

I've never seen the FATAL error.

The following should work:

rmmod pru_rproc
modprobe pru_rproc

The above commands remove the remote proc kernel module, and then reinserts 
it.
Your revised firmware should be loaded after executing the modprobe command.

You will need root access or sudo prefix to the above commands.
What distribution are you using?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2c1226b9-fc9a-4e1c-8c50-9ee48dae95a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[Greg]

Hi William, great inputs and perhaps we can ask Clayton to push these 
additional details to the repository.

There should be a clear delimiter between the current and experimental 
improvements.
I wonder if there is going to be a distinct cut-over to the revised Uboot 
process?  Maybe too soon to determine.

Another thing:

1.  dtb-rebuilder
https://github.com/RobertCNelson/dtb-rebuilder
2.  bb.org-overlays
https://github.com/RobertCNelson/bb.org-overlays

Perhaps not a newbie concern, as I think 1 and 2 above are at the 
intermediate level. 
I think these should at least be mentioned as they are important bits for 
dealing with the Beagleboard Device Tree ecosystem.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d7035e17-09a1-4839-b287-cfcecc60576d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[Greg]

Nice!  I will add this as a reference to my project documentation.

Regarding the fact that you have to run config-pin after each boot, you can 
add a section that the config-pin commands can be added
to whatever start-up configuration is most appropriate.

The way I am doing this currently is to simply list the commands in a text 
file like:

config-pin P8.30 pruout
config-pin P9.31 pruout
etc.

Then add this to the .bashrc file in the home directory:

source (path to the above file)

Then the configuration is done automatically!
Check this discussion for some other interesting info on Device Tree:

https://groups.google.com/forum/#!category-topic/beagleboard/1iFM1ywGQX4

The impression I have gotten, and I could be wrong, is that adding or 
subtracting overlays at the command
line is a not guaranteed to work operation.  The overlays should be 
reliably controlled via uEnv.txt and the eeprom.

On Sunday, January 1, 2017 at 4:49:57 PM UTC-5, Clayton Gulick wrote:
>
> Ok, here's the first draft: 
> https://github.com/claytongulick/beagle_bone_black_spi/blob/master/README.md
>
> Corrections and additions are welcome!
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[Greg]

Hi William, if you could point to an easily discoverable source which says 
that Universal IO is available in the latest images and encouraged to be 
used, then you could be correct.
Being able to successfully manipulate the SOC multiplexer is fundamental to 
getting a Beagleboard project off the ground.
If there is no such info, which should be right at the top, then Clayton's 
post is a pretty good version 1.0 guide for newbies.

On Sunday, January 1, 2017 at 2:12:45 PM UTC-5, William Hermans wrote:
>
>
> Additionally, I've been thinking this the whole time after this post, but 
> . . . the information given here. Isn't exactly the best. I wasn't going to 
> say anything, but now that I'm already posting . .  However I can pretty 
> much say with 99% certainty this is because of the lack of experience from 
> the OP. spidev's been around, and I happen to know someone who is very 
> familiar with Linux, and got it working in a matter of minutes, from 
> nothing. That is, to say. He was also new to the Beaglebone black, at that 
> time. So . . .
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/339f0b0e-aa36-4458-a49a-26b373584f01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[Greg]

Hi Clayton, what you have written is correct and the Device Tree is a 
significant barrier to entry.
The Universal IO is a good solution to this, and I've had good luck with it 
while keeping in mind my requirements to manipulate the Device Tree have 
been minimal.

The Beagleboard is driven by the community, and it is a wonder such a 
complex piece of technology is accessible at all!
The Linux kernel has something like 8000 developers contributing, making it 
perhaps the largest engineering project in human history.
The complexity of this technology is breathtaking!  I very much appreciate 
what the community has done and I have learned a great deal and also had 
fun.

In looking about, Github appears to be the de-facto standard for sharing 
information in electronic form, and the Beagleboard related stuff is there.
But not all of it, especially documentation, is located in several wiki 
pages.  These pages are not reliable.

So what I am getting at, is that Github is an accepted means of publishing 
documentation, and you can get a public account for free.
If you could tidy up your post, and put it in publishable form, I think it 
would be a good contribution to the community.
As far as what "publishable form" means, that could be as simple as 
Markdown, or better yet a PDF file, which Github can display in the browser.

Just a suggestion, good luck with your projects and please let us know how 
it is going.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/42488410-1f08-42eb-8aa4-30d403225f30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using peripherals / accessing registers in PRU C

[Greg]

https://git.ti.com/pru-software-support-package

Clone the above and look in the examples/am335x directory.
There is an example C file for IEP.
I've never run it myself, but seems to be what you are looking for. 
 Perhaps a good place to start.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7f6816f7-4a3d-4ad7-9daa-07e552fb9741%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU PID Motor Speed Controller Project at Github and Hackster.io

[Greg]

This project is based on a Texas Instruments demonstration project.
This project uses the RemoteProc and messaging framework to connect the 
PRUs to Linux user-space.
The PRU firmware code as published by TI was based on the "Mailboxes" which
was shortly thereafter changed to use the System interrupts.
A few minor changes were required to make the code compatible with the newer
RemoteProc system.

The project uses the PRUs to implement a "Proportional Integral Derivative" 
type DC motor speed controller.

In addition, a different Motor-encoder is recommended.  Minor tweaks were 
required
to the firmware code to match the specs of the different motor-encoder.

The Github repository:

https://github.com/Greg-R/pru-pid-motor

The main documentation file:

https://github.com/Greg-R/pru-pid-motor/blob/master/doc/PRUPIDMOTORlatex/pru-pid.pdf

The project at Hackster.io:

https://www.hackster.io/Greg-R/pru-pid-motor-speed-controller-with-beaglebone-green-ccb805?ref=user_id=131733=0

and a short introductory youtube video:

https://www.youtube.com/watch?v=wzNGHVjAqL8=youtu.be

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d1787723-577e-4157-9776-98f978d337df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

[Greg]

That's a good idea...I did that earlier this year when I understood the 
workings of the kernel much less.
I don't think I made any progress figuring out how user-space access gets 
exported to virtual file system at /sys.
Will do some grepping on the kernel sources and drill into the 
documentation and see what I can come up with.
There is some fantastic stuff at free-electrons.com, but it is much 
material!

I'm wrapping up some documentation, want to get it done, RemoteProc 
shutdown is a secondary issue so I will put it on the backburner until I 
have another look at the kernel.

On Wednesday, December 21, 2016 at 9:28:38 AM UTC-5, William Hermans wrote:
>
> Greg, have you read the remoteproc kernel documentation ? I did like a 
> year ago, and I do want to say there is a method to halt remoteproc. But 
> I'm not sure, and even if I did read that. There is no telling if it's 
> actually been implemented yet into our kernel / kernel modules . . .
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7bf54826-24ec-465b-a3d7-22dc5337ddff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Shutting Down PRUs via RemoteProc Framework from user-space?

[Greg]

Hi Jason-

I just tried it out with the PRU PID Motor controller example I have 
running here.
Regarding this command:

echo 1 > /sys/kernel/debug/remoteproc/remoteproc2/single_step

Does this halt the PRU1 core only?

I am looking for a complete shutdown of the PRU.  Go to sleep including 
peripherals.

I think what I am seeing is that the PRU core halts, but the PRU peripheral 
keeps going.
The PRU PID example uses the PWM on the PRU.
So even after issuing the above command, the PWM keeps on going!
However, I can tell the core is shut down because it no longer responds to 
commands to change the PID setpoint.
Then after echo 0 > single_step it starts responding to commands again. 
 But the PWM never shut down.

I can of course change the setpoint to zero before halting the core.
I guess what I am looking for is the cleanest method of putting the core to 
sleep and reducing power consumption.
Also I am thinking about how to to an emergency shutdown of a mechanical 
device.
I'm new to embedded systems design.  I think this is a reasonable 
requirement for the system?
Just not sure the best way to do this or status of current thinking in 
embedded systems design.

On Wednesday, December 21, 2016 at 10:04:25 AM UTC-5, Jason Reeder wrote:
>
> Greg,
>
> Suman added a simple debug interface for remoteproc at 
> '/sys/kernel/debug/remoteproc/'.
>
> On the BBB (AM335x) there are three devices available at that folder: 
> remoteproc0 (the wakeup M3 core), remoteproc1 (PRU0), and remoteproc2 
> (PRU1). You can verify which is which by the 'name' file in each folder:
> cat /sys/kernel/debug/remoteproc/remoteproc1/name
>
> You can dump some control registers (CTRL, Program Counter, etc.) while 
> the PRU is running by reading the 'regs' file:
> cat /sys/kernel/debug/remoteproc/remoteproc1/regs
>
> To halt a PRU, write a 1 to the single_step file. This will halt the PRU 
> and allow you to dump the full register set:
> echo 1 > /sys/kernel/debug/remoteproc/remoteproc1/single_step
> cat /sys/kernel/debug/remoteproc/remoteproc1/regs
>
> You can continue single stepping through code and dumping the registers by 
> repeating the two lines above.
>
> To run the PRU core again just write a 0 to the single_step file:
> echo 0 > /sys/kernel/debug/remoteproc/remoteproc1/single_step
>
> Jason Reeder
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c268678a-bc4b-4234-8634-aecd36687b62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

[Greg]

Hello, a quick question on operating PRUs via the RemoteProc framework on 
Beaglebone:

Is there a command via RemoteProc which will stop execution of firmwares 
running on the PRU(s)?

There are bind and unbind capability in sys:

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind
echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind
echo "4a338000.pru1"  > /sys/bus/platform/drivers/pru-rproc/unbind

The unbind appears to disconnect RPMsg (character devices gone), but it 
does not halt the PRU!

So after unbind, I am doing this:

sudo rmmod pru_rproc
sudo rmmod pruss

So after removing pruss the PRUs appear to halt.
So that is a total of 3 commands to halt a PRU.

So what I am looking for is a RemoteProc framework capability to halt the 
PRU(s) from user-space.
If there is none, I will use the rmmod commands as above.  I'm hoping I am 
missing a simpler method.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e12d6e11-3d19-469f-83bb-71f69922f125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Greg]

Great news, keep going!  Greg

On Saturday, December 17, 2016 at 11:16:25 AM UTC-5, Jay Doobie wrote:
>
> Ahhh! Ok, I had modified things so much last night I went back to the 
> original and forgot to update the uio pruss in the non-overlay version.  It 
> WORKS!
>
> When I was saying pinmux works, I guess I should have indicated that I was 
> trying to set 990, 99c, 994 to 0x15.  
>
> So it appears something in the *overlay version is preventing my pinmux 
> from being set the way I wanted it, but (for now) it works!
>
> Thank you so much everyone!
>
> /Jason
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/60f3b125-17dd-4d11-9055-14bbe7053141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Greg]

Not totally clear what you are saying.  I see you have the UIO PRUSS line 
uncommented in "PRU works".
It is not uncommented in "pinmux works".

So are you saying when you uncomment the UIO PRUSS line to activate it, it 
kills the pinmux?
Sorry for the confusion!

On Saturday, December 17, 2016 at 10:28:23 AM UTC-5, Jay Doobie wrote:
>
>
> I have modified the dts files from the dts-rebuilder and in one I can 
> access the PRU, and in the other I can get the pins set the way I want, but 
> sadly not at the same time.
>
> PRU works: 
> https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless-emmc-overlay.dts
>  
>  
> pinmux works: 
> https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless.dts
>
> If it is easier for me to post the decompiled DTS (so it is in a single 
> file) or DTB let me know,
>
> /Jay
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/afba2a33-dfc0-43b6-b83a-9768d261ef8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Link to Official WIKI Page broken?

[Greg]

>From this page:

http://beagleboard.org/latest-images

The link to the "official wiki page":

https://elinux.org/Beagleboard:Updating_The_Software

seems to never connect for me.  Anyone else see the same?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1b5f13eb-9867-4413-af7d-29b812141249%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Greg]

Hi Jay, you are correct it is difficult to work through all the issues and 
find the right sources of information.
I did attempt to document the current process for activating the PRU with 
Remoteproc:

https://github.com/Greg-R/pruadc1

More specifically look in the PDF file:

https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf

and go to the chapter 10 which has a list of the process for enabling the 
PRU with Remoteproc.
Setting up UIO PRUSS should be similar, uncomment a different line and 
blacklist the Remoteproc modules.
I hope I got this stuff correct, as it is a compilation of stuff I got from 
this group combined with my own experiments.

My general plan of attack so far is to use Universal IO and the config-pin 
utility if I can.
If you look at the discussions here, many many of them are asking how to 
work out issues with the Device Tree.
I try to not touch Device Tree stuff if I don't have to.

Of course, my latest project had to tweak the Device tree with an include 
file, and it worked.  I lucked out on that one!

I totally agree with William that you have to take notes and make sure you 
can find them a few months later.
It's easier said than done, but it's worth making the attempt.

On Saturday, December 17, 2016 at 8:40:30 AM UTC-5, Jay Doobie wrote:
>
> I certainly expect I screwed something up.  I've yet to see a website that 
> really does a good job describing how to get the pru enaled or setting a 
> main DT or overlay.  I was going to try to grab the source for my old main 
> DT and see if I am missing something. I have't been able to get either the 
> PRU or pinmux working again since last yesterday and I stayed up way too 
> late trying.  I'm going to give it an hour or two today then I need to get 
> going on other projects.
>
>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/34375990-c557-4f89-848a-132c03b8594e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU rpmsg issues with IOT 2016-11-06

[Greg]

You are very close!!!

One thing to try right away is to:

rmmod pru_rproc

and then 

modprobe pru_rproc

I don't think you are removing pru_rproc before re-probing it.
In my latest Debian image this works, and you don't need to do the bind in 
addition to this.
Of course the bind should work as well.

Now, based on the dates you show, you may be using the old Remoteproc 
framework which uses the mailboxes.
Look in your code for the PRUs and see if you see the numbers like 58 or 59.
The new system flags should be like 18 or 19.

If you have the old mailboxes you can convert your code easily enough.  In 
fact, it will probably be simplified.
Get the latest PRU Support package and look at the examples directory:

https://git.ti.com/pru-software-support-package

I'm pretty sure if you have the old mailboxes code you will get the 
behavior you are observing.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/90d8ff96-4172-4c96-89d5-f23f279d9c21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: pru + 4.4 kernel?

[Greg]

Jay, you have to do a minimal edit to the device tree and rebuild the blobs.
I'm pretty sure 4.4.x kernels will require this (not sure exactly when this 
was rolled out).

Clone this to your Beaglebone:

https://github.com/RobertCNelson/dtb-rebuilder

Look in the directory src/arm.
Find the file:

am335x-bonegreen.dts

or

am335x-boneblack.dts

In the file, you need to uncomment a line like:

/* #include "am33xx-pruss-uio.dtsi" */

Then you need to create a very simple file

/etc/modprobe.d/pruss-blacklist.conf

and include the following:

 blacklist pruss
 blacklist pruss_intc
 blacklist pru-rproc

You will find instructions for the above in the dts file.
Then

make
make install
reboot

Then see if it works!  Good luck.
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8f14c605-143d-4e3d-8d4f-4ab94337ae7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Loading PRU overlay causes BBB to lock

[Greg]

TJF, so what is the best way to update the dtc?

I've used this in the past:

https://github.com/RobertCNelson/bb.org-overlays

More specifically the script:

dtc-overlay.sh

However, I'm not sure this is the appropriate method in this case.
If not, what is?  An apt-get install ...?

Greg


On Wednesday, December 14, 2016 at 11:40:03 AM UTC-5, TJF wrote:
>
> Hi Damon!
>
> Kernel 3.8.13-bone79 is uio_pruss only (no remoteproc).
>
> Am Mittwoch, 14. Dezember 2016 04:37:47 UTC+1 schrieb Damon Kelly:
>>
>> -bash: /sbin/reboot: Input/output error
>>
>
> You executed the reboot command and the binary /sbin/reboot couldn't 
> access some hardware (perhaps a CPU ball). Obviously the device tree mixes 
> up some configurations.
>
> First, try to re-compile your device tree source. There were changes in 
> the device tree compiler around that version, so use the dtc version of 
> the new kernel! If this doesn't help, then post your source here.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0e5b164b-7cfe-4693-a39e-ac79232da228%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Loading PRU overlay causes BBB to lock

[Greg]

A couple of commands in a shell might help you get going:

lsmod

The above command will tell you which kernel modules are loaded.  If you 
are using PRU, you probably want to have one or more related modules.
Run this before you add the overlay.  Do you know if you are using the 
RemoteProc or UIO framework?

Also the command

dmesg

You probably want to use

dmesg | less

and with the above you can use the letter f (page forward) b (page 
backward) and q for quit, as this log file is quite long.

dmesg will show you the kernel log which will possibly help.  Assuming you 
can look at it at all after loading the overlay!

I'm not sure if the 3.8 version distributions require a change to the 
Device Tree to get a particular PRU framework.
The newest version 8 Debian definitely do.

You need to provide more details for sure.  What is it you were doing 
before which worked?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cdffbe3d-5dc0-4cbc-83bf-30b66317d491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU PID Motor Speed Controller Using RemoteProc and RPMsg

[Greg]

On Sunday, December 11, 2016 at 11:57:32 PM UTC-5, Jason Kridner wrote:
>
> Thanks for this! Care to post the same with some details on the steps and 
> code to Hackster.io?
>

Yes, I was already planning to upload the project to Hackster.io.
I've got a few hours of work to do on the documentation and cleaning up the 
repository.

Will post an update when I get it published.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d650cedc-2f37-41bb-a30c-5a1d6055fe51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU PID Motor Speed Controller Using RemoteProc and RPMsg

[Greg]

Here is a quick overview of this project at youtube:

https://youtu.be/wzNGHVjAqL8

This is based on the example project from Texas Instruments:

http://www.ti.com/tool/tidep0073

I have used the latest Debian version 8 Beaglebone Green IOT image.
There was a bit of hacking to convert to the System Interrupts from the 
older Mailbox implementation.
All hacking was done on the BBG using the clpru compiler.  I did not use 
IDE or crosscompiler to get this to work.

A very minor change to a Device Tree file was required.  Thanks to Robert 
Nelson's scripting, this process was trivial!

Also, I used a different DC motor-encoder I found on eBay.  It works 
perfectly with this project and is slightly cheaper than the recommended 
motor/encoder.

I will publish to Github with documentation soon.
I think the project is really cool, and the material provided by Texas 
Instruments is amazing and a huge help in showing how to use C programming 
with the PRU and Remoteproc/RPMsg!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b3398633-1252-47ca-a986-19230f33c68d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How is a default Device Tree Blob determined?

[Greg]

On Wednesday, December 7, 2016 at 9:33:22 PM UTC-5, RobertCNelson wrote:
>
> removing capes works in 1-5% of overlays... 
>
> from /boot/uEnv.txt remove the cape_universal=enable and it'll come up 
> with nothing on your next bootup.. 
>
> Regards, 
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

Got it...info much appreciated.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1998b28f-01cd-45ef-9cdf-7688d125e916%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How is a default Device Tree Blob determined?

[Greg]

On Monday, March 21, 2016 at 9:54:12 PM UTC-4, RobertCNelson wrote:
>
> We look at the eeprom: 
>
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=150c5235d230f597641bd8a8fbd8e4afa0fd16cd;hb=HEAD#l164
>  
>
> Regards, 
>
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

OK, so let's say I have a version 4.4.30-ti-r64 kernel, and I get this 
after boot:

 debian@BBG2:/sys/devices/platform/bone_capemgr$ 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-universal

According to this (I think),
https://github.com/beagleboard/bb.org-overlays

 I should be able to remove slot 4 by:
sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots" 

But that doesn't work, and there is all sorts of mayhem, including this 
from dmesg:

[ 251.257614] Unable to handle kernel NULL pointer dereference at virtual 
address 000d

So, the question is, what is the proper procedure for removing a universal 
overlay, and then putting in a different one?
The config-pin utility is capable of adding an overlay, but can it remove 
one???

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f1737ad3-ba39-43ff-9e82-4a09d4a58dbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PWM generation using libpruio

[Greg]

Are you using a recent Beagleboard image?  Beaglebone?

I haven't used libpruio, but I assume it uses the UIO kernel driver.
First, you will need to activate that driver.

This utility will help get it done:

https://github.com/RobertCNelson/dtb-rebuilder

You will need to clone the above to your board and make 2 very easy changes 
to text files.
Then you have to run the script in the above and re-boot.
Can perhaps guide you but need to know which kernel and which board you are 
using.
I didn't have to do anything to the Device tree for Remoteproc and PWM. 
 Hopefully the same
will be true for UIO.

Regarding the PWM, once again, have to assume you are using a recent Debian 
image.
The version 4 kernels require some steps to get the PWM exported.
I did this just a few days ago, and got it to work.  You need to look for:

/sys/class/pwm/pwmchip0

You need to export by something like:

echo 0 > export

Or it could be other numbers depending on which PWM.

I haven't found a concise reference for the above process, and how the 
export number maps to the particular PWM.
Perhaps someone else can point us to a good reference guide for this 
process.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e4f692e6-e939-46fc-8dc8-93fc4c6e828d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Greg]

Hi Jason, this is awesome, much appreciated!  Is it going to become part of 
the PRU Support Package examples?

I'll run through the process soon and report on the result.
I also have some questions on the interrupt examples for some time in the 
future.

Meanwhile, I assume you ran the demo on a recent Debian distribution on a 
Beaglebone.
I was wondering if you see this in the dmesg log.  This is for PRU0, and 
there is a repeated instance of these messages for PRU1.

It's not a big deal as the firmwares can be started reliably after boot.  I 
was not seeing this on the Beaglebones a few months ago, as the firmwares 
would be up and running automatically
after boot.  Just curious what is going on...

[4.705647] irq: no irq domain found for 
/ocp/pruss@4a30/intc@4a32 !
[4.742790] irq: no irq domain found for 
/ocp/pruss@4a30/intc@4a32 !
[4.836176]  remoteproc1: 4a334000.pru0 is available
[4.836201]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[4.836210]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[4.836500]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.836520]  remoteproc1: failed to load am335x-pru0-fw
[4.847402] pru-rproc 4a334000.pru0: booting the PRU core manually
[4.847433]  remoteproc1: powering up 4a334000.pru0
[4.847543]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.847559]  remoteproc1: request_firmware failed: -2
[4.852787] pru-rproc 4a334000.pru0: rproc_boot failed
[4.969567]  remoteproc1: releasing 4a334000.pru0
[4.969746] pru-rproc: probe of 4a334000.pru0 failed with error -2


On Monday, November 28, 2016 at 11:52:36 PM UTC-5, Jason Reeder wrote:
>
> Greg and Zach,
>
> Check out the two tarballs in this drive link: 
> https://drive.google.com/drive/folders/0B_OVOhSEksP8MDFiT0x6YU1EZG8?usp=sharing
>
>
>- PRU_Halt_Assembly.tar.gz
>- Contains a project to drop into 
>   /opt/source/pru-software-support-package/examples/am335x/ that is an 
>   assembly only projec
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4ca094f9-5c78-43bb-a9fd-f4050ce23a1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

[Greg]

I believe asmpru is the assembler code compiler which is part of the PRU 
compilation system which is described in the C/C++ Compiler manual.

pasm is the older assembler which existed prior to the C compiler.
There are differences in the assembly instructions used with pasm versus 
the more recent asmpru.

I believe clpru actually uses asmpru in the compilation process of C code.

Check out this discussion, especially the link to the pasm to clpru porting 
guide:

https://groups.google.com/forum/#!searchin/beagleboard/mark$20yoder$20pasm%7Csort:relevance/beagleboard/vuxsX_oMzkM/UjNIYWiKAQAJ

On Monday, November 28, 2016 at 4:49:46 PM UTC-5, Zach B wrote:
>
> Greg,
>
> Thanks for the info. That linker primer helped a bit with what is exactly 
> going on inside of the linker, at least to the level that I can understand. 
> I'm still working through getting a single assembly file to work but for 
> now I figured out a workaround with an empty c file. What is asmpru? I only 
> know about "clpru" and "pasm".
>
>
> Is it possible to load firmware into the PRU, start and stop it for 
> testing and then reload new software without having to reboot? Whenever I 
> stop the PRU and go to remove pru_rproc with "rmmod" or "modprobe -r" I get 
> a message that it is still in use. In order to get around that I just 
> restart the system after copying my new firmware file to /lib/firmware, but 
> is there another way around this? As far as I can tell the PRU is not 
> running when I try to unload/remove pru_rproc. Also when exactly is the pru 
> firmware loaded into the PRU, is it when the system boots or when "modprobe 
> pru_rproc" is called and the remoteproc is started?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b7258700-705e-4969-8e6e-ca7096dc36cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.