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.
On Mon, 17 May 2021 07:50:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
<brucechidester-Re5...@public.gmane.org> 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 80000 per second. If I converted properly, about
0.0125msec per sample.
>
>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).
>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).
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.
>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.
>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.
--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/v2u5ag1dlpbh5fkli20unvb8d8a2b254o3%404ax.com.
On Tue, May 18, 2021 at 1:42 PM, Walter Cromer<wal...@edenconceptsllc.com> wrote:
Regardless of the timing, you want to store 20,000 values but I think you've calculated correctly that you can only store 7,168 values in the 28k of combined PRU memory and that would only be true if some of the PRU memory wasn't used by your PRU program when it's loaded.So are you trying to find a way to store the data back in the main host memory instead?
Remoteproc/RPMSG can send the data back but I don't think it's fast enough for you. I'm doing that now with code written in C. (It was a bear to learn and get going but I'm a rusty guy too. ) I am reading 12-bit AD with the onboard ADC (Touchscreen controller in general-purpose mode). I@TJF on this forum promotes a solution called libpruio that might work. I don't know if it's fast enough though. saw one post on the TI E2E forum that indicated that Remoteproc/RPMSG is not intended to be a fast data transfer mechanism. That was by a TI engineer I think.
The only alternative I can think of is declaring variables in your PRU code whose address is actually in the main host memory (Linux) space. I've tried to do this using the example in Mark Yoder's PRU Cookbook but I could not get it to work. I decided that I didn't really need that and went another route.
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
... maybe TJF will reply.