Re: [beagleboard] Re: PRU Assumptions - True or False

[Bruce Chidester]

Does the 5.x kernel support an interrupt from the PRU while also supporting 
the bi-directional messaging through rproc?

On Friday, May 28, 2021 at 12:38:08 PM UTC-5 RobertCNelson wrote:

> On Fri, May 28, 2021 at 12:36 PM Robert Nelson  
> wrote:
> >
> > On Fri, May 28, 2021 at 12:21 PM Bruce Chidester
> >  wrote:
> > >
> > > I'm confused because I thought the plan was Remote Proc going forward. 
> Do you seem to say it is UIO going forward?
> >
> > Mainline has been 'slowly' getting RemoteProc work done by TI..
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/remoteproc/pru_rproc.c
>
> 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/f1665040-057c-49a4-b5b9-50b853efecfcn%40googlegroups.com.

Re: [beagleboard] Re: PRU Assumptions - True or False

[Bruce Chidester]

I'm confused because I thought the plan was Remote Proc going forward. Do 
you seem to say it is UIO going forward?

On Friday, May 28, 2021 at 12:15:34 PM UTC-5 hel...@deepsoft.com wrote:

> At Fri, 28 May 2021 12:59:20 -0400 beagl...@googlegroups.com wrote:
>
> > 
> > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> > gmane.comp.hardware.beagleboard.user Bruce Chidester
> >  wrote:
> > 
> > >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:
> > 
> > Can't confirm for everything, but...
> > >
> > >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. 
> > >You cannot run both at the same time.
> > 
> > TRUE -- but maybe not "easily"; there are some dependencies upon the
> > kernel version loaded.
>
> YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc.
>
> > 
> > TI has deprecated UIO and considers RemoteProc to be the route for
> > future usage (it is not tied to just the PRUs, it should work with the 
> DSP
> > chips on the BB AI, et al.).
>
> I think the mainline kernels don't have the RemoteProc kernel code. At 
> least 
> by default.
>
> > 
> > >
> > >2. When using RemoteProc you can *send* a remote message to the PRU and 
> > >this solution *does not work* with UIO.
> > 
> > RPMsg supports sending message in both directions
> > 
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
> > """
> > There are two vrings provided per PRU core, one vring is used for 
> messages
> > passed to the ARM and the other vring is used for messages received from
> > the ARM. System level mailboxes are used to notify cores (ARM or PRU) 
> when
> > new messages are waiting in the shared buffers.
> > """
> > 
> > >
> > >3. When using UIO the PRU can *send* an Interrupt to the host code but 
> > >RemoteProc *cannot*.
> > >
> > >4. When using UIO, you *cannot* send an interrupt to the PRU, you need 
> to 
> > >create some other solution maybe through shared memory.
> > >
> > 
> > As the PRUs do not have what I would call true interrupts (they have a
> > set of "interrupt bits" but do NOT interrupt the processor, the bits have
> > to be polled, and appropriate handlers called) any talk of interrupts is
> > vague.
> > 
> > However, for RPMsg, the "mailbox" provides, I believe, some form of
> > blocked wait or maybe use of a select() call to test for mailbox data. I
> > don't really know what a "Kick" entails in:
> > """
> > ARM Host Steps
> > Step 1a: Allocate a new buffer -or-
> > Step 1b: Get a Used buffer from the slave Vring
> > Step 2: Copy data to be transferred into the buffer from Step 1
> > Step 3: Add the newly filled buffer to the Available list in the
> > slave Vring
> > Step 4: Kick the slave Vring by writing its index (1) into a
> > message in Mailbox 2
> > PRU Steps
> > Step 5: A Kick is discovered in Mailbox 2 with the index of the
> > Kicked Vring (1). This indicates to the PRU that data is available for
> > receive
> > Step 6: Get the Available buffer from the slave Vring
> > Step 7: Copy data to be received out of the buffer from Step 2
> > Step 8: Add the now empty buffer to the Used list in the slave
> > Vring
> > Step 9: Kick the slave Vring by writing its index (1) into a
> > message in Mailbox 3
> > """
> > Step five appears to be a polling loop on the mailbox.
> > 
> > 
> > 
> > 
>
> -- 
> Robert Heller -- Cell: 413-658-7953 <(413)%20658-7953> GV: 978-633-5364 
> <(978)%20633-5364>
> Deepwoods Software -- Custom Software Services
> http://www.deepsoft.com/ -- Linux Administration Services
> hel...@deepsoft.com -- Webhosting Services
>
>

-- 
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/32060533-8294-43ec-a812-969ddc9b83c5n%40googlegroups.com.

[beagleboard] Re: PRU Assumptions - True or False

[Bruce Chidester]

Dennis,

Thanks for your response. 

When developing with the UIO architecture, they use the term "interrupt", 
so I assume they meant it somehow, but not willing to die on that hill. I 
could not get any form of "what they called interrupt" to work the remote 
proc architecture. I tried, and tried, and tried. If that solution exists I 
would greatly appreciate it.

The bi-directional note is correct about messaging, I was trying to 
emphasize that UIO cannot do messaging.

Your willingness to get in the mud with my issues is appreciated.

On Friday, May 28, 2021 at 11:59:35 AM UTC-5 Dennis Bieber wrote:

> On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
>  wrote:
>
> >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:
>
> Can't confirm for everything, but...
> >
> >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. 
> >You cannot run both at the same time.
>
> TRUE -- but maybe not "easily"; there are some dependencies upon the
> kernel version loaded.
>
> TI has deprecated UIO and considers RemoteProc to be the route for
> future usage (it is not tied to just the PRUs, it should work with the DSP
> chips on the BB AI, et al.).
>
> >
> >2. When using RemoteProc you can *send* a remote message to the PRU and 
> >this solution *does not work* with UIO.
>
> RPMsg supports sending message in both directions
>
> https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
> """
> There are two vrings provided per PRU core, one vring is used for messages
> passed to the ARM and the other vring is used for messages received from
> the ARM. System level mailboxes are used to notify cores (ARM or PRU) when
> new messages are waiting in the shared buffers.
> """
>
> >
> >3. When using UIO the PRU can *send* an Interrupt to the host code but 
> >RemoteProc *cannot*.
> >
> >4. When using UIO, you *cannot* send an interrupt to the PRU, you need to 
> >create some other solution maybe through shared memory.
> >
>
> As the PRUs do not have what I would call true interrupts (they have a
> set of "interrupt bits" but do NOT interrupt the processor, the bits have
> to be polled, and appropriate handlers called) any talk of interrupts is
> vague.
>
> However, for RPMsg, the "mailbox" provides, I believe, some form of
> blocked wait or maybe use of a select() call to test for mailbox data. I
> don't really know what a "Kick" entails in:
> """
> ARM Host Steps
> Step 1a: Allocate a new buffer -or-
> Step 1b: Get a Used buffer from the slave Vring
> Step 2: Copy data to be transferred into the buffer from Step 1
> Step 3: Add the newly filled buffer to the Available list in the
> slave Vring
> Step 4: Kick the slave Vring by writing its index (1) into a
> message in Mailbox 2
> PRU Steps
> Step 5: A Kick is discovered in Mailbox 2 with the index of the
> Kicked Vring (1). This indicates to the PRU that data is available for
> receive
> Step 6: Get the Available buffer from the slave Vring
> Step 7: Copy data to be received out of the buffer from Step 2
> Step 8: Add the now empty buffer to the Used list in the slave
> Vring
> Step 9: Kick the slave Vring by writing its index (1) into a
> message in Mailbox 3
> """
> Step five appears to be a polling loop on the mailbox.
>
>
>
>
> -- 
> 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/2ee64ff3-f998-443f-9b44-0e06b371abb5n%40googlegroups.com.

[beagleboard] SOLUTION - Fully functioning example of a PRU interrupting a host application

[Bruce Chidester]

This is a fully functioning PRU interrupt example that works on my BBB 
revision C board. This example demonstrates the PRU interrupting the host 
using PRU0 and PRU1.

This example is ready to compile and ready-to-run example that had both the 
application code and the PRU code together. Hope this helps you. This 
provides clarity to those trying to figure this out.

git clone https://gitlab.com/brucechidester/pru-interrupt-example.git

or browse to:

https://gitlab.com/brucechidester/pru-interrupt-example

-- 
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/93d61f41-d919-4372-b5d1-bd30b6639c88n%40googlegroups.com.

[beagleboard] SOLUTION - Fully functioning PRI interrupting the host example

[Bruce Chidester]

This is a fully functioning PRU interrupt example that works on my BBB 
revision C board. This example demonstrates the PRU interrupting the host 
using PRU0 and PRU1.

This example is ready to compile and ready-to-run example that had both the 
application code and the PRU code together. Hope this helps you. This 
provides clarity to those trying to figure this out.

git clone https://gitlab.com/brucechidester/pru-interrupt-example.git

or browse to:

https://gitlab.com/brucechidester/pru-interrupt-example

-- 
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/10c97d27-6df5-47dc-9720-d08d884d2cf9n%40googlegroups.com.

Re: [beagleboard] SOLUTION - Missing /dev/rpmsg_pru30 and /dev/rpmsg_pru31

[Bruce Chidester]

Where's the "like" button?

Here it is -> LIKE

On Thursday, May 27, 2021 at 12:13:59 PM UTC-5 lazarman wrote:

> Very helpful post Bruce thanks. I am just a PRU observer. The resource 
> file is discussed in some TI documents it's a way to let Linux understand 
> what resources the PRU will need is what I understood.
>
>
> I'm guessing the SDK examples I played with had this all set up.
>
> My guess this file will be important if you use any DDR to store you're 
> samples.
>
> Great to know you are on the  path to success
>
> Mark
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, May 27, 2021 at 12:00 PM, Bruce Chidester
>  wrote:
>
> I am in the middle of struggling while introducing myself to the PRU. I 
> want to contribute to the world to help some other struggling individual 
> and this seems like the right place to post a solution.
>
> I am using Beaglebone Black Rec C. 
> Running the uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo defined 
> in /boot/uEnv.txt
>
> If you do not see the /dev/rpmsg_pru3* devices and you expect them, the 
> zip file I have attached has a working solution to make them show up. I 
> believe the solution has a lot to do with the right resource file and the 
> PRU code. They will not simply just show because you have 2 PRU's. This may 
> seem obvious to the more advanced PRU people, but took me a couple of weeks 
> to figure this (and other things) out.
>
> Here are my results after days of trying to figure out the magic to get 
> the devices to show up:
>
> root@beaglebone:/home/debian/rpmsg_pru# ./run.sh
> rpmsg_pru30
> rpmsg_pru31
>
> Once the devices show for you:
>
> echo "test30" > /dev/rpmsg_pru30
> echo "test31" > /dev/rpmsg_pru31
>
> cat /dev/rpmsg_pru30
>  - c
>
> cat /dev/rpmsg_pru31
>  - c
>
> -- 
> 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/562bed0a-c4d6-43aa-b62a-7528034cc8b6n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/562bed0a-c4d6-43aa-b62a-7528034cc8b6n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/f650283d-0ba9-4acc-b0b4-d8eed01288ccn%40googlegroups.com.

[beagleboard] SOLUTION - Fully functioning PRU RProc Messaging example

[Bruce Chidester]

This is a fully functioning PRU RProc Messaging example that works on my 
BBB revision C board.

The thing that makes this solution unique is as of this date of writing, I 
could not find a ready to compile and ready to run example that had both 
the application code and the PRU code together. When your struggling 
understanding the UIO vs. Remote Proc architectures and you don't know what 
goes with what, this will save some time for you.

git clone https://gitlab.com/brucechidester/pru-messaging-example.git

or browse to:

https://gitlab.com/brucechidester/pru-messaging-example

-- 
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/59d38972-674e-422f-90f1-001295488b5an%40googlegroups.com.

[beagleboard] PRU Assumptions - True or False

[Bruce Chidester]

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. 
You cannot run both at the same time.

2. When using RemoteProc you can *send* a remote message to the PRU and 
this solution *does not work* with UIO.

3. When using UIO the PRU can *send* an Interrupt to the host code but 
RemoteProc *cannot*.

4. When using UIO, you *cannot* send an interrupt to the PRU, you need to 
create some other solution maybe through shared memory.

5. When working with UIO, clpru generated binaries are *no good* and this 
forces you to write the PRU code in assembly and to use pasm.

It's really not knowing which architecture some articles are talking about, 
or not knowing the limits of the architecture that makes the PRU stuff so 
frustrating.

I thank you 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/4dfa88bc-372e-4cc5-95fa-edc0b1dd6d98n%40googlegroups.com.

[beagleboard] SOLUTION - Missing /dev/rpmsg_pru30 and /dev/rpmsg_pru31

[Bruce Chidester]

I am in the middle of struggling while introducing myself to the PRU. I 
want to contribute to the world to help some other struggling individual 
and this seems like the right place to post a solution.

I am using Beaglebone Black Rec C. 
Running the uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo defined in 
/boot/uEnv.txt

If you do not see the /dev/rpmsg_pru3* devices and you expect them, the zip 
file I have attached has a working solution to make them show up. I believe 
the solution has a lot to do with the right resource file and the PRU code. 
They will not simply just show because you have 2 PRU's. This may seem 
obvious to the more advanced PRU people, but took me a couple of weeks to 
figure this (and other things) out.

Here are my results after days of trying to figure out the magic to get the 
devices to show up:

root@beaglebone:/home/debian/rpmsg_pru# ./run.sh
rpmsg_pru30
rpmsg_pru31

Once the devices show for you:

echo "test30" > /dev/rpmsg_pru30
echo "test31" > /dev/rpmsg_pru31

cat /dev/rpmsg_pru30
 - c

cat /dev/rpmsg_pru31
 - c

-- 
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/562bed0a-c4d6-43aa-b62a-7528034cc8b6n%40googlegroups.com.
<>

Re: [beagleboard] Re: PRU Messaging

[Bruce Chidester]

Thanks for the reference...everything helps. I will digest it as well.

On Tuesday, May 25, 2021 at 1:41:32 PM UTC-5 darre...@gmail.com wrote:

> Bruce,
>
> I feel your frustration with getting familiar with PRU.  What I did, 
> working with the standard Debian that BB ships with (including updates), 
> was to start with Professor Yoder's PRUCookbook 
> <https://markayoder.github.io/PRUCookbook/>.  That at least should get 
> you going.  He has information on BBB as well as BBAI.
>
> df
>
>
> On Tue, May 25, 2021 at 11:51 AM Bruce Chidester  
> wrote:
>
>> Other? (OK)
>>
>> When I mean others, I mean other people's post on this topic seems to get 
>> the message in dmesg, and looks like everyone else seems to get them fine. 
>> I however do not.
>>
>> The "other" I refer to, for example,  is at: 
>> https://github.com/beagleboard/linux/issues/185
>>
>> Laserman, I think our ships are passing in the night. My messages do not 
>> seem to get to you properly, and not sure what to do to improve them. I 
>> apologize for any frustration I may cause.
>>
>> I may have also seemed to have found a real working example of userspace 
>> communicating back and forth with the PRU's. I am currently looking at 
>> these details if it meets my needs. I will report after looking at it. The 
>> example I am referring to is at:
>>
>> https://codedocs.xyz/pratimugale/PRUSS-Bindings/index.html
>>
>> On Tuesday, May 25, 2021 at 12:39:17 PM UTC-5 lazarman wrote:
>>
>>> Bruce
>>>
>>> What do " The Others" say is wrong?
>>>
>>> I have seen that PRU support package.
>>>
>>> In my reply last week it appears to me you have adopted what I call the 
>>> apple  and oranges approach.
>>>
>>> I'm trying to say serious but I think "the other's" were a mysterious 
>>> cult on star trek.
>>>
>>> These instructions look like they were cut out of something.
>>>
>>> It's helpful to display a copy paste from your terminal window in Linux 
>>> showing your prompt and maybe a directory list at end of / dev/.
>>>
>>> This procedure looks similar to what's in the sdk instructions but I'm 
>>> guessing your not following that. It's possible your instructions are 
>>> missing something.
>>>
>>> Let us know if " The other's" communicate back.
>>>
>>> Mark
>>>
>>>
>>> Sent from Yahoo Mail on Android 
>>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>>
>>> On Tue, May 25, 2021 at 11:47 AM, Bruce Chidester
>>>  wrote:
>>>
>>> I have a new image with 10.9 installed with an apt update; apt upgrade
>>>
>>> I wonder if my issue is around /dev/rpmsg_pru*
>>>
>>> Others suggest that after the following steps, the device shows up, but 
>>> mine does not.
>>>
>>> cd /tmp 
>>> git clone git://
>>> git.ti.com/pru-software-support-package/pru-software-support-package.git 
>>> cd 
>>> /tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 
>>> export PRU_CGT=/usr/share/ti/cgt-pru make 
>>> cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw 
>>> echo start > /sys/class/remoteproc/remoteproc1/state
>>>
>>> I do not get the message:
>>>
>>> rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: 
>>> /dev/rpmsg_pru30 
>>>
>>> and the device does not show in /dev/
>>>
>>> What is the secret to making those devices show up?
>>>
>>> On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote:
>>>
>>> Dennis,
>>>
>>> I have made a flasher and have flashed 10.9 image that you referred to 
>>> me earlier.  Re-adding everything on the system now and re-testing.
>>>
>>> Also processing the requests from Lazarman about the lab and quick start 
>>> guide.
>>>
>>> Really appreciate the help
>>>
>>>
>>> On Tuesday, May 25, 2021 at 11:20:45 AM UTC-5 Dennis Bieber wrote:
>>>
>>> On Tue, 25 May 2021 07:40:20 -0700 (PDT), in 
>>> gmane.comp.hardware.beagleboard.user Bruce Chidester 
>>>  wrote: 
>>>
>>> >*It is asking you to confirm which Beagle you are using.:* 
>>> >I am using Beaglebone Black 

Re: [beagleboard] Re: PRU Messaging

[Bruce Chidester]

Other? (OK)

When I mean others, I mean other people's post on this topic seems to get 
the message in dmesg, and looks like everyone else seems to get them fine. 
I however do not.

The "other" I refer to, for example,  is 
at: https://github.com/beagleboard/linux/issues/185

Laserman, I think our ships are passing in the night. My messages do not 
seem to get to you properly, and not sure what to do to improve them. I 
apologize for any frustration I may cause.

I may have also seemed to have found a real working example of userspace 
communicating back and forth with the PRU's. I am currently looking at 
these details if it meets my needs. I will report after looking at it. The 
example I am referring to is at:

https://codedocs.xyz/pratimugale/PRUSS-Bindings/index.html

On Tuesday, May 25, 2021 at 12:39:17 PM UTC-5 lazarman wrote:

> Bruce
>
> What do " The Others" say is wrong?
>
> I have seen that PRU support package.
>
> In my reply last week it appears to me you have adopted what I call the 
> apple  and oranges approach.
>
> I'm trying to say serious but I think "the other's" were a mysterious cult 
> on star trek.
>
> These instructions look like they were cut out of something.
>
> It's helpful to display a copy paste from your terminal window in Linux 
> showing your prompt and maybe a directory list at end of / dev/.
>
> This procedure looks similar to what's in the sdk instructions but I'm 
> guessing your not following that. It's possible your instructions are 
> missing something.
>
> Let us know if " The other's" communicate back.
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, May 25, 2021 at 11:47 AM, Bruce Chidester
>  wrote:
>
> I have a new image with 10.9 installed with an apt update; apt upgrade
>
> I wonder if my issue is around /dev/rpmsg_pru*
>
> Others suggest that after the following steps, the device shows up, but 
> mine does not.
>
> cd /tmp 
> git clone git://
> git.ti.com/pru-software-support-package/pru-software-support-package.git 
> cd 
> /tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 
> export PRU_CGT=/usr/share/ti/cgt-pru make 
> cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw 
> echo start > /sys/class/remoteproc/remoteproc1/state
>
> I do not get the message:
>
> rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30 
>
> and the device does not show in /dev/
>
> What is the secret to making those devices show up?
>
> On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote:
>
> Dennis,
>
> I have made a flasher and have flashed 10.9 image that you referred to me 
> earlier.  Re-adding everything on the system now and re-testing.
>
> Also processing the requests from Lazarman about the lab and quick start 
> guide.
>
> Really appreciate the help
>
>
> On Tuesday, May 25, 2021 at 11:20:45 AM UTC-5 Dennis Bieber wrote:
>
> On Tue, 25 May 2021 07:40:20 -0700 (PDT), in 
> gmane.comp.hardware.beagleboard.user Bruce Chidester 
>  wrote: 
>
> >*It is asking you to confirm which Beagle you are using.:* 
> >I am using Beaglebone Black Revision C 
> > 
> > 
> >*It will be much quicker to do an apt update/aptupgrade.:* 
> >I performed the update/upgrade and /etc/dogtag still reports the same 
> info. 
> >Should I get a newer image? Is the issue my distro? 
> > 
>
> I don't think the "dogtag" gets updated from repositories. It likely 
> just identifies the original image burned to the memory. 
>
> debian@beaglebone:~$ uname -a 
> Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55 
> UTC 2020 armv7l GNU/Linux 
> debian@beaglebone:~$ cat /etc/dogtag 
> BeagleBoard.org Debian Buster IoT Image 2020-08-19 
> debian@beaglebone:~$ 
>
> I've been doing apt update/apt upgrade at least monthly since writing that 
> image. 
>
>
>
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
>
>
> https://groups.google.com/d/msgid/beagleboard/e55624c8-a8b1-4306-903c-5236174b53c1n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/e55624c8-a8b1-4306-903c-5236174b5

[beagleboard] Re: PRU Messaging

[Bruce Chidester]

I have a new image with 10.9 installed with an apt update; apt upgrade

I wonder if my issue is around /dev/rpmsg_pru*

Others suggest that after the following steps, the device shows up, but 
mine does not.

cd /tmp 
git clone 
git://git.ti.com/pru-software-support-package/pru-software-support-package.git 
cd 
/tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 
export PRU_CGT=/usr/share/ti/cgt-pru make 
cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw 
echo start > /sys/class/remoteproc/remoteproc1/state

I do not get the message:

rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30 

and the device does not show in /dev/

What is the secret to making those devices show up?

On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote:

> Dennis,
>
> I have made a flasher and have flashed 10.9 image that you referred to me 
> earlier.  Re-adding everything on the system now and re-testing.
>
> Also processing the requests from Lazarman about the lab and quick start 
> guide.
>
> Really appreciate the help
>
>
> On Tuesday, May 25, 2021 at 11:20:45 AM UTC-5 Dennis Bieber wrote:
>
>> On Tue, 25 May 2021 07:40:20 -0700 (PDT), in
>> gmane.comp.hardware.beagleboard.user Bruce Chidester
>>  wrote:
>>
>> >*It is asking you to confirm which Beagle you are using.:*
>> >I am using Beaglebone Black Revision C
>> >
>> >
>> >*It will be much quicker to do an apt update/aptupgrade.:*
>> >I performed the update/upgrade and /etc/dogtag still reports the same 
>> info.
>> >Should I get a newer image? Is the issue my distro?
>> >
>>
>> I don't think the "dogtag" gets updated from repositories. It likely
>> just identifies the original image burned to the memory.
>>
>> debian@beaglebone:~$ uname -a
>> Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
>> UTC 2020 armv7l GNU/Linux
>> debian@beaglebone:~$ cat /etc/dogtag
>> BeagleBoard.org Debian Buster IoT Image 2020-08-19
>> debian@beaglebone:~$
>>
>> I've been doing apt update/apt upgrade at least monthly since writing that
>> image.
>>
>>
>>
>>
>> -- 
>> 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/e55624c8-a8b1-4306-903c-5236174b53c1n%40googlegroups.com.

[beagleboard] Re: PRU Messaging

[Bruce Chidester]

Dennis,

I have made a flasher and have flashed 10.9 image that you referred to me 
earlier.  Re-adding everything on the system now and re-testing.

Also processing the requests from Lazarman about the lab and quick start 
guide.

Really appreciate the help


On Tuesday, May 25, 2021 at 11:20:45 AM UTC-5 Dennis Bieber wrote:

> On Tue, 25 May 2021 07:40:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
>  wrote:
>
> >*It is asking you to confirm which Beagle you are using.:*
> >I am using Beaglebone Black Revision C
> >
> >
> >*It will be much quicker to do an apt update/aptupgrade.:*
> >I performed the update/upgrade and /etc/dogtag still reports the same 
> info.
> >Should I get a newer image? Is the issue my distro?
> >
>
> I don't think the "dogtag" gets updated from repositories. It likely
> just identifies the original image burned to the memory.
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
> UTC 2020 armv7l GNU/Linux
> debian@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org Debian Buster IoT Image 2020-08-19
> debian@beaglebone:~$
>
> I've been doing apt update/apt upgrade at least monthly since writing that
> image.
>
>
>
>
> -- 
> 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/855a947e-f27d-433a-9d64-679e3c706959n%40googlegroups.com.

[beagleboard] Re: PRU Messaging

[Bruce Chidester]

*It is asking you to confirm which Beagle you are using.:*
I am using Beaglebone Black Revision C


*It will be much quicker to do an apt update/aptupgrade.:*
I performed the update/upgrade and /etc/dogtag still reports the same info.
Should I get a newer image? Is the issue my distro?

On Monday, May 24, 2021 at 3:01:50 PM UTC-5 Dennis Bieber wrote:

> On Mon, 24 May 2021 10:25:57 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
>  wrote:
>
>
> >*2 This is the BB AI correct?*
> >I do not know what this question means..please clarify. 
> >
>
> It is asking you to confirm which Beagle you are using.
>
> > 
> >*4 What is your ARM OS and version. Compiler host details*
> >BeagleBoard.org Debian Buster IoT Image 2020-04-06, 4.19.94-ti-r42. A 
> >fresh release from https://beagleboard.org/latest-images
> >
> Unfortunately, that is a year out of date... It's basically the image
> that was shipped on new boards (to my knowledge the "testing" images don't
> get shipped). Doing an apt update/apt upgrade will take lots of space
> staging the files, and quite some time (it is Debian 10.3, and Debian is
> now at 10.9)
>
> You might want to grab one of the images at
> https://rcn-ee.net/rootfs/bb.org/testing/2021-04-27/ (buster is Debian 10,
> stretch is prior Debian 9). It will be much quicker to do an apt update/apt
> upgrade.
>
> Unfortunately you trimmed the description so that the question of board
> is still open.
>
> AM3358 (now seen as "bone-debian..." in "testing") is for Beaglebone
> BLACK/GREEN and other clones. AM57829 (seen as am57xx in testing) are for
> the BB-AI (Beaglebone Artifical Intelligence) and X-15 boards.
>
>
> -- 
> 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/a3d30a79-992c-4ba4-8004-846c4035b27dn%40googlegroups.com.

Re: [beagleboard] Re: PRU Messaging

[Bruce Chidester]

*1 Most important what's it doing?*
The original post was a link to all the code.  It is 
at: https://gitlab.com/brucechidester/pru-messaging-example
The Readme.txt file explains what I would like the solution to do.
 
*2 This is the BB AI correct?*
I do not know what this question means..please clarify. 

*3 Where did this code come from?*
I wrote this code from other examples attempting to get it to work. 
 
*4 What is your ARM OS and version. Compiler host  details*
BeagleBoard.org Debian Buster IoT Image 2020-04-06,  4.19.94-ti-r42.  A 
fresh release from https://beagleboard.org/latest-images
 
*5 Brief Summary of what you tried  with important details(start from 5 and 
work backwards trying to keep it clear and concise)*
I was trying several examples from everywhere and I cannot get any 
messaging example to work.  The TI messaging examples that they provide do 
not include the application code that interacts with the PRU messaging. The 
UIO to Remote Proc change has made many of the examples out of date and it 
is getting frustrating trying to figure out the correct solution for the 
latest disto for the BBB. 

On Monday, May 24, 2021 at 12:13:30 PM UTC-5 lazarman wrote:

> Hello Bruce in my opinion your missing some things important 
>
> 1 Most important what's it doing?
> 2 This is the BB AI correct?
> 3 Where did this code come from?
> 4 What is your ARM OS and version. Compiler host  details
> 5 Brief Summary of what you tried  with important details(start from 5 and 
> work backwards trying to keep it clear and concise)
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 24, 2021 at 10:44 AM, Bruce Chidester
>  wrote:
>
> Maybe some code in the post will promote some response:
>
> *Main Application:*
>
> #include  
> #include  
> #include  
> #include  
> #include  
> #include  
> #include  
> #define DEVICE_NAME "/dev/rpmsg_pru30" 
> int main(int argc, char* argv[]) { 
>int result = 0; 
>struct pollfd pollfds[1]; 
>pollfds[0].fd = open(DEVICE_NAME, O_RDWR); 
>if (pollfds[0].fd < 0) { 
>   printf("Failed to open %s\n", DEVICE_NAME); 
>   return -1; 
>} 
>/* Send 'hello world!' to the PRU through the RPMsg channel */ 
>result = write(pollfds[0].fd, "hello world!", 13); 
>while (1) {
>   prussdrv_pru_wait_event(PRU_EVTOUT_0); 
>   printf("Responding to interrupt\n"); 
>   prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); 
>} 
>return 0; 
> } 
>
> *PRU Code:*
>
> #include  
> #include  
> #include  
> #include "resource_table_empty.h" 
> volatile register uint32_t __R30; 
> volatile register uint32_t __R31; 
> #define PRU_ARM_INTERRUPT 19 
> #define HOST_NUM 2 
> #define CHAN_NUM 2 
> #define PRU_ARM_INTERRUPT_PULSE 0x23 
> #define HOST_INT ((uint32_t) 1 << 31) 
> // PRU Interrupt control registers 
> #define PRU_INTC 0x0002 
> // Start of PRU INTC registers TRM 4.3.1.2 
> #define PRU_INTC_GER ((volatile uint32_t *)(PRU_INTC + 0x10)) 
> // Global Interrupt Enable, TRM 4.5.3.3 
> #define PRU_INTC_SICR ((volatile uint32_t *)(PRU_INTC + 0x24)) 
> // Interrupt, TRM 4.5.3.6 
> #define PRU_INTC_GPIR ((volatile uint32_t *)(PRU_INTC + 0x80)) 
> // Interrupt, TRM 4.5.3.11 
> void main(void) { 
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ 
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; 
> // Globally enable host interrupts 
> CT_INTC.GER = 0x1; 
> /* Clear any pending PRU-generated events */ 
> __R31 = 0x; 
> /* Enable Host interrupt 2 */ 
> CT_INTC.HIEISR |= HOST_NUM; 
> //Enable the system event to be propagated through the INTC 
> CT_INTC.EISR |= PRU_ARM_INTERRUPT; 
> /* Map channel 2 to host 2 */ 
> CT_INTC.HMR0_bit.HINT_MAP_2 = CHAN_NUM; 
> /* Map PRU0_ARM_INTERRUPT (event 19) to channel 2 */ 
> CT_INTC.CMR4_bit.CH_MAP_19 = CHAN_NUM; 
> /* Ensure PRU_ARM_INTERRUPT is cleared */ 
> CT_INTC.SICR = PRU_ARM_INTERRUPT; 
> volatile uint32_t gpio; 
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ 
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; 
> gpio = 0x000F; 
> while (!(__R31 & HOST_INT)) { 
> } 
> while (1) { 
>__R30 ^= gpio; 
>__delay_cycles(10); 
>__R31 = PRU_ARM_INTERRUPT_PULSE; 
>// Clear interrupt 
>CT_INTC.SICR = 15; 
>} 
> } 
>
> On Sunday, May 23, 2021 at 2:10:24 PM UTC-5 Bruce Chidester wrote:
>
> 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 can

[beagleboard] Re: PRU Messaging

[Bruce Chidester]

Maybe some code in the post will promote some response:

*Main Application:*

#include  
#include  
#include  
#include  
#include  
#include  
#include  
#define DEVICE_NAME "/dev/rpmsg_pru30" 
int main(int argc, char* argv[]) { 
   int result = 0; 
   struct pollfd pollfds[1]; 
   pollfds[0].fd = open(DEVICE_NAME, O_RDWR); 
   if (pollfds[0].fd < 0) { 
  printf("Failed to open %s\n", DEVICE_NAME); 
  return -1; 
   } 
   /* Send 'hello world!' to the PRU through the RPMsg channel */ 
   result = write(pollfds[0].fd, "hello world!", 13); 
   while (1) {
  prussdrv_pru_wait_event(PRU_EVTOUT_0); 
  printf("Responding to interrupt\n"); 
  prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); 
   } 
   return 0; 
} 

*PRU Code:*

#include  
#include  
#include  
#include "resource_table_empty.h" 
volatile register uint32_t __R30; 
volatile register uint32_t __R31; 
#define PRU_ARM_INTERRUPT 19 
#define HOST_NUM 2 
#define CHAN_NUM 2 
#define PRU_ARM_INTERRUPT_PULSE 0x23 
#define HOST_INT ((uint32_t) 1 << 31) 
// PRU Interrupt control registers 
#define PRU_INTC 0x0002 
// Start of PRU INTC registers TRM 4.3.1.2 
#define PRU_INTC_GER ((volatile uint32_t *)(PRU_INTC + 0x10)) 
// Global Interrupt Enable, TRM 4.5.3.3 
#define PRU_INTC_SICR ((volatile uint32_t *)(PRU_INTC + 0x24)) 
// Interrupt, TRM 4.5.3.6 
#define PRU_INTC_GPIR ((volatile uint32_t *)(PRU_INTC + 0x80)) 
// Interrupt, TRM 4.5.3.11 
void main(void) { 
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ 
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; 
// Globally enable host interrupts 
CT_INTC.GER = 0x1; 
/* Clear any pending PRU-generated events */ 
__R31 = 0x; 
/* Enable Host interrupt 2 */ 
CT_INTC.HIEISR |= HOST_NUM; 
//Enable the system event to be propagated through the INTC 
CT_INTC.EISR |= PRU_ARM_INTERRUPT; 
/* Map channel 2 to host 2 */ 
CT_INTC.HMR0_bit.HINT_MAP_2 = CHAN_NUM; 
/* Map PRU0_ARM_INTERRUPT (event 19) to channel 2 */ 
CT_INTC.CMR4_bit.CH_MAP_19 = CHAN_NUM; 
/* Ensure PRU_ARM_INTERRUPT is cleared */ 
CT_INTC.SICR = PRU_ARM_INTERRUPT; 
volatile uint32_t gpio; 
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ 
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; 
gpio = 0x000F; 
while (!(__R31 & HOST_INT)) { 
} 
while (1) { 
   __R30 ^= gpio; 
   __delay_cycles(10); 
   __R31 = PRU_ARM_INTERRUPT_PULSE; 
   // Clear interrupt 
   CT_INTC.SICR = 15; 
   } 
} 

On Sunday, May 23, 2021 at 2:10:24 PM UTC-5 Bruce Chidester wrote:

> 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: https://gitlab.com/brucechidester/pru-messaging-example
>
> In summary, it is the smallest possible example where the application code 
> sends an interrupt (or message) to the PRU and the PRU sends an interrupt 
> every second (with a GPIO pulse). Every time the pulse is sent from the 
> PRU, the main application prints a message.
>
> 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/176deb85-62a7-4370-890a-c7ae7873d168n%40googlegroups.com.

[beagleboard] PRU Messaging

[Bruce Chidester]

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: https://gitlab.com/brucechidester/pru-messaging-example

In summary, it is the smallest possible example where the application code 
sends an interrupt (or message) to the PRU and the PRU sends an interrupt 
every second (with a GPIO pulse). Every time the pulse is sent from the 
PRU, the main application prints a message.

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/6a371767-2ae2-4ee8-ae8b-eed2d9aebca9n%40googlegroups.com.

[beagleboard] Re: Shared PRU Memory and beyond

[Bruce Chidester]

  Not sure I am replying properly to preserve the format desired for this 
page, but your (Dennis B) response definitely deserves a response from me.

On Monday, May 17, 2021 at 12:39:53 PM UTC-5 Dennis Bieber wrote:

> On Mon, 17 May 2021 07:50:02 -0700 (PDT), in 
> gmane.comp.hardware.beagleboard.user Bruce Chidester 
>  wrote: 
> >This leaves me with a total memory of 28K. Storing float's I can store 
> >7,168 values. I would like to capture 20,000 values in about 250ms. 
>
> Capture from what? 
>
> 80 samples/msec... or 8 per second. If I converted properly, about 
> 0.0125msec per sample. 
>
> I will be sampling from an ADC up to 1MHz maybe. 

> > 
> >The Derek Malloy tutorial on PRU's ( 
> >http://exploringbeaglebone.com/chapter15/) claims, "a pool of 2,000,000 
> >bytes is allocated for the sample data". Things appear to have changed 
> >since the writing of that tutorial. No more dynamic Device Tree through 
> UIO 
>
> The tutorial you reference is based upon the FIRST EDITION of the book 
> "Additional Content for First Edition" (when it was chapter 13). 
>
> Does the second addition contain the updates to the remote proc process?

>and PRU's accessed through Remote Proc. Not sure if the architecture 
>
> Device trees are now loaded by u-Boot. If you really want UIO, there is 
> a device tree for that... By default, current images use the TI 
> recommended 
> RPROC/msg system (partly because that is supposed to work with multiple 
> types of special processor cores -- the BB AI not only has PRU, but DSP 
> processors). 
>
> Thanks for the DSP lead...that is awesome as well.
 

> Extract from /boot/uEnv.txt: 
>
> ###PRUSS OPTIONS 
> ###pru_rproc (4.14.x-ti kernel) 
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo 
> ###pru_rproc (4.19.x-ti kernel) 
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo 
> ###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel) 
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo 
> ### 
>
> You would have to uncomment the UIO line, and comment out the active 
> RPROC line (only one mode allowed at a time); then reboot. 
>
> This is awesome and definitely gives me something to work with
 

> >changed as well. This makes most of the printed material out of date 
> >concerning PRU's and it's painful to figure out what is current and not. 
> I 
> >would love to have these 2,000,000 bytes available in the new 
> architecture. 
>
> Note that those bytes are allocated in the DDR RAM. There is no 
> hardware change. 
>
> Glad to know the HW did not change. 

>
> >Needing help with the addressing, and some code samples would be 
> excellent. 
> >Hoping someone out there can help me get it. 
> > 
>
> Might https://github.com/pgmmpk/bbb_pru_adc be of use? Note that the 
> maximum speed for that code is 15KHz, or just 1/5th of your 80KHz desire. 
>
>
>
> I'll take a look 

> -- 
> 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/b1cdec6f-2b99-4d31-9eea-d537339c6cecn%40googlegroups.com.

[beagleboard] Shared PRU Memory and beyond

[Bruce Chidester]

Currently working with the Beaglebone Black Rev C and the PRU has the 
following arrangement:

PRU0 = 8k RAM, PRU1 = 8k RAM, and 12k RAM Shared



I have successfully been able to have one PRU access its own 8K, the other 
PRU's 8K, and the shared 12K.

This leaves me with a total memory of 28K. Storing float's I can store 
7,168 values. I would like to capture 20,000 values in about 250ms.

The Derek Malloy tutorial on PRU's (
http://exploringbeaglebone.com/chapter15/) claims, "a pool of 2,000,000 
bytes is allocated for the sample data". Things appear to have changed 
since the writing of that tutorial. No more dynamic Device Tree through UIO 
and PRU's accessed through Remote Proc. Not sure if the architecture 
changed as well. This makes most of the printed material out of date 
concerning PRU's and it's painful to figure out what is current and not. I 
would love to have these 2,000,000 bytes available in the new architecture. 
Needing help with the addressing, and some code samples would be excellent. 
Hoping someone out there can help me get it.

Question: Is there a way, technique, or resources that can be applied to 
allow me to do this? Remember, 20,000 samples in 250ms when providing a 
response.

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/01eb7738-1f04-4c4d-9e64-6be92888f458n%40googlegroups.com.