Re: [beagleboard] Autorun Python Script can't write files

[Steve Lentz]

Dennis:

Thanks for this, I had to increase the hold off to 60 seconds but that’s fine 
for my purposes.  

I discovered that sudo systemctl status cron gives good output for debugging.

While troubleshooting, I made my script executable with chmod 777 autotest.py 
although I’m not certain this was necessary.

-Steve



> On Apr 16, 2021, at 3:28 PM, Dennis Lee Bieber  
> wrote:
> 
> On Fri, 16 Apr 2021 09:01:33 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user
> "stl...-re5jqeeqqe8avxtiumw...@public.gmane.org"
>  wrote:
> 
>> I want my autorun python script to write information into a text file. 
>> This works fine when the python file is run from the Cloud9 interface, but 
>> does not run properly when the beagleboard restarted.  
>> 
>> The command that is failing is:
>> 
>> with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
>>  f.write("bbb autorun test\n")
>> 
>> I am running Buster IoT Image 2020-04-06 on a beagle board black.
>> 
>> I have tried using chmod 666, chmod 755 etc, on the target file and 
>> enclosing directory with no success.
>> 
>> I see a number of older threads about using chron, but these don't seem 
>> applicable in light of having autorun.
>> 
>> Any idea what is preventing this script from writing to a file when it is 
>> autorun?  Is this a permissions issue and how would I change that?
> 
>   I have no idea what systemd does when starting Cloud9 and processing
> its "autorun" directory...
> 
>   Personally, I would move your file /out of/ Cloud9 into some location
> in your home directory...
> 
> {in Cloud9}
> debian@beaglebone:/var/lib/cloud9$ mv autorun/autotest.py ~
> 
> ... and then add it to that user's crontab...
> 
> {rest is all via SSH using PuTTY}
> debian@beaglebone:~$ crontab -e
> no crontab for debian - using an empty one
> 
> Select an editor.  To change later, run 'select-editor'.
>  1. /usr/bin/vim.nox
>  2. /bin/nano< easiest
>  3. /usr/bin/vim.basic
>  4. /usr/bin/vim.tiny
>  5. /bin/nano-tiny
> 
> Choose 1-5 [2]: 3
> crontab: installing new crontab
> 
> {the vim session is not shown} 
> 
>   Locating the actual crontab file...
> 
> debian@beaglebone:~$ sudo cat /var/spool/cron/crontabs/debian
> # DO NOT EDIT THIS FILE - edit the master and reinstall.
> # (/tmp/crontab.Wesos5/crontab installed on Fri Apr 16 15:00:39 2021)
> # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
> # Edit this file to introduce tasks to be run by cron.
> #
> # Each task to run has to be defined through a single line
> # indicating with different fields when the task will be run
> # and what command to run for the task
> #
> # To define the time you can provide concrete values for
> # minute (m), hour (h), day of month (dom), month (mon),
> # and day of week (dow) or use '*' in these fields (for 'any').
> #
> # Notice that tasks will be started based on the cron's system
> # daemon's notion of time and timezones.
> #
> # Output of the crontab jobs (including errors) is sent through
> # email to the user the crontab file belongs to (unless redirected).
> #
> # For example, you can run a backup of all your user accounts
> # at 5 a.m every week with:
> # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
> #
> # For more information see the manual pages of crontab(5) and cron(8)
> #
> # m h  dom mon dow   command
> @reboot sleep 30 && /home/debian/autotest.py
>> /home/debian/logs/unexpected.log  2>&1
> 
> debian@beaglebone:~$
>   Note: the crontab operation wrapped, the redirection is part of the
> @reboot line.
> 
>   I found I had to put in the 30 second delay to allow the system time to
> set up the GPIOs, without the job failed on 
> 
> GPIO.setup(relay3, GPIO.OUT)
> 
> with a missing file or permission error.
> 
>   I ended on 30 seconds as that is where dmesg had a major break...
> 
> [   25.949286] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
> [   26.184613] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
> [   66.991145] remoteproc remoteproc0: wkup_m3 is available
> [   67.376203] remoteproc remoteproc0: powering up wkup_m3
> 
> 
> 
> -- 
> 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/k4mj7g99ck3j9l01upctmbtuj500b3afoh%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 

[beagleboard] Need armhf java 8

[maxmike]

It looks like the Oracle download page for this archive version is under 
repairs (for who knows how long)
does anybody have a copy of jdk-8u191-linux-arm32-vfp-hflt.tar.gz  ? Please?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/47f1794d-d941-4974-89e9-41bbff5b3b0an%40googlegroups.com.

Re: [beagleboard] versioning beaglebone images with OSTree

[Robert Nelson]

On Fri, Apr 16, 2021 at 4:19 PM John Allwine  wrote:
>
> I'd like to start a discussion about creating complete Beaglebone images that 
> leverage OSTree to be able to atomically update the system as a whole. The 
> scripts in https://github.com/beagleboard/image-builder generate complete 
> images for the Beaglebone that include specific kernel, apt packages, boot 
> settings, git repositories, etc. Updating a deployed Beaglebone without 
> reflashing a new image involves piecemeal updating of those various 
> components. Improperly updating can leave the system in a broken state and 
> can be difficult to get back into a good state. It would be great to be able 
> to leverage those image-builder scripts to construct the rootfs, add that 
> tree as a commit to an OSTree repository and properly configured Beaglebones 
> could download that commit and atomically switch to it to update the whole 
> system while preserving portions of the system such as home directories and 
> other key directories (/etc, /var?). If something did break, rolling back is 
> easy as well.
>
> Configuring a Beaglebone this way would make most of the system read-only so 
> using apt-get to install new packages wouldn't work without altering its 
> implementation, but that seems like a worthy trade off. This would be for 
> someone who has a Beaglebone with an out-of-the-box image and some 
> scripts/servers set up in their home directory who doesn't want to worry too 
> much about the system as a whole, but wants to be able to easily update it 
> without reflashing or doing piecemeal updates. People who develop software 
> for Beaglebones in their customers' devices could host their own OSTree 
> repository and make their own modifications to the image-builder scripts if 
> they have their own set of system dependencies (this is what I'd like to do).
>
> Does anyone else think this would be useful? Is there anyone with the 
> expertise to know what details would need to be taken into account to make 
> this work properly?
>
> OSTree documentation is here: https://ostreedev.github.io/ostree/
> It lists a number of examples of it being used in various Linux distributions.

I remember seeing one of Peter Robinson's demo of Fedora IoT a few
years back at ELC, that used OSTree+btrfs. It worked pretty well.  At
that time, I made sure btrfs worked well for us, to possibly look down
that road.  My biggest issue, the 4gb eMMC, was too limited for the
out of box images to do something like that.  For an iot/console image
the idea would still work well..   While working on bullseye images
this week, i noticed we still have the "--no-merged-usr" flag for
debootstrap, we should try with that removed in 'bullseye', as ostree
needs that..

We did have ostree installed on the lxqt images:

https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-buster-lxqt-v5.4.conf#L138

--no-merged-usr (due to bugs in stretch/buster..)
https://github.com/beagleboard/image-builder/blob/master/scripts/debootstrap.sh#L138

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/CAOCHtYgHJiESN2df7jVbUErSwL5mcoPva-woQXR91t%3D0nCJJDQ%40mail.gmail.com.

[beagleboard] versioning beaglebone images with OSTree

[John Allwine]

I'd like to start a discussion about creating complete Beaglebone images 
that leverage OSTree to be able to atomically update the system as a whole. 
The scripts in https://github.com/beagleboard/image-builder generate 
complete images for the Beaglebone that include specific kernel, apt 
packages, boot settings, git repositories, etc. Updating a deployed 
Beaglebone without reflashing a new image involves piecemeal updating of 
those various components. Improperly updating can leave the system in a 
broken state and can be difficult to get back into a good state. It would 
be great to be able to leverage those image-builder scripts to construct 
the rootfs, add that tree as a commit to an OSTree repository and properly 
configured Beaglebones could download that commit and atomically switch to 
it to update the whole system while preserving portions of the system such 
as home directories and other key directories (/etc, /var?). If something 
did break, rolling back is easy as well.
 
Configuring a Beaglebone this way would make most of the system read-only 
so using apt-get to install new packages wouldn't work without altering its 
implementation, but that seems like a worthy trade off. This would be for 
someone who has a Beaglebone with an out-of-the-box image and some 
scripts/servers set up in their home directory who doesn't want to worry 
too much about the system as a whole, but wants to be able to easily update 
it without reflashing or doing piecemeal updates. People who develop 
software for Beaglebones in their customers' devices could host their own 
OSTree repository and make their own modifications to the image-builder 
scripts if they have their own set of system dependencies (this is what I'd 
like to do).

Does anyone else think this would be useful? Is there anyone with the 
expertise to know what details would need to be taken into account to make 
this work properly?

OSTree documentation is here: https://ostreedev.github.io/ostree/
It lists a number of examples of it being used in various Linux 
distributions.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/a7e71161-0114-403b-b5e2-1895cc14b9ecn%40googlegroups.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Dennis - It was just an example that, for me, made it clearer to me the 
relationship between A/D channels and steps.  This isn't something we're 
doing in this application.

WC

On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote:

> On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
>
> >So if I had an application that had a sensor A that needs to be read 
> every 
> >10ms and sensor B that only needs to be read every minute, I could wire 
> >channel 1 to sensor A and assign it to step 1 and wire channel 2 to 
> sensor 
> >B and assign it to step 2. 
> >
> >Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> >but not 3-16. This saves time on the read as channels 3-7 aren't needed 
> >and steps 3-16 aren't needed so I don't use them. Then after the initial 
> >read when I don't need to read sensor B until a minute passes, I can 
> change 
> >STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only 
> >sensor A would be read. Then at one minute intervals, I change STEPENABLE 
> >so steps 1 & 2 are enabled and when read is triggered, sensors A and B 
> are 
> >read. 
> >
>
> Seems like a lot of fiddling around with step enables, and assumes ADC
> reading is a one-shot operation. I'd likely just create a process loop with
> major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
> you increment after every read), and read both sources each time -- but
> only report the one-minute source at top of major frame; counter at 6
> if my calculations are right).
>
> The ADC configurations supports continuous mode in which, after all
> enabled steps are processed, it loops back to the top and restarts the step
> sequence. Note:
>
> "
> 12.3.4 One-Shot (Single) or Continuous Mode
>
> When the sequencer finishes cycling through all the enabled steps, the
> user can decide if the sequencer should stop (one-shot), or loop back and
> schedule the step again (continuous).
>
> If one-shot mode is selected, the sequencer will take care of disabling
> the step enable bit after the conversion. If continuous mode is selected,
> it is the software’s responsibility to turn off the step enable bit.
> "
> ... if doing one-shot, you don't have to turn off the second step enable...
> You have to, instead, turn ON the steps you want active before doing the
> reads -- every time.
>
> Also pertinent -- as soon as any step is enabled, the ADC goes out of
> IDLE to handle enabled steps. There is a master Enable in the CTRL register
> -- to synchronize the reads, you'd likely have to set it to 0, program the
> steps, then set it to 1 to start the ADC. 
>
>
>
>
> -- 
> 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/b2cf59f7-435c-4f35-a765-d959193ec798n%40googlegroups.com.

Re: [beagleboard] What is the difference between flasher and microSD images?

[eb]

Thank you for the clarification. I successfully flashed to the eMMC, 
mounted a FAT32 SD card, and everything works great.

On Friday, April 16, 2021 at 2:13:39 PM UTC-4 RobertCNelson wrote:

> On Wed, Apr 14, 2021 at 11:23 PM eb  wrote:
> >
> > I'm having trouble finding information on the difference between the 
> flasher and microSD images. Why can an image made for microSD not be 
> flashed to eMMC?
> >
> > The reason I'm asking is because the Debian 9.12 ImgTec image is only 
> available as "microSD", but I want to run this version from eMMC for 
> performance and reliability reasons. I also want to mount a microSD as a 
> different mount point for writing files. If I flash this image to eMMC, 
> will I run into issues? If yes, is there a way to "modify" the microSD 
> version to work with eMMC?
>
> There should not be any 'big' issues, i assumed most customer projects
> with 'qt' etc might run out of space on the eMMC..
>
> 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/0b952ea0-4a9f-47a3-b1e1-511e340a0eccn%40googlegroups.com.

[beagleboard] Re: Autorun Python Script can't write files

[Dennis Lee Bieber]

On Fri, 16 Apr 2021 09:01:33 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"stl...-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:

>I want my autorun python script to write information into a text file. 
> This works fine when the python file is run from the Cloud9 interface, but 
>does not run properly when the beagleboard restarted.  
>
>The command that is failing is:
>
>with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
>   f.write("bbb autorun test\n")
>
>I am running Buster IoT Image 2020-04-06 on a beagle board black.
>
>I have tried using chmod 666, chmod 755 etc, on the target file and 
>enclosing directory with no success.
>
>I see a number of older threads about using chron, but these don't seem 
>applicable in light of having autorun.
>
>Any idea what is preventing this script from writing to a file when it is 
>autorun?  Is this a permissions issue and how would I change that?

I have no idea what systemd does when starting Cloud9 and processing
its "autorun" directory...

Personally, I would move your file /out of/ Cloud9 into some location
in your home directory...

{in Cloud9}
debian@beaglebone:/var/lib/cloud9$ mv autorun/autotest.py ~

... and then add it to that user's crontab...

{rest is all via SSH using PuTTY}
debian@beaglebone:~$ crontab -e
no crontab for debian - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /usr/bin/vim.nox
  2. /bin/nano< easiest
  3. /usr/bin/vim.basic
  4. /usr/bin/vim.tiny
  5. /bin/nano-tiny

Choose 1-5 [2]: 3
crontab: installing new crontab

{the vim session is not shown} 

Locating the actual crontab file...

debian@beaglebone:~$ sudo cat /var/spool/cron/crontabs/debian
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.Wesos5/crontab installed on Fri Apr 16 15:00:39 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
@reboot sleep 30 && /home/debian/autotest.py
>/home/debian/logs/unexpected.log  2>&1

debian@beaglebone:~$
Note: the crontab operation wrapped, the redirection is part of the
@reboot line.

I found I had to put in the 30 second delay to allow the system time to
set up the GPIOs, without the job failed on 

GPIO.setup(relay3, GPIO.OUT)

with a missing file or permission error.

I ended on 30 seconds as that is where dmesg had a major break...

[   25.949286] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   26.184613] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   66.991145] remoteproc remoteproc0: wkup_m3 is available
[   67.376203] remoteproc remoteproc0: powering up wkup_m3



-- 
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/k4mj7g99ck3j9l01upctmbtuj500b3afoh%404ax.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[jeff....@gmail.com]

Ok thank you sir!! (but I probably am still losing my mind :-) )  

The daily emails (and Mark's email) gets us to the latest posts in the 
meantime.. 

On Friday, April 16, 2021 at 2:59:39 PM UTC-4 RobertCNelson wrote:

> On Fri, Apr 16, 2021 at 1:40 PM jeff@gmail.com
>  wrote:
> >
> > Really interesting post!!
> >
> > But I can't seem to find this thread on the new Beaglebone forums 
> webpage over here: https://forum.beagleboard.org/
> >
> > Am I missing something or just loosing my mind?
>
> No, the last sync of the classic BeagleBoard group ran 18 days ago.
> Jason is still Beta Testing the other smaller "Beagle" community
> sections before the main channel get's fully enabled.. Give it a few
> more weeks. ;)
>
> 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/95465fd9-bcfc-45cc-b946-a68a015d3bacn%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Robert Nelson]

On Fri, Apr 16, 2021 at 1:40 PM jeff@gmail.com
 wrote:
>
> Really interesting post!!
>
> But I can't seem to find this thread on the new Beaglebone forums webpage 
> over here: https://forum.beagleboard.org/
>
> Am I missing something or just loosing my mind?

No, the last sync of the classic BeagleBoard group ran 18 days ago.
Jason is still Beta Testing the other smaller "Beagle" community
sections before the main channel get's fully enabled..  Give it a few
more weeks. ;)

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/CAOCHtYh%2BJRnp73myKXbC6z6E6vUzA9x-u_%2BSeiv3y6U9_bNJdg%40mail.gmail.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

['Mark Lazarewicz' via BeagleBoard]

 Sorry Chrome browser on windows this works for me 
https://groups.google.com/g/beagleboard/c/-WlvGEaqrKU/m/EatslVHvCwAJ



On Friday, April 16, 2021, 01:51:00 PM CDT, 'Mark Lazarewicz' via 
BeagleBoard  wrote:  
 
 Hi Jeff
I have it open on my PC in gmail I'll send you a link to your personal email. 
Strange stuff going on in my Yahoo client. And searching the group on Google 
group's took me a few tries to find this so no your not crazy Jeff. Key words 
seem important I'd imagine this group's archive is huge. Give me 5 minutes and 
check your email. I'm at the point where I can't offer much help without doing 
some actual work with CCS and JTAG mainly as a refresher for myself 
Cheers
Mark


Sent from Yahoo Mail on Android 
 
  On Fri, Apr 16, 2021 at 1:40 PM, jeff@gmail.com 
wrote:   Really interesting post!!  
But I can't seem to find this thread on the new Beaglebone forums webpage over 
here: https://forum.beagleboard.org/
Am I missing something or just loosing my mind?

On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote:

On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>So if I had an application that had a sensor A that needs to be read every 
>10ms and sensor B that only needs to be read every minute, I could wire 
>channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
>B and assign it to step 2. 
>
>Then at startup, when I want to read both sensors, I enable steps 1 and 2 
>but not 3-16. This saves time on the read as channels 3-7 aren't needed 
>and steps 3-16 aren't needed so I don't use them. Then after the initial 
>read when I don't need to read sensor B until a minute passes, I can change 
>STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only 
>sensor A would be read. Then at one minute intervals, I change STEPENABLE 
>so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
>read. 
>

 Seems like a lot of fiddling around with step enables, and assumes ADC
reading is a one-shot operation. I'd likely just create a process loop with
major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
you increment after every read), and read both sources each time -- but
only report the one-minute source at top of major frame; counter at 6
if my calculations are right).

 The ADC configurations supports continuous mode in which, after all
enabled steps are processed, it loops back to the top and restarts the step
sequence. Note:

"
12.3.4 One-Shot (Single) or Continuous Mode

 When the sequencer finishes cycling through all the enabled steps, the
user can decide if the sequencer should stop (one-shot), or loop back and
schedule the step again (continuous).

 If one-shot mode is selected, the sequencer will take care of disabling
the step enable bit after the conversion. If continuous mode is selected,
it is the software’s responsibility to turn off the step enable bit.
"
... if doing one-shot, you don't have to turn off the second step enable...
You have to, instead, turn ON the steps you want active before doing the
reads -- every time.

 Also pertinent -- as soon as any step is enabled, the ADC goes out of
IDLE to handle enabled steps. There is a master Enable in the CTRL register
-- to synchronize the reads, you'd likely have to set it to 0, program the
steps, then set it to 1 to start the ADC. 




-- 
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/4c5b55c6-c1be-4c39-adbe-ff2a6339ffc0n%40googlegroups.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/375946152.1674261.1618599048305%40mail.yahoo.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/1137219829.1685121.1618599543253%40mail.yahoo.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

['Mark Lazarewicz' via BeagleBoard]

Hi Jeff
I have it open on my PC in gmail I'll send you a link to your personal email. 
Strange stuff going on in my Yahoo client. And searching the group on Google 
group's took me a few tries to find this so no your not crazy Jeff. Key words 
seem important I'd imagine this group's archive is huge. Give me 5 minutes and 
check your email. I'm at the point where I can't offer much help without doing 
some actual work with CCS and JTAG mainly as a refresher for myself 
Cheers
Mark


Sent from Yahoo Mail on Android 
 
  On Fri, Apr 16, 2021 at 1:40 PM, jeff@gmail.com 
wrote:   Really interesting post!!  
But I can't seem to find this thread on the new Beaglebone forums webpage over 
here: https://forum.beagleboard.org/
Am I missing something or just loosing my mind?

On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote:

On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>So if I had an application that had a sensor A that needs to be read every 
>10ms and sensor B that only needs to be read every minute, I could wire 
>channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
>B and assign it to step 2. 
>
>Then at startup, when I want to read both sensors, I enable steps 1 and 2 
>but not 3-16. This saves time on the read as channels 3-7 aren't needed 
>and steps 3-16 aren't needed so I don't use them. Then after the initial 
>read when I don't need to read sensor B until a minute passes, I can change 
>STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only 
>sensor A would be read. Then at one minute intervals, I change STEPENABLE 
>so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
>read. 
>

 Seems like a lot of fiddling around with step enables, and assumes ADC
reading is a one-shot operation. I'd likely just create a process loop with
major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
you increment after every read), and read both sources each time -- but
only report the one-minute source at top of major frame; counter at 6
if my calculations are right).

 The ADC configurations supports continuous mode in which, after all
enabled steps are processed, it loops back to the top and restarts the step
sequence. Note:

"
12.3.4 One-Shot (Single) or Continuous Mode

 When the sequencer finishes cycling through all the enabled steps, the
user can decide if the sequencer should stop (one-shot), or loop back and
schedule the step again (continuous).

 If one-shot mode is selected, the sequencer will take care of disabling
the step enable bit after the conversion. If continuous mode is selected,
it is the software’s responsibility to turn off the step enable bit.
"
... if doing one-shot, you don't have to turn off the second step enable...
You have to, instead, turn ON the steps you want active before doing the
reads -- every time.

 Also pertinent -- as soon as any step is enabled, the ADC goes out of
IDLE to handle enabled steps. There is a master Enable in the CTRL register
-- to synchronize the reads, you'd likely have to set it to 0, program the
steps, then set it to 1 to start the ADC. 




-- 
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/4c5b55c6-c1be-4c39-adbe-ff2a6339ffc0n%40googlegroups.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/375946152.1674261.1618599048305%40mail.yahoo.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[jeff....@gmail.com]

Really interesting post!!  

But I can't seem to find this thread on the new Beaglebone forums webpage 
over here: https://forum.beagleboard.org/

Am I missing something or just loosing my mind?

On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote:

> On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
>
> >So if I had an application that had a sensor A that needs to be read 
> every 
> >10ms and sensor B that only needs to be read every minute, I could wire 
> >channel 1 to sensor A and assign it to step 1 and wire channel 2 to 
> sensor 
> >B and assign it to step 2. 
> >
> >Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> >but not 3-16. This saves time on the read as channels 3-7 aren't needed 
> >and steps 3-16 aren't needed so I don't use them. Then after the initial 
> >read when I don't need to read sensor B until a minute passes, I can 
> change 
> >STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only 
> >sensor A would be read. Then at one minute intervals, I change STEPENABLE 
> >so steps 1 & 2 are enabled and when read is triggered, sensors A and B 
> are 
> >read. 
> >
>
> Seems like a lot of fiddling around with step enables, and assumes ADC
> reading is a one-shot operation. I'd likely just create a process loop with
> major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
> you increment after every read), and read both sources each time -- but
> only report the one-minute source at top of major frame; counter at 6
> if my calculations are right).
>
> The ADC configurations supports continuous mode in which, after all
> enabled steps are processed, it loops back to the top and restarts the step
> sequence. Note:
>
> "
> 12.3.4 One-Shot (Single) or Continuous Mode
>
> When the sequencer finishes cycling through all the enabled steps, the
> user can decide if the sequencer should stop (one-shot), or loop back and
> schedule the step again (continuous).
>
> If one-shot mode is selected, the sequencer will take care of disabling
> the step enable bit after the conversion. If continuous mode is selected,
> it is the software’s responsibility to turn off the step enable bit.
> "
> ... if doing one-shot, you don't have to turn off the second step enable...
> You have to, instead, turn ON the steps you want active before doing the
> reads -- every time.
>
> Also pertinent -- as soon as any step is enabled, the ADC goes out of
> IDLE to handle enabled steps. There is a master Enable in the CTRL register
> -- to synchronize the reads, you'd likely have to set it to 0, program the
> steps, then set it to 1 to start the ADC. 
>
>
>
>
> -- 
> 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/4c5b55c6-c1be-4c39-adbe-ff2a6339ffc0n%40googlegroups.com.

Re: [beagleboard] What is the difference between flasher and microSD images?

[Robert Nelson]

On Wed, Apr 14, 2021 at 11:23 PM eb  wrote:
>
> I'm having trouble finding information on the difference between the flasher 
> and microSD images. Why can an image made for microSD not be flashed to eMMC?
>
> The reason I'm asking is because the Debian 9.12 ImgTec image is only 
> available as "microSD", but I want to run this version from eMMC for 
> performance and reliability reasons. I also want to mount a microSD as a 
> different mount point for writing files. If I flash this image to eMMC, will 
> I run into issues? If yes, is there a way to "modify" the microSD version to 
> work with eMMC?

There should not be any 'big' issues, i assumed most customer projects
with 'qt' etc might run out of space on the eMMC..

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/CAOCHtYjK-KVBEGGAK4t0U5tfz0Xqfod33FGV45ah7NAWRLkEqg%40mail.gmail.com.

[beagleboard] Re: What is the difference between flasher and microSD images?

[Dennis Lee Bieber]

On Wed, 14 Apr 2021 21:23:16 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user eb
 wrote:


>I'm having trouble finding information on the difference between the 
>flasher and microSD images. Why can an image made for microSD not be 
>flashed to eMMC?
>
The difference is one line at the bottom of /boot/uEnv.txt

If you uncomment the line, the card becomes a flasher image (and if you
don't remove it after the flashing, rebooting will repeat flashing...).


-- 
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/t3jj7g5rbjiko507uopddstrfchl8sitvr%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>So if I had an application that had a sensor A that needs to be read every 
>10ms and sensor B that only needs to be read every minute, I could wire 
>channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
>B and assign it to step 2. 
>
>Then at startup, when I want to read both sensors, I enable steps 1 and 2 
>but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
>and steps 3-16 aren't needed so I don't use them.  Then after the initial 
>read when I don't need to read sensor B until a minute passes, I can change 
>STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
>sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
>so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
>read. 
>

Seems like a lot of fiddling around with step enables, and assumes ADC
reading is a one-shot operation. I'd likely just create a process loop with
major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
you increment after every read), and read both sources each time -- but
only report the one-minute source at top of major frame; counter at 6
if my calculations are right).

The ADC configurations supports continuous mode in which, after all
enabled steps are processed, it loops back to the top and restarts the step
sequence. Note:

"
12.3.4 One-Shot (Single) or Continuous Mode

When the sequencer finishes cycling through all the enabled steps, the
user can decide if the sequencer should stop (one-shot), or loop back and
schedule the step again (continuous).

If one-shot mode is selected, the sequencer will take care of disabling
the step enable bit after the conversion. If continuous mode is selected,
it is the software’s responsibility to turn off the step enable bit.
"
... if doing one-shot, you don't have to turn off the second step enable...
You have to, instead, turn ON the steps you want active before doing the
reads -- every time.

Also pertinent -- as soon as any step is enabled, the ADC goes out of
IDLE to handle enabled steps. There is a master Enable in the CTRL register
-- to synchronize the reads, you'd likely have to set it to 0, program the
steps, then set it to 1 to start the ADC. 




-- 
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/69hj7g140e9n0vp111gpr7tiltonan0c41%404ax.com.

[beagleboard] Autorun Python Script can't write files

[stl...@gmail.com]

I want my autorun python script to write information into a text file. 
 This works fine when the python file is run from the Cloud9 interface, but 
does not run properly when the beagleboard restarted.  

The command that is failing is:

with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
   f.write("bbb autorun test\n")

I am running Buster IoT Image 2020-04-06 on a beagle board black.

I have tried using chmod 666, chmod 755 etc, on the target file and 
enclosing directory with no success.

I see a number of older threads about using chron, but these don't seem 
applicable in light of having autorun.

Any idea what is preventing this script from writing to a file when it is 
autorun?  Is this a permissions issue and how would I change that?

Here's the whole file if it helps.  Again, this runs in its entirety from 
Cloud9.  When it is in the autostart folder and the BBB is restarted, it 
goes no further than turning on relay3.

Thanks in advance,
-Steve Lentz

#!/usr/bin/python3
#//
#
#   autorun test
# 
#//
# 
#
import Adafruit_BBIO.GPIO as GPIO
import time

relay3 = "P9_30"
relay4 = "P9_27"
GPIO.setup(relay3, GPIO.OUT)
GPIO.setup(relay4, GPIO.OUT)

GPIO.output(relay3, GPIO.HIGH)

with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
   f.write("bbb autorun test\n")

GPIO.output(relay4, GPIO.HIGH)
time.sleep(30)
GPIO.output(relay4, GPIO.LOW)
time.sleep(1)
GPIO.output(relay3, GPIO.LOW)

exit()

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/9d67ea91-542d-46fc-b961-cbb9bd736a5dn%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Mark Lazarewicz]

I spent most of yesterday reading TI's documentation and the Beaglebone 
Black SRM in detail and believe I have a much better handle on how this 
works now.  
My plan is to allocate memory space in pru0's RAM for the data storage and 
then have an ARM program read it from there

Thanks for link
Ignore my question about missing posts its my Android Tablet from Samsung 
email client 

That SRM doesn't talk about "allocate memory space in pru0's RAM for the 
data storage and then have an ARM program read it from there"
Did you read something that describes doing this? 

Also that SRM says TI doesn't support PRU rather wierd. 
Your statement lead my to believe some TI docs gave you an *epiphany* can 
you explain?
If there are any docs like this in my experience they come from E2E not 
.org Ive got several boards at home and a jtag and a fresh ccs install I 
plan on revisting this soon

Thx 

Mark


On Thursday, April 15, 2021 at 9:13:19 AM UTC-5 wal...@edenconceptsllc.com 
wrote:

> I think this is a better version.   Than what I posted a few minutes ago ( 
> Ideleted that post).
>
>
> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
>
>
>
> On Thursday, April 15, 2021 at 9:55:41 AM UTC-4 lazarman wrote:
>
>> Beaglebone Black SRM
>>
>> Have not seen this can you share a link
>>
>> Thanks
>>
>> Mark
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer
>>  wrote:
>>
>> I'm sticking with remoteproc for now.  I spent most of yesterday reading 
>> TI's documentation and the Beaglebone Black SRM in detail and believe I 
>> have a much better handle on how this works now.  
>> My plan is to allocate memory space in pru0's RAM for the data storage 
>> and then have an ARM program read it from there.Our production solution 
>> does not need to share this data with the ARM side.  We only need this 
>> during R so I'm not worried about the two sides clobbering each other on 
>> the production system.
>>
>> But, now, of course, nothing that used to work is working!  I had started 
>> out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.  
>> dmesg shows the PRU starting and stopping and the firmware file in 
>> /lib/firmware is new based on ls -l output so I'm fairly certain that the 
>> code got compiled and copied over to the right directory.  The PRUCookbook 
>> example that blinks USR3 works and I can change the blinking frequency and 
>> change it to blink USR2 instead and all that works.  But the example to 
>> blink P9_11 won't and neither will another one to blink P9_27.   The only 
>> thing I know I changed is that the PRUCookbook directories were all owned 
>> by root and group root.  They weren't originally like that but got changed 
>> somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to 
>> change them so Debian could edit files in those directories.  I wouldn't 
>> think this would matter since all the real remoteproc action happens in 
>> other directories.  
>>
>> I also started working with CCS some and trying to get it going.  
>>  Somewhere along the way, something deleted all the files and folders in my 
>> local WIndows machine's Documents folder.  I'm running anti-virus and 
>> anti-malware on the WIndows box.
>>
>> Just when I thought I was going to start really moving forward!!!
>>
>> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>>
>> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>>
>> I thought he had an unacceptable delay reading ADC from ARM?
>> Just trying to understand how libpruio fixes this and if it did why even 
>> bother with PRU?
>>
>>
>> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to 
>> a ring buffer. The ARM can read/evaluate the data later.
>>
>> @Walter
>> Inspired by lazarman, just another thought: perhaps you don't need a PRU 
>> mainloop at all. Perhaps you can meet your needs by ARM code using the 
>> libpruio trigger features in MM mode.
>>
>>1. Configure your trigger event (up to four events can get chained 
>>up).
>>2. Open valves.
>>3. Start MM mode, synchronously waiting for trigger.
>>4. Close valves.
>>5. ?Perhaps evaluate pre-trigger values?
>>6. Repeat from step 2.
>>
>> -- 
>>
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>>
>>
>> https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com
>>  
>> 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

['Mark Lazarewicz' via BeagleBoard]

 Hello Walter
I think so nice novel approach. Since the 2nd PRU is started manualy from 
command line in Linux you shouldnt get clobbered as thats what that memory is 
for the PRU code and Resource Tables from my reading. Id guess address  
translation is required.  shared RAM could be used as well I know that works 
thinks are much simpler when ARM is in supervisor mode no userland but I 
digress.I saw your latest post I think that issue has come up before maybe 
search the group I might be wrong maybe poke around in the OCP dir see whats 
there. How these directories get created should be documented perhaps in some 
Linux readme none of this tribal knowledge exists in barebone arm its straight 
C code muxing. Searching E2E I saw a thread blaming Linux for CCS/JTAG issues 
on PRU theres definately many angry confused users out there I appreciate the 
difficulty in supporting a complex chip but sorting all this can be daunting. I 
installed CCCS 10 Win10 for a TI simple Link radio project and Im seeing grayed 
out feature Id rather avoid CCS on Linux. I've installed CCS on at least a 
dozen projects on windows never had issues I am still confused as at one point 
some  features and Processors were not free. These wikis in the past have been 
very helpful I see some migration going on with that documentation a bit scary. 
Lastly I found some PRU examples digging in E2E  Im more apt to start with 
those vs cookbook they mention CCS6. If I delve into Linux/PRU it would be the 
RPMsg examples and I have a sneaky hunch the command line build example may 
work fine using sdk linux but from past experience the CCS/JTAG require xml and 
gel files to hold the ARM core off and do muxing and low level setup of memory.
Hopefully I can share something useful. Does Cookbook have RPMsg examples? 


Mark
On Friday, April 16, 2021, 07:49:22 AM CDT, Walter Cromer 
 wrote:  
 
 As I get a better understanding and experience this may change, but right now 
I don't think it can handle the volume of data we need to move between systems. 
 And, that volume is only needed during R  The production system will not 
need to keep that data.
So, my plan is to instance arrays on the ARM side and use RPMSG to pass the 
addresses to the PRU.  The PRU code will translate that to ARM addresses.   As 
the data is collected it will be stored in arrays local to the PRUs (in the 8k 
or 12k memory spaces).  When the time-sensitive data collection is completed, 
the PRU array will contain the data.  Then we'll just copy it over the ARM 
addresses.
My assumption is that since the ARM instances the arrays in memory, Linux will 
not overwrite those locations so they'll be 'safe'.  I'll probably use RPMSG to 
alert ARM that the data is going to be transferred and wait on an 'ack' from 
the ARM before copying it over. 
Seems like it should work.


On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote:

Hello TJF
Looks very powerful and code is very generic and well thought out. I thought 
you couldn't code?藍
I'm on tablet forgive my laziness where are the ADC examples located in c 
language if possible 
Looks like you support multiple languages nice.

I'm guessing  below reference you mentioned is the am335x TRM or are you 
referring to the ARM intellectual property for ADC?
It's also possible to directly write to the step configuration in AdcSet::St_p 
by writing to the member variables Confg and Delay. See ARM Reference Guide, 
chapter 12 for details on ADC configurations.
Thanks. Did you write this library? It's quite a bit to wrap ones mind around. 
How long dis this take to develop. 
I've got a basic  understanding of how RPMSG works I'd like to understand how 
libpruio handles the data exchange. 
I'm wondering why Walter isn't using RPMSG  he's talking about using the other 
unused  PRU memory to store data and have ARM read it. I'm trying to see if 
that's doable for my own understanding. Certainly would not be good if that PRU 
loaded code from ARM. The Linux part I'm unfamiliar with. From my reading it 
sounds like starting PRU is manually done from linux command line. 
Loading and debugging PRU code seems to me to be slow and time consuming 
compared to jtag.
Lastly in the unlikely event a modified libpruio example crashes what is the 
debug mechanisms beyond dmsg saying dude you crashed go recompile and reload. 
Are console output echoed back.
Thanks in advance also any data sharing examples in libpruio?Mark

Sent from Yahoo Mail on Android 
 
  On Fri, Apr 16, 2021 at 12:47 AM, TJF wrote:  


wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 18:35:20 
UTC+2:

So, STEPENABLE lets me enable the steps that I want to be executed.  (I missed 
that concept before.)

So if I had an application that had a sensor A that needs to be read every 10ms 
and sensor B that only needs to be read every minute, I could wire channel 1 to 
sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it 
to step 2. 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I'm 100% sure it wasn't doing this before because I worked through the 
exercises in Mark Yodre's PRUCookbook and this command

config-pin P9_31 pruout 

worked before

Now it gives

debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/05blocks/code$ 
config-pin P9_31 pruout
ERROR: open() for /sys/devices/platform/ocp/ocp:P9_31_pinmux/state failed, 
No such file or directory

I get the same error when I execute this as root.


On Friday, April 16, 2021 at 6:43:46 AM UTC-4 Walter Cromer wrote:

> Yes.  It’s throwing an error when I do that. I don’t think it was before 
> but I could be mistaken.  I can’t even query the options with 
> configure-pin.  It makes me wonder if the pins I’m choosing are in use by 
> something else like video or audio.  I will check this today. 
>
>
> On Thu, Apr 15, 2021 at 4:00 PM Darren Freed  wrote:
>
>> Have you set the pins with config-pin to pruout or pruin?  This caught me 
>> out a few times when I was learning PRU.
>>
>>
>> On Thu, Apr 15, 2021 at 7:15 AM Walter Cromer  
>> wrote:
>>
>>> I'm sticking with remoteproc for now.  I spent most of yesterday reading 
>>> TI's documentation and the Beaglebone Black SRM in detail and believe I 
>>> have a much better handle on how this works now.  
>>> My plan is to allocate memory space in pru0's RAM for the data storage 
>>> and then have an ARM program read it from there.Our production solution 
>>> does not need to share this data with the ARM side.  We only need this 
>>> during R so I'm not worried about the two sides clobbering each other on 
>>> the production system.
>>>
>>> But, now, of course, nothing that used to work is working!  I had 
>>> started out with the PRUCookbook and had P9_11 blinking an LED.  Now, 
>>> nothing.  dmesg shows the PRU starting and stopping and the firmware file 
>>> in /lib/firmware is new based on ls -l output so I'm fairly certain that 
>>> the code got compiled and copied over to the right directory.  The 
>>> PRUCookbook example that blinks USR3 works and I can change the blinking 
>>> frequency and change it to blink USR2 instead and all that works.  But the 
>>> example to blink P9_11 won't and neither will another one to blink P9_27.  
>>>  The only thing I know I changed is that the PRUCookbook directories were 
>>> all owned by root and group root.  They weren't originally like that but 
>>> got changed somehow.  Yesterday I did a *chown -R debian:debian* on 
>>> PRUCookbook to change them so Debian could edit files in those 
>>> directories.  I wouldn't think this would matter since all the real 
>>> remoteproc action happens in other directories.  
>>>
>>> I also started working with CCS some and trying to get it going.  
>>>  Somewhere along the way, something deleted all the files and folders in my 
>>> local WIndows machine's Documents folder.  I'm running anti-virus and 
>>> anti-malware on the WIndows box.
>>>
>>> Just when I thought I was going to start really moving forward!!!
>>>
>>> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>>>
 lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:

> I thought he had an unacceptable delay reading ADC from ARM?
> Just trying to understand how libpruio fixes this and if it did why 
> even bother with PRU?
>

 In RB mode libpruio fetches ADC data at accurate timing (no delays) in 
 to a ring buffer. The ARM can read/evaluate the data later.

 @Walter
 Inspired by lazarman, just another thought: perhaps you don't need a 
 PRU mainloop at all. Perhaps you can meet your needs by ARM code using the 
 libpruio trigger features in MM mode.

1. Configure your trigger event (up to four events can get chained 
up).
2. Open valves.
3. Start MM mode, synchronously waiting for trigger.
4. Close valves.
5. ?Perhaps evaluate pre-trigger values?
6. Repeat from step 2.

 -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

As I get a better understanding and experience this may change, but right 
now I don't think it can handle the volume of data we need to move between 
systems.  And, that volume is only needed during R  The production 
system will not need to keep that data.

So, my plan is to instance arrays on the ARM side and use RPMSG to pass the 
addresses to the PRU.  The PRU code will translate that to ARM addresses.  
 As the data is collected it will be stored in arrays local to the PRUs (in 
the 8k or 12k memory spaces).  When the time-sensitive data collection is 
completed, the PRU array will contain the data.  Then we'll just copy it 
over the ARM addresses.

My assumption is that since the ARM instances the arrays in memory, Linux 
will not overwrite those locations so they'll be 'safe'.  I'll probably use 
RPMSG to alert ARM that the data is going to be transferred and wait on an 
'ack' from the ARM before copying it over. 

Seems like it should work.



On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote:

> Hello TJF
>
> Looks very powerful and code is very generic and well thought out. I 
> thought you couldn't code?藍
>
> I'm on tablet forgive my laziness where are the ADC examples located in c 
> language if possible 
>
> Looks like you support multiple languages nice.
>
>
> I'm guessing  below reference you mentioned is the am335x TRM or are you 
> referring to the ARM intellectual property for ADC?
>
> It's also possible to directly write to the step configuration in 
> AdcSet::St_p 
> 
>  by 
> writing to the member variables Confg and Delay. See ARM Reference Guide, 
> chapter 12  for details on ADC 
> configurations.
>
> Thanks. Did you write this library? It's quite a bit to wrap ones mind 
> around. How long dis this take to develop. 
>
> I've got a basic  understanding of how RPMSG works I'd like to understand 
> how libpruio handles the data exchange. 
>
> I'm wondering why Walter isn't using RPMSG  he's talking about using the 
> other unused  PRU memory to store data and have ARM read it. I'm trying to 
> see if that's doable for my own understanding. Certainly would not be good 
> if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From 
> my reading it sounds like starting PRU is manually done from linux command 
> line. 
>
> Loading and debugging PRU code seems to me to be slow and time consuming 
> compared to jtag.
>
> Lastly in the unlikely event a modified libpruio example crashes what is 
> the debug mechanisms beyond dmsg saying dude you crashed go recompile and 
> reload. Are console output echoed back.
>
> Thanks in advance also any data sharing examples in libpruio?
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 16, 2021 at 12:47 AM, TJF
>  wrote:
>
>
> wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 
> 18:35:20 UTC+2:
>
> So, STEPENABLE lets me enable the steps that I want to be executed.  (I 
> missed that concept before.)
>
> So if I had an application that had a sensor A that needs to be read every 
> 10ms and sensor B that only needs to be read every minute, I could wire 
> channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
> B and assign it to step 2. 
>
> Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
> and steps 3-16 aren't needed so I don't use them.  Then after the initial 
> read when I don't need to read sensor B until a minute passes, I can change 
> STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
> sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
> so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
> read. 
>
> There're 17 steps, one charge step and 16 sample steps. Each step 
> configures not only the multiplexer (chanel 0-7), but also an open delay 
> and a sample delay, as well as an avaraging number. That's explained at 
> AdcUdt::setStep() 
> ,
>  
> including a hint where to find further information in the ARM TRM.
>
> In order to write to the STEPENABLE register you've to stop the sequencer, 
> write the new value and restart the sequencer again. This is 3 times L3 
> operation, which need at least 3 PRU cycles each (perhaps more in case of 
> heavy travel). How do you what to ensure accurate ADC timing?
>
> The outnumber of step registers isn't thought of macroscopic asymmetry (in 
> your case sample channel A and B at 10 ms and ignore the B value for a 
> minute). 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Yes.  It’s throwing an error when I do that. I don’t think it was before
but I could be mistaken.  I can’t even query the options with
configure-pin.  It makes me wonder if the pins I’m choosing are in use by
something else like video or audio.  I will check this today.


On Thu, Apr 15, 2021 at 4:00 PM Darren Freed  wrote:

> Have you set the pins with config-pin to pruout or pruin?  This caught me
> out a few times when I was learning PRU.
>
>
> On Thu, Apr 15, 2021 at 7:15 AM Walter Cromer 
> wrote:
>
>> I'm sticking with remoteproc for now.  I spent most of yesterday reading
>> TI's documentation and the Beaglebone Black SRM in detail and believe I
>> have a much better handle on how this works now.
>> My plan is to allocate memory space in pru0's RAM for the data storage
>> and then have an ARM program read it from there.Our production solution
>> does not need to share this data with the ARM side.  We only need this
>> during R so I'm not worried about the two sides clobbering each other on
>> the production system.
>>
>> But, now, of course, nothing that used to work is working!  I had started
>> out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.
>> dmesg shows the PRU starting and stopping and the firmware file in
>> /lib/firmware is new based on ls -l output so I'm fairly certain that the
>> code got compiled and copied over to the right directory.  The PRUCookbook
>> example that blinks USR3 works and I can change the blinking frequency and
>> change it to blink USR2 instead and all that works.  But the example to
>> blink P9_11 won't and neither will another one to blink P9_27.   The only
>> thing I know I changed is that the PRUCookbook directories were all owned
>> by root and group root.  They weren't originally like that but got changed
>> somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to
>> change them so Debian could edit files in those directories.  I wouldn't
>> think this would matter since all the real remoteproc action happens in
>> other directories.
>>
>> I also started working with CCS some and trying to get it going.
>>  Somewhere along the way, something deleted all the files and folders in my
>> local WIndows machine's Documents folder.  I'm running anti-virus and
>> anti-malware on the WIndows box.
>>
>> Just when I thought I was going to start really moving forward!!!
>>
>> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>>
>>> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>>>
 I thought he had an unacceptable delay reading ADC from ARM?
 Just trying to understand how libpruio fixes this and if it did why
 even bother with PRU?

>>>
>>> In RB mode libpruio fetches ADC data at accurate timing (no delays) in
>>> to a ring buffer. The ARM can read/evaluate the data later.
>>>
>>> @Walter
>>> Inspired by lazarman, just another thought: perhaps you don't need a PRU
>>> mainloop at all. Perhaps you can meet your needs by ARM code using the
>>> libpruio trigger features in MM mode.
>>>
>>>1. Configure your trigger event (up to four events can get chained
>>>up).
>>>2. Open valves.
>>>3. Start MM mode, synchronously waiting for trigger.
>>>4. Close valves.
>>>5. ?Perhaps evaluate pre-trigger values?
>>>6. Repeat from step 2.
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.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/CAMRnUvDf16iYJoqN_xZo%2BJMKF%2Bso6oUdLPKXKEwaqrCjK4a8Ng%40mail.gmail.com
> 
> .
>
-- 
Thanks,

Walter Cromer, MS, PMP, PMI-ACP, CSM
Chief Idea Officer and Founder
Eden Concepts LLC
w: http://edenconceptsllc.com
m: 865-719-8881

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[TJF]

lazarman schrieb am Freitag, 16. April 2021 um 09:01:56 UTC+2:

> Looks very powerful and code is very generic and well thought out. I 
> thought you couldn't code?藍

Even a blind hen sometimes finds a grain of corn. I'm not a programming 
expert, but I've a ton of hands-on experience in developing realtime closed 
loop controllers.
 

> I'm on tablet forgive my laziness where are the ADC examples located in c 
> language if possible
>
See 
https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html

C examples including ADC: 1.c, io_input.c, rb_file.c

Since I don't know how to generate graphical screen output in C (or 
Python), I didn't transform the further ADC examples (ie MM mode). They're 
FreeBASIC only. (Feel free to help out here.)

I'm guessing  below reference you mentioned is the am335x TRM or are you 
> referring to the ARM intellectual property for ADC?
>
> It's also possible to directly write to the step configuration in 
> AdcSet::St_p 
> 
>  by 
> writing to the member variables Confg and Delay. See ARM Reference Guide, 
> chapter 12  for details on ADC 
> configurations.
>
Just click on the text "ARM Reference Guide, chapter 12". It's a link to 
the document I'm refering to.
 

> Thanks. Did you write this library? It's quite a bit to wrap ones mind 
> around. How long dis this take to develop. 
>
The main tasks were to get the FreeBASIC compiler running on ARM, to 
develop the CMake support for that language and to create a filter for 
Doxygen. Then the first version was less than three month. Find details at

https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaChangelog.html
 

> I've got a basic  understanding of how RPMSG works I'd like to understand 
> how libpruio handles the data exchange. 
>
> I'm wondering why Walter isn't using RPMSG  he's talking about using the 
> other unused  PRU memory to store data and have ARM read it. I'm trying to 
> see if that's doable for my own understanding. Certainly would not be good 
> if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From 
> my reading it sounds like starting PRU is manually done from linux command 
> line. 
>
> Loading and debugging PRU code seems to me to be slow and time consuming 
> compared to jtag.
>
> Lastly in the unlikely event a modified libpruio example crashes what is 
> the debug mechanisms beyond dmsg saying dude you crashed go recompile and 
> reload. Are console output echoed back.
>
Again: libpruio does not use, and will never use rproc/rpmsg.
 

> Thanks in advance also any data sharing examples in libpruio?
>
pruss_add.c, pruss_toggle.c
And, of course, libpruio itself.

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/0655e0fe-4158-473b-a47a-15ec77e533c4n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

['Mark Lazarewicz' via BeagleBoard]

Hello TJF
Looks very powerful and code is very generic and well thought out. I thought 
you couldn't code?藍
I'm on tablet forgive my laziness where are the ADC examples located in c 
language if possible 
Looks like you support multiple languages nice.

I'm guessing  below reference you mentioned is the am335x TRM or are you 
referring to the ARM intellectual property for ADC?
It's also possible to directly write to the step configuration in AdcSet::St_p 
by writing to the member variables Confg and Delay. See ARM Reference Guide, 
chapter 12 for details on ADC configurations.
Thanks. Did you write this library? It's quite a bit to wrap ones mind around. 
How long dis this take to develop. 
I've got a basic  understanding of how RPMSG works I'd like to understand how 
libpruio handles the data exchange. 
I'm wondering why Walter isn't using RPMSG  he's talking about using the other 
unused  PRU memory to store data and have ARM read it. I'm trying to see if 
that's doable for my own understanding. Certainly would not be good if that PRU 
loaded code from ARM. The Linux part I'm unfamiliar with. From my reading it 
sounds like starting PRU is manually done from linux command line. 
Loading and debugging PRU code seems to me to be slow and time consuming 
compared to jtag.
Lastly in the unlikely event a modified libpruio example crashes what is the 
debug mechanisms beyond dmsg saying dude you crashed go recompile and reload. 
Are console output echoed back.
Thanks in advance also any data sharing examples in libpruio?Mark

Sent from Yahoo Mail on Android 
 
  On Fri, Apr 16, 2021 at 12:47 AM, TJF wrote:   
wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 18:35:20 
UTC+2:

So, STEPENABLE lets me enable the steps that I want to be executed.  (I missed 
that concept before.)

So if I had an application that had a sensor A that needs to be read every 10ms 
and sensor B that only needs to be read every minute, I could wire channel 1 to 
sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it 
to step 2. 

Then at startup, when I want to read both sensors, I enable steps 1 and 2 but 
not 3-16.  This saves time on the read as channels 3-7 aren't needed and steps 
3-16 aren't needed so I don't use them.  Then after the initial read when I 
don't need to read sensor B until a minute passes, I can change STEPENABLE so 
only step 1 is enabled and execute a read every 10 ms.  Only sensor A would be 
read.  Then at one minute intervals, I change STEPENABLE so steps 1 & 2 are 
enabled and when read is triggered, sensors A and B are read. 


There're 17 steps, one charge step and 16 sample steps. Each step configures 
not only the multiplexer (chanel 0-7), but also an open delay and a sample 
delay, as well as an avaraging number. That's explained at AdcUdt::setStep(), 
including a hint where to find further information in the ARM TRM.

In order to write to the STEPENABLE register you've to stop the sequencer, 
write the new value and restart the sequencer again. This is 3 times L3 
operation, which need at least 3 PRU cycles each (perhaps more in case of heavy 
travel). How do you what to ensure accurate ADC timing?
The outnumber of step registers isn't thought of macroscopic asymmetry (in your 
case sample channel A and B at 10 ms and ignore the B value for a minute). It's 
made for microscopic asymmetry, ie when you want to sample A twice as often as 
B.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/def726b2-31f2-469b-a9fc-70fc429ffa59n%40googlegroups.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/806450037.1554779.1618556494588%40mail.yahoo.com.