First thanks for your reply.
So to answer your question, I try to load a data every 25ns.
I have few questions regarding your reply :
- Can I write into the PRU memory form a C program on the ARM side at
that can of speed ? (because for now I have succeeded at least)
- In addition does your solution can load several data at the same
time as I do with the propriety of the register R30 of the PRU ?
- Also the fact, is I am also reading data at the same time (I didn't
tell you about it previously in order to be clearer)., so can I do so with
the solution "C program on the ARM side do the writing into the PRU memory
ring-buffer" ? Maybe that it would be more easy with your DDR memory
solution ?
- Moreover, I didn't new that the PRU got a Ring buffer, is it link with
the section 4.4.1.2.3.3 28-Bit Shift In of the Technical reference manual,
or is it something else ?
- Also the fact with your solution with the DDR memory is that to load a
data from there I have also observed some huge delay with the LBBO command.
Or it's just me who have done something wrong ?
Thanks again for your answer.
Regards
Vincent
On Thursday, 23 June 2016 16:02:49 UTC+2, Charles Steinkuehler wrote:
>
> On 6/23/2016 8:55 AM, Charles Steinkuehler wrote:
> > On 6/23/2016 5:55 AM, Vincent lc wrote:
> >> Hello,
> >>
> >> *So, I would to know I someone new a quickest/easiest way to send more
> than 8k
> >> data into the PRU ?*
> >
> > There are lots of different ways you can do this. I'd probably put
> > the 24K of data into DDR memory (the PRUSS driver allocates a chunk of
> > memory you can use for this), use one of the PRUs to move the bulk
> > data to a PRU local ring buffer in the 12K shared PRU data memory, and
> > use the second PRU to do whatever it is you need to do with the data.
> >
> > This assumes you don't need both PRUs for your task.
>
> Thinking about this a bit more, it's probably easier to just have a C
> program on the ARM side do the writing into the PRU memory
> ring-buffer. That leaves both PRUs available, and should be easier to
> code as well. The only drawback is the ARM side code can get
> interrupted by the kernel for potentially a long time (hundreds of
> milliseconds on a non-real-time kernel). You don't mention your data
> rate requirement (other than it's faster than "seconds), but a
> standard kernel should work if your 12K buffer holds about 0.2 seconds
> worth of data. If the 12K buffer represents less time than that, you
> will probably need a PREEMPT_RT (easiest) or Xenomai kernel to
> guarantee the ARM side will keep up.
>
> --
> Charles Steinkuehler
> [email protected] <javascript:>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/c0737590-4b25-49d6-a347-0f9d00832475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
