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

['Mark Lazarewicz' via BeagleBoard]

   
   - learn to read ADC values in RB mode (first from ARM side, then from PRU)   

   - learn to exchange data between ARM and PRU   

   - finally put all together in your PRU mainloop (perhaps test on ARM before)
Hello TJFI 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?
Sent from Yahoo Mail on Android 
 
  On Thu, Apr 15, 2021 at 12:00 AM, TJF wrote:   
wal...@edenconceptsllc.com schrieb am Mittwoch, 14. April 2021 um 17:58:31 
UTC+2:

So I looked over the libpruio page and it looks great.  My head's spinning a 
bit between remoteproc, uio, and libpruio options but I'd like to try libpruio. 
 I don't want to break remoteproc if I set up to use libpruio.  Will that 
happen?

libpruio will never run under rproc, since rproc isn't powerful enough (same 
issue with maschinekit). Only uio_pruss driver will meet its needs.
 
Also, I'm running Buster (version.sh) at the bottom of this post The 
instructions refer to Jessie.  Are the Debian packages referred to compatible 
with Buster?  Here's what I am referring to.


The easy way to benefit from libpruio is to install the Debian packages. 
They're not in mainline, yet.

RobertCNelson started to add the packages in mainline years ago. Ask him why he 
never finished.
For kernel 4.19 you'll have to add a symlink, since a sysfs path changed. 
(Compiling from source may be a good option.)
 Start your project by a working example. Then add features step by step. You 
cannot test your PRU mainloop before you got hardware IO running.   
   - install libpruio
   - get pruss_toggle example running   

   - add a second output
   - learn to read ADC values in RB mode (first from ARM side, then from PRU)   

   - learn to exchange data between ARM and PRU   

   - finally put all together in your PRU mainloop (perhaps test on ARM before) 
  

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/7f8b9988-b6bf-4ae5-885b-818f1be0664bn%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/1604609652.1312043.1618466117801%40mail.yahoo.com.

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

[TJF]

wal...@edenconceptsllc.com schrieb am Mittwoch, 14. April 2021 um 17:58:31 
UTC+2:

> So I looked over the libpruio page and it looks great.  My head's spinning 
> a bit between remoteproc, uio, and libpruio options but I'd like to try 
> libpruio.  
> I don't want to break remoteproc if I set up to use libpruio.  Will that 
> happen?
>

libpruio will never run under rproc, since rproc isn't powerful enough 
(same issue with maschinekit). Only uio_pruss driver will meet its needs.
 

> Also, I'm running Buster (version.sh) at the bottom of this post 
> The instructions refer to Jessie.  Are the Debian packages referred to 
> compatible with Buster?  Here's what I am referring to.
>
> The easy way to benefit from *libpruio* is to install the Debian 
> packages. They're not in mainline, yet.
>
RobertCNelson started to add the packages in mainline years ago. Ask him 
why he never finished.

For kernel 4.19 you'll have to add a symlink, since a sysfs path changed. 
(Compiling from source may be a good option.)
 
Start your project by a working example. Then add features step by step. 
You cannot test your PRU mainloop before you got hardware IO running.

   1. install libpruio
   2. get pruss_toggle example running
   3. add a second output
   4. learn to read ADC values in RB mode (first from ARM side, then from 
   PRU)
   5. learn to exchange data between ARM and PRU
   6. finally put all together in your PRU mainloop (perhaps test on ARM 
   before)
   
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/7f8b9988-b6bf-4ae5-885b-818f1be0664bn%40googlegroups.com.

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

[eb]

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?

Thanks in advance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/381222af-605a-4d73-9bcf-d82a8aa26e22n%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]

That reference Dennis provided especially the block diagram showing everything 
about both PRU have access to is essential and a good thing to really consume.
Note each PRU has instruction ram and data RAM.
Instruction ram is where a debugger or rproc loads your pru program.
Keep in mind any ADC register you used on ARM has a different address on PRU if 
you're porting code from ARM be careful.
That document Dennis linked to also explains the ARM does muxing. That's 
defined ar setting a pins function as in GPIO or ADC etc etc. So PRU can access 
the ADC register direct as in those Macro's you were asking about.
Lastly the memory map shows shared RAM
I'm almost positive that's the area the ARM can access so that's your gateway 
between the PRU and ARM. 
Be careful rproc may be using a chunk of that but theoretically you could write 
your results and ARM could read it but you need a queue and a Way to ensure 
only one side is accessing the Data.
This can be done many ways unless you're really comfortable you might look for 
something else to transfer data.
I know the rproc for x15 carves out shared memory and all this done I think in 
the device tree.
Here's the magic area 

| 0x0001_ | Data 12KB RAM 2 (Shared)
 |


I'd start with a PRU  cookbook  ADC working example get that running then start 
asking about alternatives.
Maybe send back your ADC values to ARM while you change voltage input.
Dice the job up into manageable chunk's
Keep in mind you have no OS on PRU a main.c program will run once and exit.
Start getting familiar with every address important in your application on PRU 
and that document and exactly what you have to debug when PRU crashesPrintf etc 
etc
Baby steps Warren the tortoise slow and steady always wins the race.


Sent from Yahoo Mail on Android 
 
  On Wed, Apr 14, 2021 at 3:20 PM, Dennis Lee Bieber 
wrote:   On Wed, 14 Apr 2021 08:03:30 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

> The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 

    So far as I can make out, since each step config includes the
input/channel, it means one can sample the same channel multiple times
during a sequence.


-- 
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/i1je7g5lji264tiuae2ftumvb1e3mauicv%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/539829544.1070839.1618433959578%40mail.yahoo.com.

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

[Dennis Lee Bieber]

On Wed, 14 Apr 2021 08:03:30 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

> The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 

So far as I can make out, since each step config includes the
input/channel, it means one can sample the same channel multiple times
during a sequence.


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

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

[Dennis Lee Bieber]

On Tue, 13 Apr 2021 11:25:06 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>We're designing it the way you suggested.  The nice thing is that basically 
>the control logic has already been written in C on the ARM side.  Now, I 
>just
>Here's one more thing I am struggling with though.  It's a mental block I 
>think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>appears that on the PRU, we use __R30 instead but I don't understand how 
>that works.  I read through it this morning and it still isn't sinking in.  
>If anyone can help make this clearer, I'd appreciate it.
>
More details of what is confusing you would help.

R30 (output)/R31 (input) registers are mapped as one GPIO per bit
https://elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes
and those bits/GPIOs you are using will need to be properly pin-muxed in
u-Boot uEnv.txt.

As for using the registers... For input it should just be a case of
bitwise AND on the register content and test for result of 0/not 0
(assuming you are testing just one input at a time...). {Treat the
following as pseudo-code; I've not done any PRU programming, and am getting
stale with C]

inputX = 0 != (__R31 & (1 << desired_bit))

For output, you likely will need to maintain a copy (can the output
register be read by C code? -- if it can, forget the copy). You would AND
the inverse of the desired bit (to retain the other bits, but clear the
desired bit to 0) then OR the desired bit with the wanted value and write
the register with the combined result.

to set
__R30 = (__R30 & ^(1 << desired_bit)) | (1 << desired_bit)
to clear
__R30 = __R30 & ^(1 << desired_bit)

You'll likely want to prebuild the (1^^desired_bit) as constants for
each input/output of interest.


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

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

[Walter Cromer]

Definitely agree.  My head is spinning.  I am very appreciative of all the 
help and suggestions!

On Wednesday, April 14, 2021 at 1:13:25 PM UTC-4 lazarman wrote:

> Walter
>
> Just trying to be a guiding light. Why not get the control loop working on 
> PRU first.?
>
> Your being pulled into to many directions. I know how that feels I've been 
> there.
>
> Once the ADC and output works worry about getting Data over to ARM.
>
> Too many new things will kill you. Master the PRU coding first and on 
> second thought forget the CCS JTAG suggestions I gave.
>
> I'm getting dizzy reading all the suggestions you received. 
>
> What's working what's the architecture?
>
> Too many chef's the soup will boil away.
>
> Thanks 
>
> Mark
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Wed, Apr 14, 2021 at 10:58 AM, Walter Cromer
>  wrote:
>
> So I looked over the libpruio page and it looks great.  My head's spinning 
> a bit between remoteproc, uio, and libpruio options but I'd like to try 
> libpruio.  
> I don't want to break remoteproc if I set up to use libpruio.  Will that 
> happen?
>
> Also, I'm running Buster (version.sh) at the bottom of this post 
> The instructions refer to Jessie.  Are the Debian packages referred to 
> compatible with Buster?  Here's what I am referring to.
>
> The easy way to benefit from *libpruio* is to install the Debian 
> packages. They're not in mainline, yet. So you have to add a PPA (Personal 
> Package Archive) to your package management sources. On the default Debian 
> operating system, edit the file sudo nano /etc/apt/sources.list and add the 
> lines:
> deb http://beagle.tuks.nl/debian jessie/ deb-src 
> http://beagle.tuks.nl/debian jessie/ 
>
> Then grep the keyring by (mind the '-' character at the end)
> wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add - 
>
> Once prepared, you can update your package manager database
> sudo apt-get update
>
> debian@beaglebone:/$ sudo opt/scripts/tools/version.sh
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLT00C04417BBBK1847]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
> kernel:[4.19.94-ti-r61]
> nodejs:[v10.15.2]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
> pkg:[kmod]:[26-1]
> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
> admin spi iio docker tisdk weston-launch xenomai cloud9ide]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [   66.835497] remoteproc remoteproc0: wkup_m3 is available
> [   67.240120] remoteproc remoteproc0: powering up wkup_m3
> [   67.240151] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217148
> [   67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up
> [   69.894313] remoteproc remoteproc1: 4a334000.pru is available
> [   69.907897] remoteproc remoteproc2: 4a338000.pru is available
> [15549.657580] remoteproc remoteproc1: powering up 4a334000.pru
> [15549.665009] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
> size 30880
> [15549.665035] remoteproc remoteproc1: header-less resource table
> [15549.675909] remoteproc remoteproc1: Boot failed: -22
> [15602.811891] remoteproc remoteproc1: powering up 4a334000.pru
> [15602.812184] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
> size 

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

['Mark Lazarewicz' via BeagleBoard]

Walter
Just trying to be a guiding light. Why not get the control loop working on PRU 
first.?
Your being pulled into to many directions. I know how that feels I've been 
there.
Once the ADC and output works worry about getting Data over to ARM.
Too many new things will kill you. Master the PRU coding first and on second 
thought forget the CCS JTAG suggestions I gave.
I'm getting dizzy reading all the suggestions you received. 
What's working what's the architecture?
Too many chef's the soup will boil away.
Thanks 
Mark


Sent from Yahoo Mail on Android 
 
  On Wed, Apr 14, 2021 at 10:58 AM, Walter Cromer 
wrote:   So I looked over the libpruio page and it looks great.  My head's 
spinning a bit between remoteproc, uio, and libpruio options but I'd like to 
try libpruio.  I don't want to break remoteproc if I set up to use libpruio.  
Will that happen?
Also, I'm running Buster (version.sh) at the bottom of this post The 
instructions refer to Jessie.  Are the Debian packages referred to compatible 
with Buster?  Here's what I am referring to.


The easy way to benefit from libpruio is to install the Debian packages. 
They're not in mainline, yet. So you have to add a PPA (Personal Package 
Archive) to your package management sources. On the default Debian operating 
system, edit the file sudo nano /etc/apt/sources.list and add the lines:
deb http://beagle.tuks.nl/debian jessie/deb-src http://beagle.tuks.nl/debian 
jessie/
Then grep the keyring by (mind the '-' character at the end)
wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add -
Once prepared, you can update your package manager database
sudo apt-get update

debian@beaglebone:/$ sudo 
opt/scripts/tools/version.shgit:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]eeprom:[A335BNLT00C04417BBBK1847]model:[TI_AM335x_BeagleBone_Black]dogtag:[BeagleBoard.org
 Debian Buster IoT Image 
2020-04-06]bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd 
MBR]bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]UBOOT: Booted 
Device-Tree:[am335x-boneblack-uboot-univ.dts]UBOOT: Loaded 
Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]UBOOT: Loaded 
Overlay:[BB-ADC-00A0]UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]UBOOT: Loaded 
Overlay:[BB-HDMI-TDA998x-00A0]UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]UBOOT: 
Loaded 
Overlay:[BB-W1-P9.12-00A2]kernel:[4.19.94-ti-r61]nodejs:[v10.15.2]/boot/uEnv.txt
 
Settings:uboot_overlay_options:[enable_uboot_overlays=1]uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]uboot_overlay_options:[enable_uboot_cape_universal=1]uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]pkg
 check: to individually upgrade run: [sudo apt install --only-upgrade 
]pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]pkg:[kmod]:[26-1]pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]groups:[debian
 : debian adm kmem dialout cdrom floppy audio dip video plugdev users 
systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio 
docker tisdk weston-launch xenomai cloud9ide]cmdline:[console=ttyO0,115200n8 
bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 
rng_core.default_quality=100 quiet]dmesg | grep remote[   66.835497] remoteproc 
remoteproc0: wkup_m3 is available[   67.240120] remoteproc remoteproc0: 
powering up wkup_m3[   67.240151] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148[   67.240404] remoteproc remoteproc0: 
remote processor wkup_m3 is now up[   69.894313] remoteproc remoteproc1: 
4a334000.pru is available[   69.907897] remoteproc remoteproc2: 4a338000.pru is 
available[15549.657580] remoteproc remoteproc1: powering up 
4a334000.pru[15549.665009] remoteproc remoteproc1: Booting fw image 
am335x-pru0-fw, size 30880[15549.665035] remoteproc remoteproc1: header-less 
resource table[15549.675909] remoteproc remoteproc1: Boot failed: 
-22[15602.811891] remoteproc remoteproc1: powering up 
4a334000.pru[15602.812184] remoteproc remoteproc1: Booting fw image 
am335x-pru0-fw, size 30880[15602.812202] remoteproc remoteproc1: header-less 
resource table[15602.823804] remoteproc remoteproc1: Boot failed: 
-22[15801.464252] remoteproc remoteproc1: powering up 
4a334000.pru[15801.464540] remoteproc remoteproc1: Booting fw image 
am335x-pru0-fw, size 30880[15801.464559] remoteproc remoteproc1: header-less 
resource table[15801.475947] remoteproc remoteproc1: Boot failed: 
-22[15835.561165] remoteproc remoteproc1: powering up 
4a334000.pru[15835.561459] remoteproc remoteproc1: Booting fw image 
am335x-pru0-fw, size 30880[15835.561478] 

[beagleboard] Re: GPIO configuartion in Device Tree Overlay and how to set a default value for an output pin

[fenc...@gmail.com]

did you ever get to find a proper way to do this without this workaround?

On Tuesday, 11 July 2017 at 09:44:14 UTC+2 boner...@gmail.com wrote:

> Well I did a little workaround and made a script that will init the GPIO 
> via sysfs in the way I want at system start. But I don´t need to set the 
> pinmux via the overlay for that as far as i know.
> echo "61" > /sys/class/gpio/export   #set gpio61 P8_26
> echo "out" > /sys/class/gpio/gpio61/direction#set gpio61 as output
> echo "1" > /sys/class/gpio/gpio61/value  #set gpio61 to high
>
> The fragment@1 I mentioned seems to affect 
> /sys/kernel/debug/pinctrl
> But I still dont understand what it actually does.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/e56468de-41fc-47e0-8708-672b317d83f7n%40googlegroups.com.

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

[Walter Cromer]

So I looked over the libpruio page and it looks great.  My head's spinning 
a bit between remoteproc, uio, and libpruio options but I'd like to try 
libpruio.  
I don't want to break remoteproc if I set up to use libpruio.  Will that 
happen?

Also, I'm running Buster (version.sh) at the bottom of this post 
The instructions refer to Jessie.  Are the Debian packages referred to 
compatible with Buster?  Here's what I am referring to.

The easy way to benefit from *libpruio* is to install the Debian packages. 
They're not in mainline, yet. So you have to add a PPA (Personal Package 
Archive) to your package management sources. On the default Debian 
operating system, edit the file sudo nano /etc/apt/sources.list and add the 
lines:
deb http://beagle.tuks.nl/debian jessie/ deb-src 
http://beagle.tuks.nl/debian jessie/ 

Then grep the keyring by (mind the '-' character at the end)
wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add - 

Once prepared, you can update your package manager database
sudo apt-get update

debian@beaglebone:/$ sudo opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLT00C04417BBBK1847]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   66.835497] remoteproc remoteproc0: wkup_m3 is available
[   67.240120] remoteproc remoteproc0: powering up wkup_m3
[   67.240151] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148
[   67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   69.894313] remoteproc remoteproc1: 4a334000.pru is available
[   69.907897] remoteproc remoteproc2: 4a338000.pru is available
[15549.657580] remoteproc remoteproc1: powering up 4a334000.pru
[15549.665009] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15549.665035] remoteproc remoteproc1: header-less resource table
[15549.675909] remoteproc remoteproc1: Boot failed: -22
[15602.811891] remoteproc remoteproc1: powering up 4a334000.pru
[15602.812184] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15602.812202] remoteproc remoteproc1: header-less resource table
[15602.823804] remoteproc remoteproc1: Boot failed: -22
[15801.464252] remoteproc remoteproc1: powering up 4a334000.pru
[15801.464540] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15801.464559] remoteproc remoteproc1: header-less resource table
[15801.475947] remoteproc remoteproc1: Boot failed: -22
[15835.561165] remoteproc remoteproc1: powering up 4a334000.pru
[15835.561459] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15835.561478] remoteproc remoteproc1: header-less resource table
[15835.575362] remoteproc remoteproc1: Boot failed: -22
[15973.384568] remoteproc remoteproc1: powering up 4a334000.pru
[15973.384866] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15973.384884] remoteproc remoteproc1: header-less resource table
[15973.395805] remoteproc remoteproc1: Boot failed: -22
[15996.157221] remoteproc remoteproc1: powering up 4a334000.pru
[15996.157504] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15996.157523] remoteproc remoteproc1: header-less resource table

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

[Walter Cromer]

 The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 

On Wednesday, April 14, 2021 at 11:02:56 AM UTC-4 Walter Cromer wrote:

> My setup is a Windows 10 PC with a Black connected via USB or a Black 
> wireless connected via wi-fi.   So far I have done all the C development on 
> the ARM side with Cloud9 and only occasionally use Nano.  It's met my needs 
> just fine so far but this is getting more complex.  I installed TI's CCS 
> but it (or TI)  prefers to be on a Linux box apparently.
>
>
>
> On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote:
>
>> Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
>> exchanging source files via virtual file system), while I compile and test 
>> under LINUX on the BB.
>>
>> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 
>> 20:25:06 UTC+2:
>>
>>> Here's one more thing I am struggling with though.  It's a mental block 
>>> I think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>>> appears that on the PRU, we use __R30 instead but I don't understand how 
>>> that works.  I read through it this morning and it still isn't sinking in.  
>>> If anyone can help make this clearer, I'd appreciate it.
>>
>>
>> Check out example pruss_toggle 
>> 
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/17f5daf7-9271-4e90-a4f3-309b1ce20510n%40googlegroups.com.

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

[Walter Cromer]

My setup is a Windows 10 PC with a Black connected via USB or a Black 
wireless connected via wi-fi.   So far I have done all the C development on 
the ARM side with Cloud9 and only occasionally use Nano.  It's met my needs 
just fine so far but this is getting more complex.  I installed TI's CCS 
but it (or TI)  prefers to be on a Linux box apparently.



On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote:

> Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
> exchanging source files via virtual file system), while I compile and test 
> under LINUX on the BB.
>
> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 
> 20:25:06 UTC+2:
>
>> Here's one more thing I am struggling with though.  It's a mental block I 
>> think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>> appears that on the PRU, we use __R30 instead but I don't understand how 
>> that works.  I read through it this morning and it still isn't sinking in.  
>> If anyone can help make this clearer, I'd appreciate it.
>
>
> Check out example pruss_toggle 
> 
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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/f1f8bf49-4f8c-4d7c-9c0e-5b886f246960n%40googlegroups.com.