[beagleboard] PRU Assumptions - True or False

I am using BBB Revision C Please help me get clarity on my assumptions that I believe I have learned so far and tell me where I am incorrect: 1. There are 2 architectures to interact with the PRU's. They are *UIO* and *RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file.

[beagleboard] PRU Messaging

Group, I have been attempting to make a messaging example and I am either very close or so far away I don't realize it since I cannot seem to get it to respond. Once I get it working I will leave the answer for the world, please help me get this example working. It is at:

Re: [beagleboard] PRU remoteproc1 and 2 missing

It works. Thanks for the help! Appreciate it Regards, Cheng 在2021年4月7日星期三 UTC-4 下午1:20:20 写道： > On Wed, Apr 7, 2021 at 11:31 AM Cheng Chen wrote: > > > > Hi, > > > > I am just learning Beaglebone and have set up a Debian 10 image on a > recently purchased Beaglebone Black wireless. > > I

Re: [beagleboard] PRU remoteproc1 and 2 missing

On Wed, Apr 7, 2021 at 11:31 AM Cheng Chen wrote: > > Hi, > > I am just learning Beaglebone and have set up a Debian 10 image on a recently > purchased Beaglebone Black wireless. > I am following the Molloy's book chapter 15 to learn PRU. > However, it seems rproc module has not loaded the PRU.

[beagleboard] PRU remoteproc1 and 2 missing

Hi, I am just learning Beaglebone and have set up a Debian 10 image on a recently purchased Beaglebone Black wireless. I am following the Molloy's book chapter 15 to learn PRU. However, it seems rproc module has not loaded the PRU. Is there an additional step to allow use of the PRUs? What

[beagleboard] PRU I/O max speed

I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running into a speed limit < 50 MHz I desire. I can certainly create a clock that fast, but reading data seems to be delayed. I can see on the logic analyzer a "0" clearly being read as a '1" so there is either a delay in my

[beagleboard] PRU RemoteProc documentation

Hi all, I've done a few searches and couldn't find any threads or "conversations" in this forum/group on the remoteproc kernel module for loading firmware onto the PRUs. The remoteproc framework is supposed to be a Linux standard, there are some generic documents for it, but I've only found a

Re: [beagleboard] PRU 2 0 memory addresses

Hi Mark, My main question is how to use the offsets. How 0x0002_2000 will become 0x4B2A2000? For instance on the documents the Em seg., 4 de jan. de 2021 às 18:55, 'Mark Lazarewicz' via BeagleBoard < beagleboard@googlegroups.com> escreveu: > Please rephrase the question > > You said you used

Re: [beagleboard] PRU 2 0 memory addresses

Please rephrase the question  You said you used AM5729 addresses on BBC and BIG this will confuse people. You also said you find this below in code. It's possible that's an offset only  #define RCOUT_PRUSS_RAM_BASE      0x4b28 Stick what's in the reference manual and then verify that with any

[beagleboard] PRU 2 0 memory addresses

Hi guys, today to load the a code to PRU on BBB, BBG and Pocket we are using this addresses: POCKET: #define RCIN_PRUSS_RAM_BASE 0x4a301000 #define RCOUT_PRUSS_RAM_BASE 0x4a30 #define RCOUT_PRUSS_CTRL_BASE 0x4a322000 #define RCOUT_PRUSS_IRAM_BASE 0x4a334000 BBB: #define

[beagleboard] PRU - I2C on BBAI (WAS: PRU - ADC on BBAI

On Tue, 20 Oct 2020 05:33:26 -0700 (PDT), in gmane.comp.hardware.beagleboard.user "pierric...-jemvhsqn...@public.gmane.org" wrote: >Hi Denis, >Thanks for the help and sorry that I only answer now. >I understand what you mean with the I2C, I tried to change the topic of the >post without luck

[beagleboard] PRU Memory Store Instruction with Autoincrement?

Hi, folks, I'm trying to dump R31 over and over into either RAM0 or Shared DRAM (Data RAM). So, basically it looks like I have to do: Store R31 to address in register Increment address in register (Lather rinse repeat) As that stands, that's a 100MHz sample of R31. Is there anyway to do the

[beagleboard] PRU - ADC on BBAI

Hi All, I am trying to implement deterministic data acquisition on the Beaglebone AI. I was thinking of using the PRU with the ADC as it is done on one the TechLab example analogIn.pru0.c

[beagleboard] PRU interrupt program

Hello, I am trying to configure a low latency interrupt to detect change in GPIO input pin i.e. input to Beagle Bone AI changes from 0 ->1 or 1-> 0 , it should generate an interrupt. I want to do this preferably in PRU by implementing an ISR . Do you have an example code? Regards, Jayasudhaa

[beagleboard] PRU IEP timers non-responsive

Hello I'm trying to write a simple program to test the IEP timers. Ideally I'd like to be able to poll the timer and get an unsigned long value back, but for this test, I followed what I read in this post:

[beagleboard] PRU pins on BBAI

I see that the SRM[1] ([2] is easier to read) for the BBAI shows that some PRU pins appear at 2 of the P8/P9 header pins. Is this really so? --Mark [1] https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#pru-icss2-pin-access [2]

Re: [beagleboard] PRU Beginner Questions (2)

Many thanks for your reply and a friendly hat tip for all your efforts with Beaglebone.org - it is appreciated! I was thinking that maybe GPREG30 := 0xd233c9c3 represents some debugging info but couldn't figure out what was setting it. for the default PRU firmware => yes it makes sense to have

Re: [beagleboard] PRU Beginner Questions (2)

> On May 10, 2020, at 4:09 AM, V37E00E wrote: > >  > Hello, > > > > I’m a beginner learning about PRU with a couple of questions. I’ve been > using as reference: > > PRU Cookbook (thank you Mark) > Exploring BeagleBone by Derek Molloy > TI Examples & Labs >

[beagleboard] PRU Beginner Questions (2)

Hello, I’m a beginner learning about PRU with a couple of questions. I’ve been using as reference: - PRU Cookbook (thank you Mark) - Exploring BeagleBone by Derek Molloy - TI Examples & Labs https://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs *Questions:*

Re: [beagleboard] PRU locking up Beaglebone AI

Got a more complete answer from the TI support team: This is seems classic. The Remote Core, PRU in this case, is trying to access GPIO bank shared with Linux. Linux, by default owns all GPIO banks and if there are no GPIO lines requested by Linux - the GPIO bank will be powered down. Correct

Re: [beagleboard] PRU locking up Beaglebone AI

This makes a whole lot more sense now, because I swear I had it working on those GPIO ports at one point. I think I had exported pins manually while testing things. Thanks for the help! On Wed, Apr 29, 2020 at 2:59 PM John Allwine wrote: > That did it! I exported pin 8.43: > > echo 226 >

Re: [beagleboard] PRU locking up Beaglebone AI

That did it! I exported pin 8.43: echo 226 > /sys/class/gpio/export And now the PRUs can write to the set and clear addresses for GPIO8. I also exported 8.26: echo 124 > /sys/class/gpio/export And now the PRUs can write to the set and clear addresses for GPIO4. On Wed, Apr 29, 2020 at 11:42

Re: [beagleboard] PRU locking up Beaglebone AI

On Wed, Apr 29, 2020 at 12:38 PM Charles Steinkuehler < char...@steinkuehler.net> wrote: > Regarding your bus errors, I don't see anything in the TRM that > indicates the PRU shouldn't be able to talk to all of the GPIO banks. > > I have, however, seen bus errors on uninitialized GPIO banks which

Re: [beagleboard] PRU locking up Beaglebone AI

Regarding your bus errors, I don't see anything in the TRM that indicates the PRU shouldn't be able to talk to all of the GPIO banks. I have, however, seen bus errors on uninitialized GPIO banks which come up disabled by default. Check to make sure at least one GPIO pin is exported by the

Re: [beagleboard] PRU locking up Beaglebone AI

Using that test, I was able to quickly check to see which GPIO ports I was able to write to from the PRU. GPIO 1, 4 and 8 errored. GPIO 2 doesn't have any pins mapped to P8 or P9 headers, so that leaves GPIO 3, 5, 6 and 7 that I can use for hal_pru_generic. The P8 and P9 pins that are mapped to

Re: [beagleboard] PRU locking up Beaglebone AI

Ok, I have a more localized test that triggers the exception: https://github.com/PocketNC/cloud9-examples/blob/test-pru-gpio-access/BeagleBone/AI/pru/doNothingToGPIO8.pru1_1.c Two stack traces can be seen in dmesg after running that on the PRU. If it has something to do with the device tree, this

Re: [beagleboard] PRU locking up Beaglebone AI

Are there any ramifications of the PRU writing 0 to both the set and clear addresses of GPIO8 (0x48053190 and 0x48053194), when the device tree has several overlapping pins allocated to being direct outputs on the PRU? The issue seems to arise when I write to those two addresses on the PRU, as

Re: [beagleboard] PRU locking up Beaglebone AI

It seems that even if I hardcode the addresses in there (to eliminate the possibility that my registers were getting overwritten somewhere), that I get the bus error. Does enabling the OCP Master port work the same way as on the BBB? It's supposedly being set here:

Re: [beagleboard] PRU locking up Beaglebone AI

It's the hal_pru_generic code. It definitely smells like a bus error. In fact, if I comment out the lines that write to the GPIO, it stops happening, so it seems like I have the wrong addresses in there, but I'm struggling figuring out how that could be. These lines are where the GPIO ports are

Re: [beagleboard] PRU locking up Beaglebone AI

What is the code running on PRUSS2 PRU1? This line kinda spells out an illegal access by that PRU or of that PRU: MASTER PRUSS2 PRU1 TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access Looks like the error is from here:

[beagleboard] PRU locking up Beaglebone AI

I'm getting this stack trace in dmesg, but I'm unsure what it means or how to figure out what it means. As far as I can tell, the code running on the PRU is working. I'm generating a 100Khz signal on a direct output, and am able to successfully measure this signal. The Beaglebone is locking up,

Re: [beagleboard] PRU example does not work

Could you refer to which version of the image or code repository this applies? I have a BBBlack. Maybe I could try it. Op wo 8 jan. 2020 15:20 schreef Stephan Böck : > Hello everybody, > > I just got my hands on a BB AI. During my testing I stumbled over an error > in the Cloud 9 examples. > I

[beagleboard] PRU example does not work

Hello everybody, I just got my hands on a BB AI. During my testing I stumbled over an error in the Cloud 9 examples. I wanted to run the program blinkInternalLED.pru1_1.c of the PRU examples of the AI. The following message appeares in the terminal output if I try to run it (note: I work with

[beagleboard] PRU based Apple IIe videocard

Helllo Guys, I just wanted to share the first steps of my project: take a look to my facebook post: https://www.facebook.com/groups/5251478676/permalink/10159148656378677/ Best, Tomas -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

[beagleboard] PRU phandle is changing

I'm writing a kernel driver that needs to control the PRUs' state using rproc_boot(...)/rproc_shutdown(...) from linux/remoteproc.h. The functions take a `struct rproc *` as argument. I tried using `rproc_get_by_phandle(...)` to get the reference to the PRUs. The problem is that the phandles

Re: [beagleboard] PRU Communications: Beaglebone Black

Thanks for quoting the TRM for me (I didn't download the 'c' version yet). Am Donnerstag, 4. Juli 2019 15:10:38 UTC+2 schrieb Charles Steinkuehler: > > On 7/4/2019 2:57 AM, TJF wrote: > > Interesting, thanks Charles! > > > > Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles

Re: [beagleboard] PRU Communications: Beaglebone Black

On 7/4/2019 2:57 AM, TJF wrote: > Interesting, thanks Charles! > > Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler: >> >> The >> transfer is terminated if either PRU core stalls for more than 1024 >> cycles. > > How to distinguish between a terminated or regular

Re: [beagleboard] PRU Communications: Beaglebone Black

Interesting, thanks Charles! Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler: > > The > transfer is terminated if either PRU core stalls for more than 1024 > cycles. > How to distinguish between a terminated or regular transfer? Regards -- For more options, visit

Re: [beagleboard] PRU Communications: Beaglebone Black

Sounds a tad more intricate, but seems powerful. Thanks for letting us know, Steinkuehler. On Wed, Jul 3, 2019, 9:05 PM Charles Steinkuehler wrote: > As has been discussed, the PRUs have no direct "interrupt" like > functionality that interrupts and redirects program execution. > > In addition

Re: [beagleboard] PRU Communications: Beaglebone Black

As has been discussed, the PRUs have no direct "interrupt" like functionality that interrupts and redirects program execution. In addition to the various methods already discussed, if you are trying to tightly couple program execution between the two PRU cores, I suggest using the transfer

[beagleboard] PRU Communications: Beaglebone Black

We are a group working with a Beaglebone and trying to get more time determinism between the PRUs. We are trying to get one PRU to respond to a trigger from the other PRU. The INTC framework seems quite complex, and we are finding it quite difficult to decipher or understand (but an example might

[beagleboard] PRU remoteproc[12] not appearing under /sys/class/remoteproc/

I've just set up a new Debian 9.5 (kernel 14.4.71-ti-r80) image and made the following changes to /boot/uEnv.txt: disable_uboot_overlay_video=1

[beagleboard] PRU Remoteproc Carveout Access from Userspace

Greetings All, TLDR; what is the best way to access PRU remoteproc carveouts from userspace? I have a (working) project for reading an 8-bit parallel interface camera that I originally wrote using UIOPRUSS. I decided to take the plunge and work through the remoteproc documentation to see if I

[beagleboard] PRU Can not change output ...

Can Anyone Help me? my code can not change the output of pru ... machinekit@beaglebone:~$ uname -a Linux beaglebone 4.19.26-bone-rt-r26 #1stretch PREEMPT RT Thu Feb 28 11:27:59 UTC 2019 armv7l GNU/Linux machinekit@beaglebone:~$ cat /boot/uEnv.txt #Docs:

[beagleboard] PRU DMA Example

I tried to launch some examples using chain DMA+PRU. I found this git repository https://github.com/maciejjo/beaglebone-pru-dma (There is guide i used to launch example: https://github.com/maciejjo/beaglebone-pru-dma/tree/master/Documentation) But i didn't make it cause of troubles with

[beagleboard] PRU does not start.

Hello. I need help regarding PRU. I tried to enable the PRU by a command below. *root@beaglebone:/sys/class/remoteproc/remoteproc1# echo 'start' > state * -bash: echo: write error: No such file or directory But I get above result and PRU does not start. I also tried sudo sh -c "echo

Re: [beagleboard] PRU dev/rpmsg_pru* files don't exist

On Mon, Feb 25, 2019 at 9:35 AM Lee wrote: > > Hello, > > I am trying to send data from the ARM processor to the PRU using rpmsg. After > following Greg's guide found here: > https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf, I > am still unable to see any rpmsg_pru*

[beagleboard] PRU dev/rpmsg_pru* files don't exist

Hello, I am trying to send data from the ARM processor to the PRU using rpmsg. After following Greg's guide found here: https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf, I am still unable to see any rpmsg_pru* files in the dev folder. Are there additional

[beagleboard] PRU Cape Demo Starterware not Loading

Hello, I am following the instructions here: http://processors.wiki.ti.com/index.php/PRU_Cape_Getting_Started_Guide to get started with the BBB PRU Cape Rev 1.2A. The MLO and app folders are on the SD card, and the serial terminal is setup in Putty with all of the required settings. The SD

Re: [beagleboard] PRU Internal clock

Thanks to both of you, this is really helpful. Charles, this is what I was looking for and for this particular problem is what I need, but also thanks Bill I will have a look at this timer as well. On Friday, December 7, 2018 at 7:35:21 PM UTC-5, Charles Steinkuehler wrote: > > On 12/7/2018

Re: [beagleboard] PRU Internal clock

On 12/7/2018 11:16 AM, alanmthomason via BeagleBoard wrote: > I use the BeagleBone Black PRU for a very time critical task. I currently > have registers that increment based on how many instructions I have just > run and their type (SBBO's for instance take more than the usual 1 clock > cycle

Re: [beagleboard] PRU Internal clock

Hi Alan! There is only 1 of this timer, so expect trouble if you try to use it on both PRU's at the same time.. That said, the following should do what you want (from Mark Yoder's PRU Cookbook). One count == 5ns, so you can do some pretty precise timing. #include # define TEN_US_DELAY 2001

[beagleboard] PRU Internal clock

I use the BeagleBone Black PRU for a very time critical task. I currently have registers that increment based on how many instructions I have just run and their type (SBBO's for instance take more than the usual 1 clock cycle per instruction) so that I can keep track of time. I have seen

Re: [beagleboard] PRU - Can't read data up to 2.5 MHz

I Gerhard, thank you very much for your answer. I replaced the "IF" statements by "While", as shown in your example and the communication got a way faster. However, I am can't still get data at 10 MHz, I think the problem has to be with writing in the shared memory zone, I've got the following

[beagleboard] PRU compiler Optimization Issue

Hi! First, a *big* thanks to Mark Yoder, who kindly put a whole lot of information together to help me figure this out. I'm attempting to using the BBB to make a simple motor controller and will use the PRU's to do the critical timing events.To demonstrate a baby step, I decided to play

Re: [beagleboard] PRU - Can't read data up to 2.5 MHz

Am 28.11.18 um 12:08 schrieb fred.p.gome...@gmail.com: ... |state[0] = ((__R31) == sclk) ?  true :  false;| |state[0] = (__R31) == sclk; | | | |should do the same thing, but I would expect the compiler to optimize| |that away. Unrolling the loops and inlining should help, also. | This is how I

[beagleboard] PRU - Can't read data up to 2.5 MHz

Hello, I need your help I have to read data from an SPI master device, which sends the clock at 10 MHz. Since the SPI kernel driver only allows to the beagle bone to working as SPI Master I had to implement this functionality using a PRU. >From what I've read throughout the internet the PRU

[beagleboard] PRU devices taking a very long time to start up

I have PRU code working great on my BeagleBone Black industrial boards using the latest Debian 9.5 2018-10-07 4GB SD IoT flashed to eMMC, but even though the board boots up very quickly, I have to wait about *two minutes* after boot-up before the PRU cores can be used. Here's the last part of

Re: [beagleboard] Pru Reset without BBB reboot?

Many many thanks. prussdrv_pru_reset () make the job. Two very good tips. This is going to be a nice day. :-) All good for you Peter Am Mittwoch, 24. Oktober 2018 14:55:39 UTC+2 schrieb Charles Steinkuehler: > > On 10/24/2018 5:05 AM, true...@web.de wrote: > > Hello, > > > > In tests with

Re: [beagleboard] Pru Reset without BBB reboot?

On 10/24/2018 5:05 AM, true-t...@web.de wrote: > Hello, > > In tests with clpru C programs, the problem arises again and again that the > Pru hangs up. > A simple LED Bink program can then no longer be started. > Is there a way to reset the Pru without rebooting the BBB? > Tips from the network

[beagleboard] Pru Reset without BBB reboot?

Hello, In tests with clpru C programs, the problem arises again and again that the Pru hangs up. A simple LED Bink program can then no longer be started. Is there a way to reset the Pru without rebooting the BBB? Tips from the network have not worked for me so far. thanks to all experts Peter

[beagleboard] PRU 0 & 1 not found, 9.4 & 9.5 debian, iot and lxqt

/sys/class/remoteproc/ shows me only remoteproc0. PRU 0 & 1 'don't exist'. I've not modified anything in the boot sequence yet.I've looked at https://groups.google.com/forum/#!category-topic/beagleboard/pru/4P9NdglojBo which lead me to trying echo "4a334000.pru0" > /sys/bus

[beagleboard] PRU Cookbook

Announcing rev 0.1.0 of PRU Cookbook PDF: https://github.com/beagleboard/PRUCookbook/releases/download/0.1.0/book.pdf Live view: https://markayoder.github.io/PRUCookbook/ Source: https://github.com/markayoder/PRUCookbook/ Report issues: https://github.com/markayoder/PRUCookbook/issues Outline

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

On Mon, Sep 17, 2018 at 3:41 PM GS wrote: > > Sorry I meant if I write my own PRU overlay file while completely disabling > universal cape, I should still be using "uboot_overlay_pru=" option? Really, you can use any of them, the variable uboot_overlay_pru has less other logic, so it's

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

Sorry I meant if I write my own *PRU *overlay file while completely disabling universal cape, I should still be using "uboot_overlay_pru=" option? On Monday, September 17, 2018 at 3:38:26 PM UTC-5, GS wrote: > > Thanks, Robert. I dont know how i missed that. > Just to make sure I understand

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

Thanks, Robert. I dont know how i missed that. Just to make sure I understand your second point correctly, if I write my own overlay file while completely disabling universal cape, I should still be using "uboot_overlay_pru=" option? Thanks again On Monday, September 17, 2018 at 3:28:58 PM

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

On Mon, Sep 17, 2018 at 3:32 PM Robert Nelson wrote: > > On Mon, Sep 17, 2018 at 3:28 PM Robert Nelson wrote: > > > > On Mon, Sep 17, 2018 at 3:21 PM GS wrote: > > > > > > PRU cape overlay fails to load due to pin conflicts on latest image. I > > > have tried various setups of overlays, none

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

On Mon, Sep 17, 2018 at 3:28 PM Robert Nelson wrote: > > On Mon, Sep 17, 2018 at 3:21 PM GS wrote: > > > > PRU cape overlay fails to load due to pin conflicts on latest image. I have > > tried various setups of overlays, none seem to work. I am not sure what am > > I missing. > > > > Setup 1:

Re: [beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

On Mon, Sep 17, 2018 at 3:21 PM GS wrote: > > PRU cape overlay fails to load due to pin conflicts on latest image. I have > tried various setups of overlays, none seem to work. I am not sure what am I > missing. > > Setup 1: [Highlighted section identifies the difference in the setup] > >

[beagleboard] PRU cape overlay fails to load on latest IOT Stretch image

PRU cape overlay fails to load due to pin conflicts on latest image. I have tried various setups of overlays, none seem to work. I am not sure what am I missing. *Setup 1*: [Highlighted section identifies the difference in the setup] debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh

Re: [beagleboard] PRU examples are half there

BTW, I seem to remember that I had to modify the code to work because RPMSG use to use mailbox to exchange messages, but that was changed to use Interrupts. I believe Jason Reeder from TI helped me get this working. Regards, John > On May 7, 2018, at 12:47 PM, Mark A. Yoder

Re: [beagleboard] PRU examples are half there

Yeah, I haven’t worked on this for a while, but from what I remember, the ARM side sends out 200 ping messages to the PRU and the PRU responds to each interrupt with a reply, which the ARM side prints out. Look for the PING example for the PRU, load the firmware and then load this Kernel

Re: [beagleboard] PRU examples are half there

I remember seeing both sides of the code for this interrupt example but it was for bare bone NOT linux.  Its been 6 months and I'm not sure if that helps you. My focus/interest  is primarily the chip level(register level) not API(remote proc). If it your interested I could do some digging. I

Re: [beagleboard] PRU examples are half there

John: That's a great help. Is the documentation for the example? --Mark On Monday, May 7, 2018 at 3:01:54 PM UTC-4, john3909 wrote: > > > https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c > > > Regards, > John > > > > > > On May 7, 2018, at 8:19 AM,

Re: [beagleboard] PRU examples are half there

https://git.ti.com/rpmsg/rpmsg/blobs/rpmsg-ti-linux-4.4.y/samples/rpmsg/rpmsg_client_sample.c Regards, John > On May 7, 2018, at 8:19 AM, Mark A. Yoder wrote: > > Yup,

Re: [beagleboard] PRU examples are half there

Yup, all I see is the PRU code, no ARM code. --Mark On Sunday, May 6, 2018 at 11:28:40 AM UTC-4, Jason Kridner wrote: > > Did you look at http://git.ti.com/pru-software-support-package ? > > On May 4, 2018, at 5:08 PM, Mark A. Yoder > wrote: > > I'm starting to build up

Re: [beagleboard] PRU examples are half there

Did you look at http://git.ti.com/pru-software-support-package ? > On May 4, 2018, at 5:08 PM, Mark A. Yoder wrote: > > I'm starting to build up some remoteproc-based examples for the PRU and found > a bunch of examples here:

[beagleboard] PRU examples are half there

I'm starting to build up some remoteproc-based examples for the PRU and found a bunch of examples here: */usr/lib/ti/pru-software-support-package/examples*. But the examples are only *half* there. That is, the code is present for the PRU side but not the ARM side. For example,

Re: [beagleboard] PRU with internal ADC question

From Vega's line 62 fifo0_count = HWREG(0x44e0d0e4); Go to the TRM(spruh73p search at ti.com), chapter 2, Table 2-2 Look for region name ADC_TSC, Start Address 0x44E0_D000 to End Address 0x44E0_EFFF So you are looking for register at offset 0x00E4 click on the ADC-TSC link or look

[beagleboard] PRU with internal ADC question

Hi friends. Im trying to use the BBB built-in ADC to read values with regular sampling frequency. I am using almost all defined by Rafael Vega's github project page ( https://github.com/rvega/bbb-pru/blob/master/apps/adc/pru.c). I already made changes to read the ADC sampled values on the ARM

Re: [beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

On Mon, Mar 12, 2018 at 7:50 PM, Rick Mann wrote: > Oh. I finally found this tiny note on > https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays: > > (doesn't work with v4.9.x-ti yet) > > That same page says remoteproc works on v4.4.x-ti, so I'm not sure

Re: [beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

Oh. I finally found this tiny note on https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays: (doesn't work with v4.9.x-ti yet) That same page says remoteproc works on v4.4.x-ti, so I'm not sure if the current IoT image is supposed to be able to use the PRU at all. > On Mar 12,

[beagleboard] PRU-UIO specified, but lsmod shows pru_rproc?

On the recent IoT (March 2018) standalone build, on BBB: I'm trying to enable uio PRUSS, and in /boot/uEnv.txt I uncommented uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo But after rebooting, it seems (I think?) that remoteproc is still what's loaded: $ lsmod Module

[beagleboard] PRU based frequency detection and measuremnt-

kernel 3.8.x Thanks for the effort for addressing this problem in advance. The following assembler and python files concists of my code to measure frequencies on the respectiver ports P8_15 and P8_16 using PRU0. The only problem being the outout of one of those frequency measured is always

[beagleboard] PRU based frequency measurement

kernel 3.8.x Thanks for the effort for addressing this problem in advance. The following assembler and python files concists of my code to measure frequencies on the respectiver ports P8_15 and P8_16 using PRU0. The only problem being the outout of one of those frequency measured is always

[beagleboard] PRU - ARM Communication

Greetings, Thanks for all who will make an effort to answer my querry in advance. I am using Beaglebone Black Rev C with 3.8.x kernel and I'm stuck with establishng inter-communication between one of the cores of the PRU to the main ARM core where the OS lies.Requirement- The PRU requires a

[beagleboard] PRU programming with pasm compiled .bin hangup - prussdrv_open() failed

Hello, I've been playing with this Beaglebone Black Wireless for several months now, and I feel like I've come pretty far from out-right newbie status, but after struggling for so long to program one of the BBBW's PRUs I'm starting to feel like a newbie again. Please help! I've been following

[beagleboard] PRU/DDR Feasibility

I'm looking at moving away from an FPGA to a PocketBeagle for a new project, and I think I can divide up my real-time tasks between the 2 PRU's: 1. Use PRU0 as a SPI master to capture external 16-bit ADC data at 500kS/s 2. Store around 30MB of samples in DDR 3. Change PRU0

[beagleboard] PRU shared with Node-Red ??

Hi, I wondered if there was a way to make a program running in the PRU available to a Node-Red implementation running on the same BBB?? For example if I had the PRU doing serial communications, could I read/export any data into a Node-Red flow? Kind regards Michael -- For more

Re: [beagleboard] PRU

This github is great for getting started with the PRUs. Cuts right to the chase and provides examples for all the required files. Thanks Jason. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

Re: [beagleboard] PRU

On Sat, Oct 7, 2017 at 5:18 PM William Hermans wrote: > On Fri, Oct 6, 2017 at 11:38 PM, wrote: > >> Hi, >> >> Hi, I am new to beaglebone black PRU can anybody help me to use PRU in >> c-language. >> >> Thank you >> Ashok >> > >

Re: [beagleboard] PRU

On Fri, Oct 6, 2017 at 11:38 PM, wrote: > Hi, > > Hi, I am new to beaglebone black PRU can anybody help me to use PRU in > c-language. > > Thank you > Ashok > http://lmgtfy.com/?q=beaglebone+PRU+in+C -- For more options, visit http://beagleboard.org/discuss ---

[beagleboard] PRU

Hi, Hi, I am new to beaglebone black PRU can anybody help me to use PRU in c-language. Thank you Ashok -- 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

[beagleboard] PRU DDR ram allocation using 4.4.54 kernel (uio or rproc?)

Hi all I am currently trying to get the EBB-PRU-ADC example from Derek Molloys website working on my new version of Debian. I am using kernel version; uname -r 4.4.54-ti-r93 In this later kernel, uio_pruss is no longer used and remote proc has now taken over. I have already gone through the

Re: [beagleboard] pru support for 4.4.84-ti-r120

On Tue, Sep 5, 2017 at 11:03 AM, Kasimir wrote: > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 armv7l >

[beagleboard] pru support for 4.4.84-ti-r120

I want to use the HDMI outputs to drive external circuit. Required toggle rate is between 1MHz and 10MHz. Have BB black. uname -a Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 armv7l GNU/Linux cat /etc/debian_version 9.1 So I have to use the PRU unit. I was searching

Re: [beagleboard] PRU Linux RAM access

Thank you Robert. Might be just what I need! -- 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

Re: [beagleboard] PRU Linux RAM access

On Thu, Aug 31, 2017 at 4:08 PM, wrote: > We need the PRU to sample 10MB of 8 bit data in one second and store the > bytes into RAM. > > Can the PRU do this? > > Any insight would be appreciated. look at beaglelogic: http://www.beaglelogic.net/ Regards, -- Robert Nelson

[beagleboard] PRU Linux RAM access

We need the PRU to sample 10MB of 8 bit data in one second and store the bytes into RAM. Can the PRU do this? Any insight would be appreciated. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

Re: [beagleboard] PRU speak fails to compile

I did some modifications to the pru_speak.c to correct errors until it finally compiled. Now the problem is that the directory /sys/class/misc/pru_speak/ is not created and the "build/bdist.linux-armv7l/egg/pru_speak/pruspeak.py", line 20, in __init__ method fails with: IOError: [Errno 2] No

  1   2   3   4   5   >