I have a solution that seems to work for our purposes.
Thanks for all the suggestions and help. I am going to keep learning the
PRUs because I think we'll need them in a more sophisticated version of the
product.
This is a great community and I appreciate the patience with this neophyte
to
Yes I did and it did not work on my system. I don't remember why now.
On Thursday, February 18, 2021 at 1:47:29 PM UTC-5 Dennis Bieber wrote:
> On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> wrote:
>
> >I think if I could just find how to r
On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Walter Cromer
wrote:
>I think if I could just find how to read the clock on the PRU with C, I can
>probably take it from here. And of course, it needs to be giving me
>milliseconds. From what I read the main cl
There is a cycle count register[1]
I'm not using wireless, so I don't know it's current status.
--Mark
[1]
https://markayoder.github.io/PRUCookbook/07more/more.html#_using_the_built_in_counter_for_timing
On Thursday, February 18, 2021 at 12:38:24 PM UTC-5
wal...@edenconceptsllc.com wrote:
>
I'll look into the pthread tutorials.
So is there no way to just read the clock on the PRU to get elapsed time?
Also, I've booted my BBB Wireless with the SD card with the OS that you
recommended and the access point doesn't come up. It doesn't appear to be
disabled in uEnv.txt. Any ideas
I use *__delay_cycles()* on the PRU to get accurate timing. Each cycle is 5
ns.
Here [1] is an example of passing data between the PRU and the ARM.
Try googling *pthread tutorial,* there appear to be many examples.
I'm still voting for pthreads.
--Mark
[1]
https://markayoder.github.io/PRUC
I think if I could just find how to read the clock on the PRU with C, I can
probably take it from here. And of course, it needs to be giving me
milliseconds. From what I read the main clock functions don't work below
seconds.
On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder
No. I am not familiar with that, Mark. I found Strawson's reference to it
online but it doesn't explain what it is or what it does. Is there a
better reference somewhere? Google didn't bring up anything that looked
useful.
On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wr
Have you tried starting a pthread that sleeps for 20 ms and then it stops
the read?
On Thursday, February 18, 2021 at 10:35:04 AM UTC-5
wal...@edenconceptsllc.com wrote:
> Mark,
>
> I use usleep a lot but in this case I don't want to pause. I want to keep
> reading the sensors for N millisec
Mark,
I use usleep a lot but in this case I don't want to pause. I want to keep
reading the sensors for N milliseconds. I do pause between reads using
usleep(2) to create a 20ms delay between sensor reads. I started with
a routine that essentially counts up the amount of time by estim
Walter:
It's good to hear you have the PRUs working. I still think if all you
need is millisecond timing the PRUs are over kill.
In C you can use *usleep()* and pass it the number of microseconds you want
to pause.
--Mark
On Thursday, February 18, 2021 at 10:00:10 AM UTC-5
wal...@edenconcep
I've gone through the cookbook and it's very helpful.
I'm still fuzzy on how to do what I need to do.
My main code for controlling the valves, getting user input, etc. is in C.
I need to call a procedure in C that reads sensors. I will pass this
procedure the number of milliseconds it sho
Mark ,
It is working with the updated OS. Thanks so much!
Now I will explore how to get the simple timing that I need using the PRU.
On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
> Mark,
>
> With the current OS there isn't a /dev/remoteproc even.
>
> I'm going
Mark,
With the current OS there isn't a /dev/remoteproc even.
I'm going to try the updated OS build this morning.
Walter
On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
> I fired up the Beagle at home it the PRU works out of the box.
>
> What do you get running
>
On Wed, 17 Feb 2021 10:45:49 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Walter Cromer
wrote:
>You are correct that this application does not need to know the actual real
>time but only the relative (elapsed) time since the subroutine began. I'm
>familiar with clock_gettime but didn't
I fired up the Beagle at home it the PRU works out of the box.
What do you get running
*ls /dev/remoteproc*
I get:
*ls -ls /dev/remoteproc*
total 0
0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 ->
/sys/class/remoteproc/remoteproc1
0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 ->
/
I'll get this one onto an SD card and give it a try. If I can just get
this configured I think I can make quick work of this problem!
On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
> Good point, it should work I'm running a newer test image[1], but I
> took my
Good point, it should work I'm running a newer test image[1], but I
took my Beagle home so I can't do a quick check on it until later.
--Mark
[1]https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
On Wednesday, February 17, 2021
I asked because the ones on the page @ the link are older than the one I
have installed.
On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
> On newer versions of the SD card image /var/lib/cloud9 is a git repo which
> you can do a git pull to update. Your version is too
So you are saying that this version is too old?
Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT *Tue Aug 25
01:48:39 UTC 2020* armv7l GNU/Linux
On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
> On newer versions of the SD card image /var/lib/cloud9 is a git re
On newer versions of the SD card image /var/lib/cloud9 is a git repo which
you can do a git pull to update. Your version is too old.
Follow the instructions
at:
https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
to download and install an updat
Mark,
git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or any
of the parent directories): .git
I'm such a neophyte on git. What do I need to do?
And, what do you mean by updating to a new version of the SD card? The OS
is booting from the SD card and the version.sh infor
I suggest updating to a new version of the SD card. It looks like the PRUs
are getting started at boot time, but the path isn't setup right. I think
we setup some links so the path* /dev/remoteproc/pruss-core0/state *points
to the right place.
You could also try:
*cd */var/lib/cloud9
*git* pu
Mark,
I got the latest PRUCookbook downloaded and when trying to make the
hello.pru0.c program in 1.6, I got this error.
*debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make
TARGET=hello.pru0*
*/var/lib/cloud9/common/Makefile:29:
MODEL=TI_AM335x_BeagleBone_Black,TARGET=hel
You are correct that this application does not need to know the actual real
time but only the relative (elapsed) time since the subroutine began. I'm
familiar with clock_gettime but didn't think it could give me subsecond
information. I'll explore it!
Thanks,!
Walter
On Wednesday, February
Hi Walter,
I don't think you need an RTC for relative time. clock_gettime should do
the job (https://linux.die.net/man/3/clock_gettime)
There are also more intuitive ways to manipulate timespec structs in the
RCL (http://strawsondesign.com/docs/librobotcontrol/group__time.html).
Best,
Michele
On
I really don't need ns. The valve 'on time' is going to be in the range of
500 ms to 2 seconds probably.
I will review the PRUCookbook! Thanks!
Walter
On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:
> The PRUs can give you 10's of ns timing, which is more than good
The PRUs can give you 10's of ns timing, which is more than good enough for
milliseconds, but might be over kill.
I'd think using C on the ARM processor should be fast enough. I'd use
gpiod[1].
If you really want the ns timing of the PRUs, check out the PRU Cookbook[2]
--Mark
[1] https://git
Depending on how precise you need to be, I would go for the PRU-ICSS. They
can control the GPIOs pretty easily.
Le mardi 16 février 2021 à 10:03:47 UTC-5, wal...@edenconceptsllc.com a
écrit :
> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP
> PREEMPT Fri May 24 22:12:3
29 matches
Mail list logo
