Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Andrew Harres]

That's very clever, but it looks like the file exists before it's usable by 
libpruio. I tried ConditionPathIsReadWrite, but the file is readwritable 
before it's usable by libpruio as well. I noticed that the file permissions 
and group changes which seems to correlate with libpruio being able to use 
the file. Unfortunately, I don't see anything in the systemd documentation 
about file owner or permission conditions in service files.

On Thursday, September 10, 2020 at 2:21:02 PM UTC-5 RobertCNelson wrote:

> On Thu, Sep 10, 2020 at 1:55 PM Andrew Harres  wrote:
> >
> > Hello again!
> >
> > I'm trying to solve a minor problem. I made a systemd service which 
> starts my program automatically. My problem is that my program is starting 
> too early which causes this error:
> >
> > AssertionError: pruio_new failed (b'cannot open /dev/uio5')
> >
> >
> > The program will exit and the systemd service will keep restarting the 
> program until eventually (less than a minute) the program will run 
> successfully.
> >
> > Here is my systemd service file:
> >
> > [Unit]
> > After=generic-board-startup.service libpruio-lkm.service
> > StartLimitIntervalSec=0
> >
> > [Service]
> > Type=simple
> > Restart=always
> > User=debian
> > WorkingDirectory=/opt/rad/virtual_sensor
> > ExecStart=/opt/rad/virtual_sensor/virtual_sensor
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > I realize that since the libpruio-lkm service doesn't exit, putting it 
> in the 'after' section doesn't really make sense. Surely someone has dealt 
> with this problem before, but I couldn't find it while searching.
>
> Add this option to your service:
>
> ConditionPathExists=/dev/uio5
>
> Wish systemd had a wait for module option..
>
> 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/78f4859b-e23e-4f82-8172-622034ffb23bn%40googlegroups.com.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Sep 10, 2020 at 1:55 PM Andrew Harres  wrote:
>
> Hello again!
>
> I'm trying to solve a minor problem. I made a systemd service which starts my 
> program automatically. My problem is that my program is starting too early 
> which causes this error:
>
> AssertionError: pruio_new failed (b'cannot open /dev/uio5')
>
>
> The program will exit and the systemd service will keep restarting the 
> program until eventually (less than a minute) the program will run 
> successfully.
>
> Here is my systemd service file:
>
> [Unit]
> After=generic-board-startup.service libpruio-lkm.service
> StartLimitIntervalSec=0
>
> [Service]
> Type=simple
> Restart=always
> User=debian
> WorkingDirectory=/opt/rad/virtual_sensor
> ExecStart=/opt/rad/virtual_sensor/virtual_sensor
>
> [Install]
> WantedBy=multi-user.target
>
> I realize that since the libpruio-lkm service doesn't exit, putting it in the 
> 'after' section doesn't really make sense. Surely someone has dealt with this 
> problem before, but I couldn't find it while searching.

Add this option to your service:

ConditionPathExists=/dev/uio5

Wish systemd had a wait for module option..

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/CAOCHtYhZwZUwgeuonNrCCJnzkWYa62Eb%3DxoF0nfMtMBYzPjiBA%40mail.gmail.com.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Donnerstag, 13. August 2020 18:16:55 UTC+2 schrieb Andrew Harres:
>
> debian@beaglebone:~$ groups
> debian adm kmem dialout cdrom floppy audio dip video plugdev users 
> systemd-journal input bluetooth netdev cloud9ide xenomai weston-launch 
> tisdk docker i2c iio spi admin remoteproc eqep pwm gpio
>

The system group pruio is missing. It gets created when installing the 
libpruio-lkm.deb packege.

debian@beaglebone:~$ sudo chown root:gpio 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ sudo chmod 664 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ sudo ls -l 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> -rw-rw-r-- 1 root gpio 0 Jan  1  1970 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ cat 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> cat: /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins: Permission 
> denied
>

Obviously also the folder needs permissions. Here's the folder chain on my 
system

dr-xr-xr-x  12 root root 0 Aug 13 19:40 sys
> rwxr-xr-x   10 root root 0 Aug 13 19:40 kernel
> drwx--x--x  41 root root 0 Jan  1  1970 debug
> drwxrwxr-x   2 root gpio 0 Jan  1  1970 44e10800.pinmux
>
 
Regarding ADC the example 1.py works now in python 2 and 3:

debian@beaglebone:~$ sudo python3 src/pruio_examples/1.py
> F940 EBD0 F4A0 88C0 58A0 9EB0 B6C0 F1E0
> F960 EE70 F510 C170 9600 91A0 9990 F200
> F950 EE10 F530 C630 A400 A0A0 A1D0 F1E0
> F970 EE30 F510 C680 A640 A470 A680 F1F0
> F990 EE10 F4E0 C680 A6B0 A5C0 A910 F200
> F990 EE30 F500 C660 A6B0 A630 AA10 F1E0
> F980 EE00 F4F0 C680 A660 A5D0 A980 F1C0
> F980 ED90 F4E0 C640 A590 A520 A8D0 F1D0
> F950 ED90 F510 C5F0 A520 A470 A7B0 F1B0
> F940 EDC0 F500 C5C0 A4F0 A420 A6B0 F1D0
> F960 EDA0 F4D0 C5C0 A4B0 A3B0 A630 F210
> F940 EDC0 F500 C5B0 A450 A370 A5C0 F1C0
> F940 EDF0 F4F0 C5D0 A4E0 A3C0 A5F0 F1B0
>

But you don't have pinmuxing feature yet.

   1. Try to install libpruio-lkm.deb package (command groups should list 
   the system group pruio afterwards).
   2. Make yourself a member in this group.
   3. Fix the permissions in path 
   /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins.
   4. Make uEnv.txt *NOT* loading the cape_universal stuff.
   
Then the AssertionError: pruio_new failed ('parsing kernel claims') should 
disappear and all members of group pruio should have pinmuxing capability 
from user space.

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/5dad1c89-3390-40cf-8bc9-00a728afde8bo%40googlegroups.com.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Andrew Harres]

debian@beaglebone:~$ uname -r
4.14.108-ti-r136

debian@beaglebone:~$ groups
debian adm kmem dialout cdrom floppy audio dip video plugdev users 
systemd-journal input bluetooth netdev cloud9ide xenomai weston-launch 
tisdk docker i2c iio spi admin remoteproc eqep pwm gpio

debian@beaglebone:~$ sudo chown root:gpio 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

debian@beaglebone:~$ sudo chmod 664 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

debian@beaglebone:~$ sudo ls -l 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
-rw-rw-r-- 1 root gpio 0 Jan  1  1970 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

debian@beaglebone:~$ cat 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
cat: /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins: Permission 
denied

debian@beaglebone:~$ python3 src/pruio_examples/1.py
Traceback (most recent call last):
  File "src/pruio_examples/1.py", line 25, in 
if IO.Errr: raise AssertionError("pruio_new failed (%s)" % IO.Errr)
AssertionError: pruio_new failed (b'parsing kernel claims')


I'm back on the 4.14 kernel to get closer to what you have. I modified the 
pinmux-pins permissions to be just like yours. I'm already in the gpio 
group. What do your permissions look like for the whole directory structure 
leading up to pinmux-pins?

The 2to3 procedure worked perfectly for me as well: 

debian@beaglebone:~$ python3 src/pruio_examples/1.py
Traceback (most recent call last):
  File "src/pruio_examples/1.py", line 25, in 
if IO.Errr: raise AssertionError("pruio_new failed (%s)" % IO.Errr)
AssertionError: pruio_new failed (b'parsing kernel claims')

debian@beaglebone:~$ sudo python3 src/pruio_examples/1.py
F940 EBD0 F4A0 88C0 58A0 9EB0 B6C0 F1E0
F960 EE70 F510 C170 9600 91A0 9990 F200
F950 EE10 F530 C630 A400 A0A0 A1D0 F1E0
F970 EE30 F510 C680 A640 A470 A680 F1F0
F990 EE10 F4E0 C680 A6B0 A5C0 A910 F200
F990 EE30 F500 C660 A6B0 A630 AA10 F1E0
F980 EE00 F4F0 C680 A660 A5D0 A980 F1C0
F980 ED90 F4E0 C640 A590 A520 A8D0 F1D0
F950 ED90 F510 C5F0 A520 A470 A7B0 F1B0
F940 EDC0 F500 C5C0 A4F0 A420 A6B0 F1D0
F960 EDA0 F4D0 C5C0 A4B0 A3B0 A630 F210
F940 EDC0 F500 C5B0 A450 A370 A5C0 F1C0
F940 EDF0 F4F0 C5D0 A4E0 A3C0 A5F0 F1B0

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/e80e6e61-263e-4a8d-904d-439b0263c510n%40googlegroups.com.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[jonnymo]

You could try adding the following to your Python 2 script to add Python 3
print  support.
"from __future__ import print_function"

However, there should be an effort to move from Python 2 to Python 3.

Cheers,

Jon

On Thu, Aug 13, 2020 at 6:47 AM Dennis Lee Bieber 
wrote:

> On Wed, 12 Aug 2020 16:00:14 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user TJF
>  wrote:
>
> >I forgot to mention that the modified file doesn't work in python2 any
> more:
> >
> >src/test$ python 1.py
> >>   File "1.py", line 32
> >> print("%4X" % AdcV[i], end=" ") #output one channel in hex
> >>   ^
> >> SyntaxError: invalid syntax
> >>
> >>
> Without looking at the original source, I predict you were using
>
> print "%4X" % AdcV[i] ,
>
> where the trailing comma suppressed the automatic new-line of "print" and
> just left a trailing space. Try replacing that line with
>
> sys.stdout.write("%4X " % AdcV[i])
>
> I've moved the space separator into the "..." format string.
>
> .write() doesn't add line terminators, they are all up to the
> coder to
> put in.
>
> Personally -- I'd probably replace all the "print" calls with
> equivalent sys.stdout.write() (inserting the proper line ending \n where
> needed). For "deliverable" packages I tend to save "print" for
> development/debug tracing information -- one can easily identify what is to
> be removed when delivering the package.
>
>
> --
> Dennis L Bieber
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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/6jgajf1aiseb5bc3e4h5ukmf5h367fl8ta%404ax.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/CAG99bkrkJ3WAoifNR0bo8S%3DQP8nMTHafJujjndqxvMng-0_JGA%40mail.gmail.com.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Hi CM!

Am Montag, 1. April 2019 19:39:48 UTC+2 schrieb CM:
>
> TJF,
>
> Thank you for your help, especially because it turned out to be more of a 
> systemd issue than libpruio! I have now changed my service so that it 
> doesn't start until later in the boot process, and everything seems to be 
> functioning correctly.
>

You're welcome! At the end it was both, a systemd and a libpruio issue. A 
race condition between kernel driver loading and constructor call with 
admin privileges. Because it's a common use case, I made an entry in the Tips 
and Tricks 

 
section.

Thanks for your feedback!

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/f7b2a24b-157e-4ec8-ac02-4b3af81dfa81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

TJF,

Thank you for your help, especially because it turned out to be more of a 
systemd issue than libpruio! I have now changed my service so that it 
doesn't start until later in the boot process, and everything seems to be 
functioning correctly.

My initial mistake was making multiple changes at the same time: the number 
of samples in my libpruio program and editing my systemd services. Because 
of that, I was looking at the wrong potential cause of the problem.

Thanks, again.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/ccbc7427-5386-445c-bfde-950c10a43baa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Freitag, 29. März 2019 21:18:58 UTC+1 schrieb CM:
>
> Your suggested steps did work to connect uio5, thanks! It reverts to the 
> disconnected state on reboot, however.
>

Good! 

>
> I do have several services running, including for the IMU and the analog 
> in (using libpruio). So my service isn't explicitly changing uio5, but 
> maybe it invokes it too early in the boot process.
>

Sure, your service must not start before the driver is loaded. Here is an 
example how I start one of my projects

File /etc/systemd/system/solar.service
[Unit]
Description=Start controller (/etc/default/solar-regler.sh)

[Service]
Type=oneshot
ExecStart=/etc/default/solar-regler.sh
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

File /etc/default/solar-regler.sh (the program to start is called 
solar-regler)
#!/bin/sh -e
# load PRU kernel driver and start contoller (Jessie)

uio=/dev/uio5

# wait until kernel driver created the socket nodes
until test -e ${uio}; do sleep 1; done

# start controller
/usr/local/bin/solar-regler &

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/1763291d-3475-4741-9fb0-cfb4ef1dd270%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Hello,

Your suggested steps did work to connect uio5, thanks! It reverts to the 
disconnected state on reboot, however.

I do have several services running, including for the IMU and the analog in 
(using libpruio). So my service isn't explicitly changing uio5, but maybe 
it invokes it too early in the boot process.

When I disable the service that uses libpruio, I am able to manually run my 
code, and the example code (e.g 1, io_input).

Thank you for your help. I just have to figure out what about my service is 
causing this issue.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/6c21eb95-0ad7-4d7a-a157-153e0c5ae5e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

I don't understand why uio5 doesn't change. The main issue is it's lenght 
of 0 bytes (others are 240). The device seems to be disconnected from the 
driver, and the driver loader cannot change the file.

Sorry, you don't have a libpruio issue. You have a problem with LINUX 
driver loading. And I have no Blue to test here, so I cannot really help.

I'd try to erase the file before reloading the driver

lsmod | grep uio*
sudo rmmod uio_pruss
lsmod | grep uio*
ls -l /dev/uio*
sudo rm -f /dev/uio5
ls -l /dev/uio*
sudo modprobe uio_pruss
lsmod | grep uio*
ls -l /dev/uio*

Regards

PS: Check your systemd services if anyone is changing the file /dev/uio5.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/1004761c-eb0b-46e2-a752-9b65e6b029db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Yes, I think I should probably take a deep breath, thanks!

So my system image was initially written in November, I guess, which is why 
that date is shown. It updates after being on a bit (via GPS).
Now it shows *all* /dev/uio* as Nov 3, until removing/reinstalling 
uio_pruss. Please see the output below:

debian@beaglebone:~$ ls -l /dev/uio*
crw-rw 1 root users 240, 0 Nov  3  2016 /dev/uio0
crw-rw 1 root users 240, 1 Nov  3  2016 /dev/uio1
crw-rw 1 root users 240, 2 Nov  3  2016 /dev/uio2
crw-rw 1 root users 240, 3 Nov  3  2016 /dev/uio3
crw-rw 1 root users 240, 4 Nov  3  2016 /dev/uio4
-rw-r--r-- 1 root root   0 Nov  3  2016 /dev/uio5
crw-rw 1 root users 240, 6 Nov  3  2016 /dev/uio6
crw-rw 1 root users 240, 7 Nov  3  2016 /dev/uio7
debian@beaglebone:~$ sudo rmmod uio_pruss
debian@beaglebone:~$ sudo modprobe uio_pruss
debian@beaglebone:~$ ls -l /dev/uio*
crw-rw 1 root users 240, 0 Mar 29 12:46 /dev/uio0
crw-rw 1 root users 240, 1 Mar 29 12:46 /dev/uio1
crw-rw 1 root users 240, 2 Mar 29 12:46 /dev/uio2
crw-rw 1 root users 240, 3 Mar 29 12:46 /dev/uio3
crw-rw 1 root users 240, 4 Mar 29 12:46 /dev/uio4
-rw-r--r-- 1 root root   0 Nov  3  2016 /dev/uio5
crw-rw 1 root users 240, 6 Mar 29 12:46 /dev/uio6
crw-rw 1 root users 240, 7 Mar 29 12:46 /dev/uio7
debian@beaglebone:~$ dmesg | grep uio
debian@beaglebone:~$

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Slow down, take a deep breath! I try to understand your system.

The first question is why is uio5 different than the others. By default 
since kernel 4.14 all devices are owned by root users. Why do you get root 
root for uio5? Why are all dates 2016 Nov., while uio5 is from today?

Please reload the driver and post the output from

sudo rmmod uio_pruss
sudo modprobe uio_pruss
ls -l /dev/uio*
dmesg | grep uio

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/195ee434-c85d-4509-beef-497bf820f2ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

>
> Please post the full output of ls -l /dev/uio*
>
> Do you (your user ID) have write access to that files?
>

debian@beaglebone:~/analog$ ls -l /dev/uio*
crw-rw 1 root users 240, 0 Nov  3  2016 /dev/uio0
crw-rw 1 root users 240, 1 Nov  3  2016 /dev/uio1
crw-rw 1 root users 240, 2 Nov  3  2016 /dev/uio2
crw-rw 1 root users 240, 3 Nov  3  2016 /dev/uio3
crw-rw 1 root users 240, 4 Nov  3  2016 /dev/uio4
-rw-r--r-- 1 root root   0 Mar 29 08:30 /dev/uio5
crw-rw 1 root users 240, 6 Nov  3  2016 /dev/uio6
crw-rw 1 root users 240, 7 Nov  3  2016 /dev/uio7

When I add write access to /dev/uio5, and run my code (or example 1), I get 
a Bus error.

/dev/uio5 is listed in white, which means the system doesn't recognize it 
as a device, correct? 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/ad923f31-7fcd-4888-a50c-2669bd356684%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Donnerstag, 28. März 2019 16:58:08 UTC+1 schrieb CM:
>
> When I check the PRU availability, i.e. ls /dev/uio8, it shows uio0-7. All 
> are yellow but uio5.
>

Please post the full output of ls -l /dev/uio*

Do you (your user ID) have write access to that files?

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/d13d7ab4-c0ee-460f-bd51-a96599fb5880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Ok, I already have just AM335X-PRU-UIO-00A0.dtbo enabled.

So, if it's safe to say the issue is not with librobotcontrol, that brings 
me back to the initial problem.

I cannot run rb_file (or the code I wrote as a modification of it) - 
getting "constructor failed (cannot open /dev/uio5)"
When I run the example 1 - I get a seg fault.

Any thoughts?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/c0a0e7ba-2123-4393-afbe-6a845a3b7493%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Mar 28, 2019 at 10:58 AM CM  wrote:
>>
>> You should be fine then, just disable remoteproc_pruss and use
>> uio_pruss and ignore any of the librobotcontrol pru warnings..
>
>
> Forgive me if I'm oblivious, what are the steps I take to disable 
> remoteproc_pruss and use uio_pruss?
>
> Do you mean to comment out the PRU-RPROC dtbo files in uEnv.txt, blacklist 
> them in /etc/modprobe.d, or something else entirely?
>
> lsmod shows uio, uio_pdrv_genirq, and uio_pruss already loaded.
>
> When I check the PRU availability, i.e. ls /dev/uio8, it shows uio0-7. All 
> are yellow but uio5.

in /boot/uEnv.txt

only have this one uboot_overlay_pru define enabled:

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

>
> You should be fine then, just disable remoteproc_pruss and use 
> uio_pruss and ignore any of the librobotcontrol pru warnings.. 
>

Forgive me if I'm oblivious, what are the steps I take to disable 
remoteproc_pruss and use uio_pruss?

Do you mean to comment out the PRU-RPROC dtbo files in uEnv.txt, blacklist 
them in /etc/modprobe.d, or something else entirely?

lsmod shows uio, uio_pdrv_genirq, and uio_pruss already loaded.

When I check the PRU availability, i.e. ls /dev/uio8, it shows uio0-7. All 
are yellow but uio5.

Thank you,
CM

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/ff7a8b84-ae0e-4b59-9070-87152e4daf3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Mar 28, 2019 at 10:14 AM CM  wrote:
>
> Hello Robert,
>
> I am using a colleague's code to read the BeagleBone Blue's IMU/barometer. He 
> is using some of librobotcontrol in that. To be honest, I don't know 
> specifically what of librobotcontrol his code is using.
>
> To my understanding, it includes
>
> rc/math/kalman.h, filter.h, and quaternion.h
> rc/time.h, bmp.h, and mpu.h
>
> I am reading through the librobotcontrol source, but it doesn't look like any 
> of these use the PRU.

You should be fine then, just disable remoteproc_pruss and use
uio_pruss and ignore any of the librobotcontrol pru warnings..

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Hello Robert,

I am using a colleague's code to read the BeagleBone Blue's IMU/barometer. 
He is using some of librobotcontrol in that. To be honest, I don't know 
specifically what of librobotcontrol his code is using.

To my understanding, it includes 

   - rc/math/kalman.h, filter.h, and quaternion.h 
   - rc/time.h, bmp.h, and mpu.h


I am reading through the librobotcontrol source, but it doesn't look like 
any of these use the PRU.

I appreciate your insight into this.


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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Mar 28, 2019 at 9:04 AM CM  wrote:
>
> Thank you for the help regarding the driver conflict. I feared that might be 
> the case. I will have to look into running librobotcontrol with uio_pruss, as 
> you suggested.
>
> I also hope that Robert has some insight into my problem.
>
> Also, thank you for your efforts on libpruio. The times I am able to use it, 
> it works well!

librobotcontrol "pru" function calls are tied to remoteproc_pruss (v4.14.x-ti)

What features of librobotcontrol are you using?

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Thank you for the help regarding the driver conflict. I feared that might 
be the case. I will have to look into running librobotcontrol with 
uio_pruss, as you suggested. 

I also hope that Robert has some insight into my problem.

Also, thank you for your efforts on libpruio. The times I am able to use 
it, it works well!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/3e42d1ae-e36d-4f1b-bf00-27ae13bc2bc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Mittwoch, 27. März 2019 20:44:54 UTC+1 schrieb CM:
>
> I have read enough of this board to know that question was coming, so I 
> posted the output of /opt/scripts/tools/version.sh in my initial post. Here 
> it is in case it wasn't clear:
>

Hopefully Robert finds any hint here ...
 

> W1-BLUE is a custom dtbo for 1 wire.
> libpruio dtbo is probably not actually referencing anything (I think I put 
> it there as a misstep toward troubleshooting this issue)
>
> Another thought I had is that perhaps there is a conflict with 
> librobotcontrol using the PRU when librpuio wants to.
>

I don't know librobotcontrol, but in a first glance it looks like it's 
using the rproc driver. It's impossible to use both, rproc and uio_pruss 
driver at the same time. libpruio seems to work well on your system, but 
it's the LINUX driver loading that fails. Sorry, I cannot help. For 
libpruio you'll need a proper uio_pruss driver loading (rproc isn't fast 
enough). Check the output of ls -l /dev/uio* , that should list eight 
entries in case of success. Ask in a librobotcontrol forum if it's possible 
to run that library with uio_pruss driver loaded.

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/30519131-1310-4702-bbc3-637e42331d2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

>
>
> Follow Roberts instruction in this post 
> , 
> in order to provide the necessary debugging informations.
>
> I have read enough of this board to know that question was coming, so I 
posted the output of /opt/scripts/tools/version.sh in my initial post. Here 
it is in case it wasn't clear:

debian@beaglebone:/boot$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[24f2e3495113a63c2dcc2c0bdc0d7660b54e4e8f]
eeprom:[A335BNLTBLA21722EL002623]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.19.28-bone28]
nodejs:[v6.16.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-W1-BLUE-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/libpruio-0A00.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190123.0-0rcnee0~stretch+20190123]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep remote
[0.992529] remoteproc remoteproc0: wkup_m3 is available
[1.091092] remoteproc remoteproc0: powering up wkup_m3
[1.091113] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[1.095377] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru


W1-BLUE is a custom dtbo for 1 wire.
libpruio dtbo is probably not actually referencing anything (I think I put 
it there as a misstep toward troubleshooting this issue)

Another thought I had is that perhaps there is a conflict with 
librobotcontrol using the PRU when librpuio wants to.

Thank you for your help!

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Mittwoch, 27. März 2019 16:56:48 UTC+1 schrieb CM:
>
> When I run as root I get a bus error, otherwise the error message is:
>
> constructor failed (cannot open /dev/uio5)
>

This is a LINUX issue. The kernel driver uio_pruss doesn't load properly. 
Perhaps it gets listed by lsmod, but it didn't create the interrupt devices 
/dev/uio[0-7]. (From user space there is no file /dev/uio5, so opening 
fails. As root it creates such a device, but without any function. -> Don't 
use root privileges for development!)

Follow Roberts instruction in this post 
, in 
order to provide the necessary debugging informations.

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/47b0b7a4-0b8b-445c-8837-dca5120f5503%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

>
>
> Are you using error checks (as in the examples)? You didn't change the 
> extram_pool_sz, so you should get the message "out of memory" for sample 
> amounts (= Adc->ChAz x Adc->Samp) greater than 128 kSamples (= default 
> extram_pool_sz).
>

Yes, I am still using the error checks per the examples. When I run as root 
I get a bus error, otherwise the error message is:

constructor failed (cannot open /dev/uio5)

Maybe the number of samples is a secondary issue, because I cannot even run 
any of the examples, e.g. 1 returns a segmentation fault.
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/a7217ac6-9e60-403c-88a2-1093914ba6af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Mittwoch, 27. März 2019 15:25:39 UTC+1 schrieb CM:
>
> I have tried a few implementations, with the number of samples: 30,000 --> 
> 300,000 --> 600,000. I had no issues with 30,000 or 300,000, as far as I 
> can tell.
>

> I haven't made any changes to extram_pool_sz, and don't actually know 
> where the default for this is set. If you could please tell me where that 
> is, I can answer that question.
>

Are you using error checks (as in the examples)? You didn't change the 
extram_pool_sz, so you should get the message "out of memory" for sample 
amounts (= Adc->ChAz x Adc->Samp) greater than 128 kSamples (= default 
extram_pool_sz).

You can check the current size of the external memory block in variable 
PruIo->ESize. A guide for manipulation is in the docs at

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaMemory.html#SecERam

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/773cc2a9-33f8-47fc-965f-8e72156c1735%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Wed, Mar 27, 2019 at 9:25 AM CM  wrote:
>
> Hello,
>
> I have tried a few implementations, with the number of samples: 30,000 --> 
> 300,000 --> 600,000. I had no issues with 30,000 or 300,000, as far as I can 
> tell.
>
> I haven't made any changes to extram_pool_sz, and don't actually know where 
> the default for this is set. If you could please tell me where that is, I can 
> answer that question.
>
> I also wondered if I should change my uEnv.txt reference from 
> AM335X-PRU-UIO-00A0.dtbo to AM335X-PRU-UIO-4-19-00A0.dtbo, but it was running 
> on the 4.19 kernel previously without issue.

don't use AM335X-PRU-UIO-4-19-00A0.dtbo, it was only used for testing briefly

https://github.com/beagleboard/bb.org-overlays/commit/35dddbc4bec1a61beddfd199601a784745124d3b

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

Hello,

I have tried a few implementations, with the number of samples: 30,000 --> 
300,000 --> 600,000. I had no issues with 30,000 or 300,000, as far as I 
can tell.

I haven't made any changes to extram_pool_sz, and don't actually know where 
the default for this is set. If you could please tell me where that is, I 
can answer that question.

I also wondered if I should change my uEnv.txt reference from 
AM335X-PRU-UIO-00A0.dtbo to AM335X-PRU-UIO-4-19-00A0.dtbo, but it was 
running on the 4.19 kernel previously without issue.

Thanks!

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Hi CM!

Am Dienstag, 26. März 2019 22:07:43 UTC+1 schrieb CM:
>
> ..., and I increased the amount of samples my rb_file code is recording.
>

How big is your amount of samples? What's the extram_pool_sz in the 
uio_pruss driver setting?

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/890c409e-8a2a-47e9-9d59-a58099baa1cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[CM]

I have encountered some issues with analog input and libpruio. Last week, I 
had a working version of some code that is a modification of rb_file.

When I run it (or any of the examples) now, I get a Bus error. I am not 
sure what I did to cause this. 

I changed some systemd services that I have calling my code, and I 
increased the amount of samples my rb_file code is recording. 

It doesn't seem like either of these should have affected libpruio.



debian@beaglebone:/boot$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[24f2e3495113a63c2dcc2c0bdc0d7660b54e4e8f]
eeprom:[A335BNLTBLA21722EL002623]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.19.28-bone28]
nodejs:[v6.16.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-I2C1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-W1-BLUE-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/libpruio-0A00.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190123.0-0rcnee0~stretch+20190123]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190107.0-0rcnee0~stretch+20190108]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep remote
[0.992529] remoteproc remoteproc0: wkup_m3 is available
[1.091092] remoteproc remoteproc0: powering up wkup_m3
[1.091113] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[1.095377] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[not me]

Scratch that, the problem occurs repetively.
After a random while the network over USB disappears and connecting to the
wifi does not let me reconnect to the cloud9 ide.
I got the startup error again, but the problems occurs even if the error
isn't there.

Message from syslogd@beaglebone at Mar 21 18:33:07 ...
 kernel:[  412.210610] Internal error: : 1008 [#1] PREEMPT THUMB2

 kernel:[  412.326905] Process irq/118-wl18xx (pid: 1474, stack limit =
0xdc57a210)

 kernel:[  412.333632] Stack: (0xdc57bce0 to 0xdc57c000)

 kernel:[  412.338012] bce0: c100cb70 c1004088  1800 c011eea1
c011eea1 db53b22c c011dbb7

 kernel:[  412.346227] bd00: c100a758  c110c6bc 23d5fe02 
c100cb70  c110c6bc

 kernel:[  412.354440] bd20: 1800 c011ddb9 c1004088 c011e12d c100cb70
c100cb70 000c0013 dc28a400

 kernel:[  412.362653] bd40:  c011e133 dc28a880 0001 
c011ee6f dc286010 

 kernel:[  412.370867] bd60:  c011eeb1  dc286010 
c05f46f5 dc569a00 dc286010

 kernel:[  412.379082] bd80: e000 00208040  c011eea1 c1004088
db53b22c  c05f47ef

 kernel:[  412.387296] bda0: dc286010 c101dc80 dc246010 c05f42a1 dc57bdb0
dc57bdb0  dc57bdbc

 kernel:[  412.395531] bdc0: dc57bdbc 23d5fe02 dc57be0c dc286010 0004
400c0013 0002 dc57a000

 kernel:[  412.403743] bde0: c1004088 c05f4581 400c0013 db53b000 0001
c07174db db53b22c e000

 kernel:[  412.411959] be00:  dc569a00 c0147bb9 0100 0200
23d5fe02  db5cbc00

 kernel:[  412.420172] be20: c1004088 0001fffc db218c10 0004 daf1e840
 bf92f171 bf92f1a3

 kernel:[  412.428387] be40: dad87088 c013b5d3 2000  c1004088
23d5fe02 dad86d00 c1004088

 kernel:[  412.436602] be60: c101dc80  6d90 bf99b680 0001
bf9860d3  

 kernel:[  412.444816] be80:  dc57be84 dc57be84 23d5fe02 c1017a90
dad86d00 dad86d38 dad86ec8

 kernel:[  412.453031] bea0: 1c80 c1004088 c0165a39 dc518e58 dad86d00
bf97b761  c0146683

 kernel:[  412.461245] bec0: dc57bed8 c0146683 0002 bf99b680 02213071
0001 db42b400 23d5fe02

 kernel:[  412.469459] bee0: c1017a90 c1004088 dad86ec8 c1004088 
c013b6ad 400c0013 dc57bf08

 kernel:[  412.477673] bf00: c0165a39 23d5fe02 c094366b dad86d00 dad86d38
dad86ec8 1c80 c1004088

 kernel:[  412.485888] bf20: c0165a39 dc518e58 dc11bdf8 bf97becf bf97bdfd
dc5183c0 daa1d600 daa1d600

 kernel:[  412.494102] bf40: c0165911 c0165925 dc5183c0 dc57a000 daa1d600
c0165b17  

 kernel:[  412.502318] bf60: c0165999 23d5fe02 c0165a39 dc518e40 
dc518980 dc57a000 dc5183c0

 kernel:[  412.510533] bf80: c0165a39 c013fe1f dc57a000 dc518980 c013fd45
  

 kernel:[  412.518746] bfa0:    c0106a59 
  

 kernel:[  412.526960] bfc0:     
  

 kernel:[  412.535174] bfe0:     0013
  

 kernel:[  412.697028] Code: 6d6a fa12 f383 d1ec (681b) 07da


Any idea why this would happen?

Le ven. 22 mars 2019 à 12:01, not me <78b...@gmail.com> a écrit :

> Hi Robert,
>
> That fixed the problem and the examples work fine now.
> I did get errors on the first two reboots: The connection to my computer
> was randomly cut on both reboots (the network over USB and the beaglebone
> wifi became unavailable) and additionally, on the second reboot, I got this
> error on startup:
> Internal error: : 1028 [#1] PREEMPT THUMB2
>
> It's been working fine since, so far I haven't seen these errors again.
>
> Thank you very much for your help,
>
> Have a great day,
>
> Regards,
> Baptiste
>
> Le jeu. 21 mars 2019 à 20:38, Robert Nelson  a
> écrit :
>
>> On Thu, Mar 21, 2019 at 2:25 PM <78b...@gmail.com> wrote:
>> >>
>> >> Hi Robert, thanks for your quick answer,
>> >
>> >
>> >  In the meantime I went for a clean slate, flashed the latest IoT image
>> from beaglebone.org and changed the kernel to 4.14.103-bone17
>> >
>> >
>> > here is the output you asked:
>> >
>> >
>> > root@beaglebone:/var/lib/cloud9/examplesPRUIO/examples#
>> /opt/scripts/tools/version.sh
>> > git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
>> > eeprom:[A335BNLTBWA51712EW001857]
>> > model:[TI_AM335x_BeagleBone_Black_Wireless]
>> > dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
>> 2017.01-6-g55e748eda0]:[location: dd MBR]
>>
>> Okay, the old version of u-boot in the eMMC is blocking the u-boot
>> overlay loading..
>>
>> Run this and reboot..
>>
>> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>>
>> The uio node should now properly show up..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> For more options, visit 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[not me]

Hi Robert,

That fixed the problem and the examples work fine now.
I did get errors on the first two reboots: The connection to my computer
was randomly cut on both reboots (the network over USB and the beaglebone
wifi became unavailable) and additionally, on the second reboot, I got this
error on startup:
Internal error: : 1028 [#1] PREEMPT THUMB2

It's been working fine since, so far I haven't seen these errors again.

Thank you very much for your help,

Have a great day,

Regards,
Baptiste

Le jeu. 21 mars 2019 à 20:38, Robert Nelson  a
écrit :

> On Thu, Mar 21, 2019 at 2:25 PM <78b...@gmail.com> wrote:
> >>
> >> Hi Robert, thanks for your quick answer,
> >
> >
> >  In the meantime I went for a clean slate, flashed the latest IoT image
> from beaglebone.org and changed the kernel to 4.14.103-bone17
> >
> >
> > here is the output you asked:
> >
> >
> > root@beaglebone:/var/lib/cloud9/examplesPRUIO/examples#
> /opt/scripts/tools/version.sh
> > git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
> > eeprom:[A335BNLTBWA51712EW001857]
> > model:[TI_AM335x_BeagleBone_Black_Wireless]
> > dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2017.01-6-g55e748eda0]:[location: dd MBR]
>
> Okay, the old version of u-boot in the eMMC is blocking the u-boot
> overlay loading..
>
> Run this and reboot..
>
> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>
> The uio node should now properly show up..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/CN5qKSmPIbc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgYEDeQEHTZR4BcTE6XwKXSEy89hXpfWJeV46Rt77058g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Mar 21, 2019 at 2:25 PM <78b...@gmail.com> wrote:
>>
>> Hi Robert, thanks for your quick answer,
>
>
>  In the meantime I went for a clean slate, flashed the latest IoT image from 
> beaglebone.org and changed the kernel to 4.14.103-bone17
>
>
> here is the output you asked:
>
>
> root@beaglebone:/var/lib/cloud9/examplesPRUIO/examples# 
> /opt/scripts/tools/version.sh
> git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
> eeprom:[A335BNLTBWA51712EW001857]
> model:[TI_AM335x_BeagleBone_Black_Wireless]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2017.01-6-g55e748eda0]:[location: dd MBR]

Okay, the old version of u-boot in the eMMC is blocking the u-boot
overlay loading..

Run this and reboot..

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

The uio node should now properly show up..

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[78ba19]

>
> Hi Robert, thanks for your quick answer,


 In the meantime I went for a clean slate, flashed the latest IoT image 
from beaglebone.org and changed the kernel to 4.14.103-bone17


here is the output you asked: 


root@beaglebone:/var/lib/cloud9/examplesPRUIO/examples# 
/opt/scripts/tools/version.sh
git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7]
eeprom:[A335BNLTBWA51712EW001857]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.01-6-g55e748eda0]:[location: dd MBR]
kernel:[4.14.103-bone17]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[0.733245] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[0.734057] gpio-of-helper ocp:cape-universal: ready
END


upon reinstalling lipruio I still get the same errors when launching the 
exemples. 
The rproc driver no longer gets in the way (it doesn't show up on lsmod)

After forcing the libpruio-lkm.service to start, we get /dev/uio5 to appear.

Regardless, the 1.c example doesn't work.

>  

Trying the io_input.c examples gives:


root@beaglebone:/var/lib/cloud9/examplesPRUIO/examples# ./io_input
initialisation failed (failed opening prussdrv library)
destructor warning: constructor failed


 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/b82fe2b8-1666-48fd-b1bd-d9c35f781552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Robert Nelson]

On Thu, Mar 21, 2019 at 10:59 AM <78b...@gmail.com> wrote:
>>
>> Hi TJF,
>
>
> I was previously using iio but due to ADC sampling rate issues, I've been 
> trying to use libpruio on my BBB wireless with the latest image from 
> beaglebone (i.e Debian 9.5, 4.14.71-ti-r80) on an SD card.
>
> I've installed libpruio through sudo apt-get install libpruio libruio-dev 
> libpruio-lkm libpruio-doc
>
> I've read some of the troublshooting on this thread and followed quite a few 
> steps but I'm encountering a similar problem to the others mentionned here, 
> once compiled the 1.c program goes to segmentation fault.
>
> lsmod outputs this:
>
> root@beaglebone:/var/lib/cloud9# lsmod
> Module  Size  Used by
> xt_conntrack   16384  1
> ipt_MASQUERADE 16384  1
> nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
> aes_arm_bs 20480  0
> crypto_simd16384  1 aes_arm_bs
> cryptd 24576  1 crypto_simd
> wl18xx110592  0
> wlcore237568  1 wl18xx
> mac80211  696320  2 wl18xx,wlcore
> cfg80211  622592  3 wl18xx,wlcore,mac80211
> bnep   28672  2
> hci_uart   69632  0
> btqca  16384  1 hci_uart
> bluetooth 552960  24 hci_uart,btqca,bnep
> ecdh_generic   28672  1 bluetooth
> wlcore_sdio16384  0
> evdev  24576  1
> uio_pdrv_genirq16384  0
> usb_f_mass_storage 53248  2
> usb_f_acm  16384  2
> u_serial   20480  3 usb_f_acm
> usb_f_ecm  20480  2
> usb_f_rndis32768  4
> u_ether20480  2 usb_f_ecm,usb_f_rndis
> libcomposite   65536  18 
> usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
> iptable_nat16384  1
> nf_conntrack_ipv4  20480  3
> nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
> nf_nat_ipv416384  1 iptable_nat
> nf_nat 32768  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
> nf_conntrack  143360  6 
> nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
> iptable_mangle 16384  0
> iptable_filter 16384  1
> libpruio   16384  0
> uio_pruss  16384  0
> uio20480  2 uio_pruss,uio_pdrv_genirq
> spidev 20480  0
> pruss_soc_bus  16384  0
> pru_rproc  28672  0
> pruss  16384  1 pru_rproc
> pruss_intc 16384  1 pru_rproc
> ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
> x_tables   36864  5 
> iptable_mangle,ip_tables,iptable_filter,ipt_MASQUERADE,xt_conntrack
>
>
> I've modified /boot/uEvent.txt to stoppru_rproc from loading as suggested and 
> rebooted but the output of lsmod stays the same (and the program still goes 
> to segfault).
>
> modification in uEvent.txt:
> ###PRUSS OPTIONS
> ###pru_rproc (4.4.x-ti kernel)
> ##uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
> ###pru_rproc (4.14.x-ti kernel)
> ##uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
> ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel)
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
> ###
>
> I went so far as to remove AM335X-PRU-RPROC-4-14-TI-00A0.dtbo and 
> AM335X-PRU-RPROC-4-4-TI-00A0.dtbo from /lib/firmware, to no avail.
>
> Additionally the output of ls -l /dev/uio* is "no such file or directory", I 
> don't know why.
>
> root@beaglebone:/var/lib/cloud9# ls -l /dev/uio*
> ls: cannot access '/dev/uio*': No such file or directory
>
>
> And in case this helps:
>
> root@beaglebone:/var/lib/cloud9# ls -l /sys/devices/platform/libpruio
> total 0
> -rw-r--r-- 1 root root  4096 Mar 21 14:00 driver_override
> -r--r--r-- 1 root root  4096 Mar 21 14:00 modalias
> drwxr-xr-x 2 root root 0 Mar 21 14:00 power
> -rw-rw-r-- 1 root pruio 4096 Mar 21 13:36 state
> lrwxrwxrwx 1 root root 0 Mar 21 14:00 subsystem -> ../../../bus/platform
> -rw-r--r-- 1 root root  4096 Mar 21 13:36 uevent
>
>
> Do you have a lead on what the problem might be?

Let's see more details..

sudo /opt/scripts/tools/version.sh

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 11:00 AM,  wrote:

> I got the solutio (i think.. hehe)
>

If you're happy with the code you've got, who am I to argue about 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/CALHSORoNW726T2j6goi6QxUfJrewB%2BX747jT2jrGoM5Vvsbyhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[mesquita . rodrigo . c]

I got the solutio (i think.. hehe)


 /*file doiscs.c 
 Compile by: `gcc -Wall -o doiscs doiscs.c -lpruio` 
 
 */ 
 
 #include "stdio.h" 
 #include "unistd.h" 
 #include "../c_wrapper/pruio.h" 
 #include "time.h" 
 
 int main(int argc, char **argv) 
 { 
  float n[256]; 
  float v1[128]; 
  float v2[128]; 
  int i = 0; 
 
   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 0); 
 //! create new driver structure 
   pruio_adc_setStep(io, 9, 1, 0, 0, 0);   
  // step 9, AIN-0 
   pruio_adc_setStep(io, 10, 2, 0, 0, 0);   
 // step 10, AIN-1 
 
   if (pruio_config(io, 128, 9<<10 , 156250, 4)){ 
 printf("config failed (%s)\n", io->Errr);} 
   else { 
 
   if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); 
  // start measurement 
 
   else{ 
 sleep(1); 
 do{ 
 if(io->DRam[0] == (i)){ 
 n[i] = io->Adc->Value[i]; 
 i=i+1; 
 } 
 }while(i < 256); 
 
 for(i = 0; i<=127; i++ ){ 
  v1[i] = n[2*i]; 
  v2[i] = n[2*i +1]; 
 } 
 
 printf("adc1*\n"); 
 for(i=0; i<=127; i++){ 
 printf("%f \n", v1[i]*1.8/65536); 
 } 
 
 printf("\n adc2*\n"); 
 for(i=0; i<=127; i++){ 
 printf("%f \n ", v2[i]*1.8/65536); 
 } 
 
 } 
 
 } 
   pruio_destroy(io); 
 return 0; 
 }

The error is marked in yellow. The loop condition was considering the 
garbage :D




Em segunda-feira, 6 de fevereiro de 2017 18:55:30 UTC+1, William Hermans 
escreveu:
>
> Or better yet, get rid of the second loop entirely, and just print the 
> values as you receive them. However, printf() *is* a system all that would 
> definitely slow down your ADC read speeds. Unless you pipe the output of 
> the application to a file. Which would not be healthy for the emmc, or 
> sdcard you're running from.
>
> On Mon, Feb 6, 2017 at 10:52 AM, William Hermans  > wrote:
>
>> Thinking about how to "throttle" reading from the ADC to get correct 
>> values. A little more. One way you could potentially deal with that 
>> situation  could be to change both loops to a while() loop, and only 
>> increment your loop index value if the ADC index value is greater than 0. 
>> Or maybe test if the actual ADC index value is your loop index value +1. 
>> With that said, actually you would only need to throttle the ADC read loop, 
>> so the printing to screen loop could be left alone.
>>
>> However, this kind of loop would be very CPU intensive, but the problem 
>> with with using usleep() is that technically htis is a system call, and in 
>> addition to adding a hard coded delay, you're likely to also have some 
>> system( between user space and kernel space ) non deterministic delay 
>> penalty inured.
>>
>> On Mon, Feb 6, 2017 at 10:06 AM, William Hermans > > wrote:
>>
>>>
>>> On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita >> > wrote:
>>>
 Mr, Willians, thanks for your answer.

 According to the lipruio's documentation, the variable io->DRam[0] 
 contains the index of the last ADC data read.

 About the part:

 do{
 . . .
 }while(io->DRam[0] < 126);

 This is inconsistent with:

 for(i = 0; i<=127; i++ ){
 . . .
 }

 , 

 the for is to print the values stored. The do-while is to read the 
 sample 1 to 126. the samples 0 and 127 are read before and after this 
 loop, 
 respectively.

 What are you sugestions to improve my code, Mr. Hermans?

>>>
>>> Please, in the future do not email me personally. Please email to the 
>>> group, so everyone can see the answer, as this may help others in the 
>>> future. It also makes it much harder for me to follow the posts, and give a 
>>> proper answer. Anyway . . . 
>>>
>>> Assuming what you say is correct. Your loops are still off by two 
>>> between them. The do / while() loop being 1 based( starts from 1 ) where 
>>> the for() loop being zero based( starts from 0 ). To correct this most 
>>> simply, change your for loop to i<=125, or i<126 if that is clearer for 
>>> you.
>>>
>>> After that, starting from the top down.
>>>
>>>  float n[256];
>>>  int a[256];
>>>  int i=0;
>>>
>>>
>>> float n[256]; is not needed. For this particular application you only 
>>> need one float value for printing a voltage value in your printf() 
>>> statement. In fact, in the future if you plan on expanding on this 
>>> application you may wish to do away with float values entirely, send the 
>>> raw PRU values to an external source( if that's what happens ) and let the 
>>> external source do the heavy math. This makes what 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Or better yet, get rid of the second loop entirely, and just print the
values as you receive them. However, printf() *is* a system all that would
definitely slow down your ADC read speeds. Unless you pipe the output of
the application to a file. Which would not be healthy for the emmc, or
sdcard you're running from.

On Mon, Feb 6, 2017 at 10:52 AM, William Hermans  wrote:

> Thinking about how to "throttle" reading from the ADC to get correct
> values. A little more. One way you could potentially deal with that
> situation  could be to change both loops to a while() loop, and only
> increment your loop index value if the ADC index value is greater than 0.
> Or maybe test if the actual ADC index value is your loop index value +1.
> With that said, actually you would only need to throttle the ADC read loop,
> so the printing to screen loop could be left alone.
>
> However, this kind of loop would be very CPU intensive, but the problem
> with with using usleep() is that technically htis is a system call, and in
> addition to adding a hard coded delay, you're likely to also have some
> system( between user space and kernel space ) non deterministic delay
> penalty inured.
>
> On Mon, Feb 6, 2017 at 10:06 AM, William Hermans 
> wrote:
>
>>
>> On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
>> mesquita.rodrig...@gmail.com> wrote:
>>
>>> Mr, Willians, thanks for your answer.
>>>
>>> According to the lipruio's documentation, the variable io->DRam[0]
>>> contains the index of the last ADC data read.
>>>
>>> About the part:
>>>
>>> do{
>>> . . .
>>> }while(io->DRam[0] < 126);
>>>
>>> This is inconsistent with:
>>>
>>> for(i = 0; i<=127; i++ ){
>>> . . .
>>> }
>>>
>>> ,
>>>
>>> the for is to print the values stored. The do-while is to read the
>>> sample 1 to 126. the samples 0 and 127 are read before and after this loop,
>>> respectively.
>>>
>>> What are you sugestions to improve my code, Mr. Hermans?
>>>
>>
>> Please, in the future do not email me personally. Please email to the
>> group, so everyone can see the answer, as this may help others in the
>> future. It also makes it much harder for me to follow the posts, and give a
>> proper answer. Anyway . . .
>>
>> Assuming what you say is correct. Your loops are still off by two between
>> them. The do / while() loop being 1 based( starts from 1 ) where the for()
>> loop being zero based( starts from 0 ). To correct this most simply, change
>> your for loop to i<=125, or i<126 if that is clearer for you.
>>
>> After that, starting from the top down.
>>
>>  float n[256];
>>  int a[256];
>>  int i=0;
>>
>>
>> float n[256]; is not needed. For this particular application you only
>> need one float value for printing a voltage value in your printf()
>> statement. In fact, in the future if you plan on expanding on this
>> application you may wish to do away with float values entirely, send the
>> raw PRU values to an external source( if that's what happens ) and let the
>> external source do the heavy math. This makes what your beaglebone is doing
>> more efficient, and if performance is needed can make a huge difference.
>> Also, you can look into using fixed point numbers, but this would use more
>> processor cycles than just sending out raw values.
>>
>> int a[256]; Assuming 128 samples, I might change this to: int
>> channel_n[128]; ( n representing the actual channel you're reading from ),
>> then do all the formatting in your printf() statement. If, and when you
>> decide to print more than one channel worth of samples. This is however
>> more a matter of semantics,  but it'll also make your code much more
>> readable. Again, you need to read the C standard  for the compiler you're
>> using. It does seem possible you're using a post C99 compiler as you're not
>> initializing the variable i within the for() loop. Again, make sure your
>> array has enough room for a NULL termination byte, if needed. Which
>> wouldn't be of type byte, but instead of type int.
>>
>> The libpruio stuff TJF will be able to give you a much better answer on.
>> As it's his code, and I know nearly nothing of the specifics for this code.
>>
>> if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
>> start measurement
>> This is also a bit unclear to me, mostly due to not knowing the
>> implementation, but I'd probably move this if() statement into a while
>> statement. That way you can loop, and sleep 1 second between fails.
>> Assuming the check fails more than once. Still it'd be clearer to at least
>> me, which may not matter to you, or anyone else. Semantics . . . However,
>> as it stands, if the check fails, you code will probably just exit. Maybe
>> this is what you want ?
>>
>> As for your index values being "off" or just plain zero in some cases.
>> The first thought that comes to mind is that you're trying to read from the
>> ADC too fast. But again, I have no idea what TJF's code is doing, so this
>> may not be possible. 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Thinking about how to "throttle" reading from the ADC to get correct
values. A little more. One way you could potentially deal with that
situation  could be to change both loops to a while() loop, and only
increment your loop index value if the ADC index value is greater than 0.
Or maybe test if the actual ADC index value is your loop index value +1.
With that said, actually you would only need to throttle the ADC read loop,
so the printing to screen loop could be left alone.

However, this kind of loop would be very CPU intensive, but the problem
with with using usleep() is that technically htis is a system call, and in
addition to adding a hard coded delay, you're likely to also have some
system( between user space and kernel space ) non deterministic delay
penalty inured.

On Mon, Feb 6, 2017 at 10:06 AM, William Hermans  wrote:

>
> On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
> mesquita.rodrig...@gmail.com> wrote:
>
>> Mr, Willians, thanks for your answer.
>>
>> According to the lipruio's documentation, the variable io->DRam[0]
>> contains the index of the last ADC data read.
>>
>> About the part:
>>
>> do{
>> . . .
>> }while(io->DRam[0] < 126);
>>
>> This is inconsistent with:
>>
>> for(i = 0; i<=127; i++ ){
>> . . .
>> }
>>
>> ,
>>
>> the for is to print the values stored. The do-while is to read the sample
>> 1 to 126. the samples 0 and 127 are read before and after this loop,
>> respectively.
>>
>> What are you sugestions to improve my code, Mr. Hermans?
>>
>
> Please, in the future do not email me personally. Please email to the
> group, so everyone can see the answer, as this may help others in the
> future. It also makes it much harder for me to follow the posts, and give a
> proper answer. Anyway . . .
>
> Assuming what you say is correct. Your loops are still off by two between
> them. The do / while() loop being 1 based( starts from 1 ) where the for()
> loop being zero based( starts from 0 ). To correct this most simply, change
> your for loop to i<=125, or i<126 if that is clearer for you.
>
> After that, starting from the top down.
>
>  float n[256];
>  int a[256];
>  int i=0;
>
>
> float n[256]; is not needed. For this particular application you only
> need one float value for printing a voltage value in your printf()
> statement. In fact, in the future if you plan on expanding on this
> application you may wish to do away with float values entirely, send the
> raw PRU values to an external source( if that's what happens ) and let the
> external source do the heavy math. This makes what your beaglebone is doing
> more efficient, and if performance is needed can make a huge difference.
> Also, you can look into using fixed point numbers, but this would use more
> processor cycles than just sending out raw values.
>
> int a[256]; Assuming 128 samples, I might change this to: int
> channel_n[128]; ( n representing the actual channel you're reading from ),
> then do all the formatting in your printf() statement. If, and when you
> decide to print more than one channel worth of samples. This is however
> more a matter of semantics,  but it'll also make your code much more
> readable. Again, you need to read the C standard  for the compiler you're
> using. It does seem possible you're using a post C99 compiler as you're not
> initializing the variable i within the for() loop. Again, make sure your
> array has enough room for a NULL termination byte, if needed. Which
> wouldn't be of type byte, but instead of type int.
>
> The libpruio stuff TJF will be able to give you a much better answer on.
> As it's his code, and I know nearly nothing of the specifics for this code.
>
> if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
> start measurement
> This is also a bit unclear to me, mostly due to not knowing the
> implementation, but I'd probably move this if() statement into a while
> statement. That way you can loop, and sleep 1 second between fails.
> Assuming the check fails more than once. Still it'd be clearer to at least
> me, which may not matter to you, or anyone else. Semantics . . . However,
> as it stands, if the check fails, you code will probably just exit. Maybe
> this is what you want ?
>
> As for your index values being "off" or just plain zero in some cases. The
> first thought that comes to mind is that you're trying to read from the ADC
> too fast. But again, I have no idea what TJF's code is doing, so this may
> not be possible. That would be the first place I'd look though, and in fact
> looking at your output, that seems very possible. As every value that has a
> garbage index value seems to be zero, or close to it. Ask TJF how you
> should throttle your loop. e.g. does he have something implemented in the
> library, or not.
>
> The rest of your code looks like it should work, so I'd clean up your code
> a bit, throttle the ADC reading loop how TJF suggests, and check your
> application output.
>
>
>
> On Mon, Feb 6, 2017 at 8:50 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
mesquita.rodrig...@gmail.com> wrote:

> Mr, Willians, thanks for your answer.
>
> According to the lipruio's documentation, the variable io->DRam[0]
> contains the index of the last ADC data read.
>
> About the part:
>
> do{
> . . .
> }while(io->DRam[0] < 126);
>
> This is inconsistent with:
>
> for(i = 0; i<=127; i++ ){
> . . .
> }
>
> ,
>
> the for is to print the values stored. The do-while is to read the sample
> 1 to 126. the samples 0 and 127 are read before and after this loop,
> respectively.
>
> What are you sugestions to improve my code, Mr. Hermans?
>

Please, in the future do not email me personally. Please email to the
group, so everyone can see the answer, as this may help others in the
future. It also makes it much harder for me to follow the posts, and give a
proper answer. Anyway . . .

Assuming what you say is correct. Your loops are still off by two between
them. The do / while() loop being 1 based( starts from 1 ) where the for()
loop being zero based( starts from 0 ). To correct this most simply, change
your for loop to i<=125, or i<126 if that is clearer for you.

After that, starting from the top down.

 float n[256];
 int a[256];
 int i=0;


float n[256]; is not needed. For this particular application you only need
one float value for printing a voltage value in your printf() statement. In
fact, in the future if you plan on expanding on this application you may
wish to do away with float values entirely, send the raw PRU values to an
external source( if that's what happens ) and let the external source do
the heavy math. This makes what your beaglebone is doing more efficient,
and if performance is needed can make a huge difference. Also, you can look
into using fixed point numbers, but this would use more processor cycles
than just sending out raw values.

int a[256]; Assuming 128 samples, I might change this to: int
channel_n[128]; ( n representing the actual channel you're reading from ),
then do all the formatting in your printf() statement. If, and when you
decide to print more than one channel worth of samples. This is however
more a matter of semantics,  but it'll also make your code much more
readable. Again, you need to read the C standard  for the compiler you're
using. It does seem possible you're using a post C99 compiler as you're not
initializing the variable i within the for() loop. Again, make sure your
array has enough room for a NULL termination byte, if needed. Which
wouldn't be of type byte, but instead of type int.

The libpruio stuff TJF will be able to give you a much better answer on. As
it's his code, and I know nearly nothing of the specifics for this code.

if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
start measurement
This is also a bit unclear to me, mostly due to not knowing the
implementation, but I'd probably move this if() statement into a while
statement. That way you can loop, and sleep 1 second between fails.
Assuming the check fails more than once. Still it'd be clearer to at least
me, which may not matter to you, or anyone else. Semantics . . . However,
as it stands, if the check fails, you code will probably just exit. Maybe
this is what you want ?

As for your index values being "off" or just plain zero in some cases. The
first thought that comes to mind is that you're trying to read from the ADC
too fast. But again, I have no idea what TJF's code is doing, so this may
not be possible. That would be the first place I'd look though, and in fact
looking at your output, that seems very possible. As every value that has a
garbage index value seems to be zero, or close to it. Ask TJF how you
should throttle your loop. e.g. does he have something implemented in the
library, or not.

The rest of your code looks like it should work, so I'd clean up your code
a bit, throttle the ADC reading loop how TJF suggests, and check your
application output.



On Mon, Feb 6, 2017 at 8:50 AM, William Hermans  wrote:

>
>
> On Mon, Feb 6, 2017 at 4:21 AM,  wrote:
>
>> Hello Mr. TJF
>>
>> First of All, thank you so much for providing support on real-time tasks
>> using a low cost plataform.
>> I'm trying to apply the libary "libpruio" to make a system for energy
>> meansurement using the beaglebone black. To do this,  I need to enable 2
>> ADC channels, set a sample time, fil a buffer with the samples and make
>> some calculation that includes the FFT. I'm really newbie on
>> microprocessors, but i wrote a simple C code. The idea of this code is just
>> to make 128 samples os the two channels and print the values. Just it:
>>
>> #include "unistd.h"
>> #include "../c_wrapper/pruio.h" // include header
>> #include "time.h"
>>
>>
>> //! The main function.
>> int main(/*int argc, char **argv*/)
>> {
>>  float n[256];
>>  int a[256];
>>  int i=0;
>>
>>
>>   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
>> driver structure

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[mesquita . rodrigo . c]

thank you so much for the answer, Mr. William.

According do the documentation of the libpruio, the variable io->DRam[0] 
stores the index of the last data read. This data, is stored in the vector 
io->Adc->Value[].
I Just want 128 samples of each chanel.

In fact, I completely agree with you: there is garbage in the resoults, and 
this is why it look so strange..


Em segunda-feira, 6 de fevereiro de 2017 16:51:02 UTC+1, William Hermans 
escreveu:
>
>
>
> On Mon, Feb 6, 2017 at 4:21 AM,  
> wrote:
>
>> Hello Mr. TJF
>>
>> First of All, thank you so much for providing support on real-time tasks 
>> using a low cost plataform.
>> I'm trying to apply the libary "libpruio" to make a system for energy 
>> meansurement using the beaglebone black. To do this,  I need to enable 2 
>> ADC channels, set a sample time, fil a buffer with the samples and make 
>> some calculation that includes the FFT. I'm really newbie on 
>> microprocessors, but i wrote a simple C code. The idea of this code is just 
>> to make 128 samples os the two channels and print the values. Just it:
>>
>> #include "unistd.h"
>> #include "../c_wrapper/pruio.h" // include header
>> #include "time.h"
>>
>>
>> //! The main function.
>> int main(/*int argc, char **argv*/)
>> {
>>  float n[256];
>>  int a[256];
>>  int i=0;
>>
>>
>>   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new 
>> driver structure
>>   pruio_adc_setStep(io, 9, 1, 0, 0, 0); 
>>  // step 9, AIN-0
>>   pruio_adc_setStep(io, 10, 2, 0, 0, 0);
>>
>>
>>   if (pruio_config(io, 128, 9<<10 , 156250, 4)){ // upload (default) 
>> settings, start IO mode
>>   printf("config failed (%s)\n", io->Errr);}
>>   else {
>>
>>
>>   if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); // 
>> start measurement
>>
>>
>>   else{
>> sleep(1);
>>
>>
>> i=io->DRam[0];
>> a[i] = i;
>> n[i] = io->Adc->Value[i];
>> do{
>> if(i != io->DRam[0]){
>> i=io->DRam[0];
>> a[i] = i;
>> n[i] = io->Adc->Value[i];
>> }
>> }while(io->DRam[0] < 126);
>> a[io->DRam[0]] = io->DRam[0];
>> n[io->DRam[0]] = io->Adc->Value[io->DRam[0]];
>>
>> for(i = 0; i<=127; i++ ){
>> printf("amostra %d-   %f \n", 
>> a[i],  (n[i]/65536)*1.8);
>> }
>>
>> }
>> /* we're done */
>> }
>>   pruio_destroy(io);/* destroy driver structure */
>> return 0;
>> }
>>
>>   Right from the start I see several problems with your code. 
>
> 125 zero based indexes. Or is it 128 ? Or do you really want 127 indexes ? 
> It's impossible for us to know.
>
> do{
> . . .
> }while(io->DRam[0] < 126);
>
> This is inconsistent with:
>
> for(i = 0; i<=127; i++ ){
> . . .
> }
>
> So, I have no clue what io-DRam[] *is*, but I can assume, somehow, you're 
> storing ADC values in DRAM *somehow* Based on your comments. However, first 
> off,  your indexes to not match one another from buffer "packaging" to 
> buffer "unpacking". Secondly, you're not clearing your buffers(arrays) 
> before using them. This is what the "garbage" numbers are coming from. It's 
> just random values in memory, which by the way is very bad from a couple 
> perspectives. But this also leaves these arrays without a NULL termination 
> at the end. Which is very unsafe, as a potential stack overflow. At least 
> this applies for type char[], I'd have to double check the C standard that 
> you're using for your particular case to make sure. Which you can do more 
> easily than I.
>
> Additionally, your code is hard to follow. With variable names such as a, 
> n, and i, and zero helpful comments. The code is not exactly self 
> documenting. But here is what seems to be happening. You're only storing 
> one ADC channel value into the first half of your array. Or maybe the 
> conditional if statement is testing for this somehow( unclear ), and taking 
> care of that ?
>
> Assuming what you really want is 128 samples of the two ADC channels you 
> mention, your code needs to change. You need to check and make sure you're 
> never going to overflow from your arrays. Which may mean your arrays need 
> be of size 256 + 1 for each given type. Secondly, your loops need to be 
> consistent at whichever number of values you wish to store. Thirdly, you 
> need to clear your arrays before you use them, which can be done at array 
> initialization, or by using memset(), after initialization.
>
> A couple of things worth mentioning. In your printf() statement I'm not 
> sure of libpruio's implementation, but from my experience with the 
> beaglebone's ADC, this does not seem right ---> (n[i]/65536)*1.8) Values 
> output from the ADC are in range 0-4095, I'd double check to make sure that 
> is correct. It could be that libpruio's 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 4:21 AM,  wrote:

> Hello Mr. TJF
>
> First of All, thank you so much for providing support on real-time tasks
> using a low cost plataform.
> I'm trying to apply the libary "libpruio" to make a system for energy
> meansurement using the beaglebone black. To do this,  I need to enable 2
> ADC channels, set a sample time, fil a buffer with the samples and make
> some calculation that includes the FFT. I'm really newbie on
> microprocessors, but i wrote a simple C code. The idea of this code is just
> to make 128 samples os the two channels and print the values. Just it:
>
> #include "unistd.h"
> #include "../c_wrapper/pruio.h" // include header
> #include "time.h"
>
>
> //! The main function.
> int main(/*int argc, char **argv*/)
> {
>  float n[256];
>  int a[256];
>  int i=0;
>
>
>   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
> driver structure
>   pruio_adc_setStep(io, 9, 1, 0, 0, 0);
>// step 9, AIN-0
>   pruio_adc_setStep(io, 10, 2, 0, 0, 0);
>
>
>   if (pruio_config(io, 128, 9<<10 , 156250, 4)){ // upload (default)
> settings, start IO mode
>   printf("config failed (%s)\n", io->Errr);}
>   else {
>
>
>   if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
> start measurement
>
>
>   else{
> sleep(1);
>
>
> i=io->DRam[0];
> a[i] = i;
> n[i] = io->Adc->Value[i];
> do{
> if(i != io->DRam[0]){
> i=io->DRam[0];
> a[i] = i;
> n[i] = io->Adc->Value[i];
> }
> }while(io->DRam[0] < 126);
> a[io->DRam[0]] = io->DRam[0];
> n[io->DRam[0]] = io->Adc->Value[io->DRam[0]];
>
> for(i = 0; i<=127; i++ ){
> printf("amostra %d-   %f \n",
> a[i],  (n[i]/65536)*1.8);
> }
>
> }
> /* we're done */
> }
>   pruio_destroy(io);/* destroy driver structure */
> return 0;
> }
>
>   Right from the start I see several problems with your code.

125 zero based indexes. Or is it 128 ? Or do you really want 127 indexes ?
It's impossible for us to know.

do{
. . .
}while(io->DRam[0] < 126);

This is inconsistent with:

for(i = 0; i<=127; i++ ){
. . .
}

So, I have no clue what io-DRam[] *is*, but I can assume, somehow, you're
storing ADC values in DRAM *somehow* Based on your comments. However, first
off,  your indexes to not match one another from buffer "packaging" to
buffer "unpacking". Secondly, you're not clearing your buffers(arrays)
before using them. This is what the "garbage" numbers are coming from. It's
just random values in memory, which by the way is very bad from a couple
perspectives. But this also leaves these arrays without a NULL termination
at the end. Which is very unsafe, as a potential stack overflow. At least
this applies for type char[], I'd have to double check the C standard that
you're using for your particular case to make sure. Which you can do more
easily than I.

Additionally, your code is hard to follow. With variable names such as a,
n, and i, and zero helpful comments. The code is not exactly self
documenting. But here is what seems to be happening. You're only storing
one ADC channel value into the first half of your array. Or maybe the
conditional if statement is testing for this somehow( unclear ), and taking
care of that ?

Assuming what you really want is 128 samples of the two ADC channels you
mention, your code needs to change. You need to check and make sure you're
never going to overflow from your arrays. Which may mean your arrays need
be of size 256 + 1 for each given type. Secondly, your loops need to be
consistent at whichever number of values you wish to store. Thirdly, you
need to clear your arrays before you use them, which can be done at array
initialization, or by using memset(), after initialization.

A couple of things worth mentioning. In your printf() statement I'm not
sure of libpruio's implementation, but from my experience with the
beaglebone's ADC, this does not seem right ---> (n[i]/65536)*1.8) Values
output from the ADC are in range 0-4095, I'd double check to make sure that
is correct. It could be that libpruio's values are different in
implementation through some sort of conversation. Secondly, for some
reason, it may become readily apparent that your index value may contain a
lot of zero's in the middle indexes. You're going to need to look into why
that it happening after you clean your code up some. As I said above. I am
not familiar with libpruio's implementation, and the rest of your code is
not clear enough to make a determination at a glance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Thanks for feedback!

BR

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[andreas . vogelfrei]

[SOLVED]

Hello TJF,

I will answer in English to give other users the possibility to use this 
information as well.

Thank you for your answer. With this information I was able to compile the 
supplied libpruio FreeBASIC examples.

Steps to take (on the BeagleBone, as root, otherwise use 'sudo'):

1.) wget 
http://www.freebasic-portal.de/dlfiles/625/freebasic_1.01.0debian7_armhf.deb 
2.) dpkg --install freebasic_1.01.0debian7_armhf.deb 
(Note: On 
http://www.freebasic-portal.de/downloads/fb-on-arm/debian-package-fbc-1-01-357.html
 
  you type: freebasic_1.01.0~debian7_armhf.deb which make copy 
and paste from the website resulting in an error)
3.) apt-get -f install
4.) rm /usr/local/bin/fbc
5.) reboot
6.) cp -R /usr/local/include/freebasic/BBB /usr/include/freebasic/

After this, compiling fbc -w all analyse.bas works.

Thank you.




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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[TJF]

Am Montag, 10. November 2014 21:52:26 UTC+1 schrieb William Hermans:

 TJF,

 I'd be willing at some point to help you port some code for your project, 


Hello William, welcome at the libpruio project.

I know about many tasks to improve the libpruio package. Some of them might 
be fun for you.
 

 Do you have a quick setup guide for your library ?


Find the installation guide in the documentation at page Preparation 
http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_preparation.html
.

Could you check the documentation text? It seems that you're a native 
speaker with good language skills. You should be able to improve the text a 
lot. (I could mail a pdf version, where you could add your comments.)
 

 Other problem is that I am not exactly a hardware person so much as a 
 software developer, and I am semi new to embedded Linux. The new to embeded 
 Linux part shouldnt be too much of a problem, just means I need to read up 
 on the libc functions available to me. Not being an EE however slows me 
 down greatly however, since I do not want to fry my boards . . .


I'm neither an electronics engineer, nor a programmer, nor an expert on 
embedded systems, nor a native speaker. I think I realy know what you're 
talking about.

I'm looking at the project from the user point of view, evaluating how 
things should work and then do my best to make this happen. And, knowing 
there's no perfect solution, I try to learn from my failures.
 

 As an aside, I must have really really become accustomed to C over the 
 last several years, BASIC syntax hurts my eyes, lol but it was the very 
 first language I picked up 17+ years ago . . . 


Basic isn't the first programming language I used, but for me it's the most 
productive. I'm not speaking about the m$ dialects, which I dislike as 
well, and which I don't use since the middle 80's. (AFAIR QB 4.5 was the 
last one I tested and droped.) But there're other dialects, which are in 
some points more powerful than C, and easier to read for my old eyes.

The libpruio package contains some examples, as you can see at this 
documentation page 
http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html.
 
I think all code in folder src/c_examples could have a review. But most 
important, there're some examples with grafics output

   - pwm_adc.bas, 
   - osci.bas, 
   - rb_oszi.bas, and 
   - triggers.bas

which I didn't translate to C code jet. My idea was to use cairo grafics 
library, but there might be a more common way to create short and easy C 
code?

Note: libpruio examples should be easy to understand for beginners and 
should have less than 200 lines of code.

Feel free to send further colaboration ideas and discuss details (here or 
PM). Or just make your choice and start.

BR

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Back in the early to mid 80's I was living in Kitzingen,Germany, and I was
young. If you catch my meaning.

But anyway, I am still a bit busy, but perhaps in my spare time I can read
your documentation a bit at a time to be used to it. It is something I've
been wanting to do for a while now . . .

On Tue, Nov 11, 2014 at 6:06 AM, TJF jeli.freih...@gmail.com wrote:



 Am Montag, 10. November 2014 21:52:26 UTC+1 schrieb William Hermans:

 TJF,

 I'd be willing at some point to help you port some code for your project,


 Hello William, welcome at the libpruio project.

 I know about many tasks to improve the libpruio package. Some of them
 might be fun for you.


 Do you have a quick setup guide for your library ?


 Find the installation guide in the documentation at page Preparation
 http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_preparation.html
 .

 Could you check the documentation text? It seems that you're a native
 speaker with good language skills. You should be able to improve the text a
 lot. (I could mail a pdf version, where you could add your comments.)


 Other problem is that I am not exactly a hardware person so much as a
 software developer, and I am semi new to embedded Linux. The new to embeded
 Linux part shouldnt be too much of a problem, just means I need to read up
 on the libc functions available to me. Not being an EE however slows me
 down greatly however, since I do not want to fry my boards . . .


 I'm neither an electronics engineer, nor a programmer, nor an expert on
 embedded systems, nor a native speaker. I think I realy know what you're
 talking about.

 I'm looking at the project from the user point of view, evaluating how
 things should work and then do my best to make this happen. And, knowing
 there's no perfect solution, I try to learn from my failures.


 As an aside, I must have really really become accustomed to C over the
 last several years, BASIC syntax hurts my eyes, lol but it was the very
 first language I picked up 17+ years ago . . .


 Basic isn't the first programming language I used, but for me it's the
 most productive. I'm not speaking about the m$ dialects, which I dislike as
 well, and which I don't use since the middle 80's. (AFAIR QB 4.5 was the
 last one I tested and droped.) But there're other dialects, which are in
 some points more powerful than C, and easier to read for my old eyes.

 The libpruio package contains some examples, as you can see at this
 documentation page
 http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html.
 I think all code in folder src/c_examples could have a review. But most
 important, there're some examples with grafics output

- pwm_adc.bas,
- osci.bas,
- rb_oszi.bas, and
- triggers.bas

 which I didn't translate to C code jet. My idea was to use cairo grafics
 library, but there might be a more common way to create short and easy C
 code?

 Note: libpruio examples should be easy to understand for beginners and
 should have less than 200 lines of code.

 Feel free to send further colaboration ideas and discuss details (here or
 PM). Or just make your choice and start.

 BR

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


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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

TJF,

I'd be willing at some point to help you port some code for your project,
Do you have a quick setup guide for your library ? I did read some of your
documents a couple months ago, but then i got busy with many other things .
. . such is life.

Other problem is that I am not exactly a hardware person so much as a
software developer, and I am semi new to embedded Linux. The new to embeded
Linux part shouldnt be too much of a problem, just means I need to read up
on the libc functions available to me. Not being an EE however slows me
down greatly however, since I do not want to fry my boards . . .

As an aside, I must have really really become accustomed to C over the last
several years, BASIC syntax hurts my eyes, lol but it was the very first
language I picked up 17+ years ago . . .

On Mon, Nov 10, 2014 at 6:10 AM, TJF jeli.freih...@gmail.com wrote:

 Oups, found a buck right when I posted:

 line 70
 SWAP p0, p1 : EXIT DO

 should be
 SWAP p0, p1 : EXIT WHILE

 Soory!

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


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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

 *If you want to provide better sample code you're free to go, but please
 don't be that smart-ass stating facts that are only half or not at all
 true.*


Ok, that is just plain rude.

So, since we're being rude now. I should mention the code you pasted is C
and not C++. I figured you should know this since you think you know
everything.

I will tell you what. You keep on trucking on, and nesting while loops 100
deep if you like, and I'll refrain from reading your posts any further to
keep my eyes from bleeding.

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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Whew ! If you're looking for fast, you're not going about it the right
way.

1) Nested loops are bad.

2) A file open, and close every cycle on the outer loop ? Is that really
necessary ?  Big time performance hit.

3) spintf() as I recall is a fairly slow function.

A few things you can do to fix these issues.

Remove the nested loops and replace with a, if/else control block. Make the
conditions checks that are most likely to pass more often - first. Also,
simplify your math. If the numbers are going to be consistent, and non
changing. Hard code the values. Multiplication and division on fast moving
code will slow you down. Especially if done on floating point numbers. So
unless I missed an assignment somewhere . . .



*while(io-DRam[0]  (bStep+1) * bsSize  io-DRam[0]  bStep * bsSize)
{ ...}*

if bsStep which seems to be left unassigned ( 0 ) + 1 = 1

1 * any value is going to be that any value . . . Some compilers may
optimize this out, but why ? It also makes the code less readable.

Also . . .

*fwrite(io-Adc-Value, sizeof(uint16), 16000, oFile);*


Is a potential performance hit. Quite honestly I am not sure *if*
*sizeof(uint16)
*would be checked once at compile time, or if it would be checked every
cycle at run time. But you can fix this simply by hard coding the value.
Make it a constant if you feel it makes the code more readable.


Open the file once before the loop, and close it after the loop is done.
That is, if at all possible. Also there is a trap for new players, in
that if the application exits abnormally, the file may still be left
opened. So a check when the application first starts may be in order.

As an aside, you can simplify the whole application by just gathering  raw
data, and shifting it out to the the general purpose processor ( ARM ).
Which then the main processor can be made to do all the heavy math
lifting.

Anyway I hope this is useful information, and my posting is not meant to
demean, or otherwise come across as smart-ass.

On Thu, Nov 6, 2014 at 4:18 PM, nirok...@gmail.com wrote:

 Hey TJF,

 I've got it compiled and working. I can't yet test if the adc keeps up
 since I the function generator we've ordered got out of stock However I
 changed my code a bit so it would close the files and the whole program has
 a end statement. It's currently 1 channel at ~220 kS/s. I haven't pushed it
 further because I don't know what will happen. With my understanding of the
 PRU I guess the PRU can't break anything on the BBB while doing that, but I
 don't know so I don't want to push my luck.

 #include unistd.h
 #include stdio.h
 #include ../c_wrapper/pruio.h


 //! The main function.
 int main(int argc, char **argv)
 {
   FILE* oFile;
   uint8 bDiv = 4, bStep;
   uint32 bSize = 1e6;
   uint32 bsSize = bSize/bDiv;
   uint8 cycles = 2;
   char fName[12];
   int i = 0;


   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
 driver structure
   pruio_adc_setStep(io, 9, 4, 0, 0, 0); // step 9 for AIN-4
   if (pruio_config(io, bSize, 1  9, 4545, 0)){ // '1  9' - step 9,
 '6285' ns - 159.1 kHz
 printf(config failed (%s)\n, io-Errr);}
   else{
 pruio_rb_start(io);
 sleep(1);
 for(i=0; icycles; i++){
   sprintf(fName, output.%u,i);
   oFile = fopen(fName,wb);
   while(bStepbDiv){
 while(io-DRam[0]  (bStep+1) * bsSize  io-DRam[0]  bStep *
 bsSize){
   sleep(1);
 }
 printf(writing samples %u-%u\n,bStep*bsSize, (bStep+1)*bsSize);
 fwrite(io-Adc-Value, sizeof(uint16), 16000, oFile);
 bStep++;
   }
   bStep=0;
   fclose(oFile);
 }
   }
   pruio_destroy(io);
   return 0;
 }


 Greetings,
 Nils Kohrs

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


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

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[niroko89]

Thanks for the feedback. I know that I'm far from a good c programmer, but 
I'm not that bad.

From reading the book The C++ Programming Language by Bjarne Stourstrup 
(the maker of c++) I know a thing or two about the compiler.
First of, all sizeof(...) are replace at compile time. Secondly, all 
operators that can be calculated at compile time will be calculated at 
compile time. This makes the last two optimizations you suggest just 
working with the code harder.

I don't know if you've runned this code your self already, but if you would 
have noticed that the limiting part is the PRU coprocessor and not actually 
the ARM processor itself.
With that in mind option 1 is just the flavor of code you choose.

About point 3: If you want to concatenate a integer to a string/char[] 
there are two options. First you can convert the into to a char[] with 
itoa() and then use strcat(), or you use the minimal slower spintf which is 
more readable

And lastly about point 2, if you want to write it to multiple files, you'll 
have to close the old one and open the new one every time you go on to the 
next file.

This programs was for me to test the performance, and as you see from the 
one seconds sleeps I've build into it, it runs fine and a lot faster than 
it needs to be. Also from any of the examples included to libpruio you can 
expect the reader not to just copy the code 1:1 and live happily ever 
after. Everyone will edit it to their liking and performance needs. For me 
this runs fine and error handling with the file io is something you can 
implement your self, if you need it. This is example code and not 
production code...

And on a last note, you've made me aware of a little error in my code 
though, the line:

fwrite(io-Adc-Value, sizeof(uint16), 16000, oFile);

should be

fwrite(io-Adc-Value, sizeof(uint16), bsSize, oFile);

If you want to provide better sample code you're free to go, but please 
don't be that smart-ass stating facts that are only half or not at all true.

Greetings,
Nils Kohrs

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