On Monday, 20 February 2017 01:51:53 UTC+1, ags wrote:
>
> Is it correct that whenever the PRU cores access any resource through the
> 32-bit system but, it is subject to varying delay since the other PRU core
> and even the ARM core (through the OCP slave, for instance if the ARM is
> pushing
tl;dr
Is it correct that whenever the PRU cores access any resource through the
32-bit system but, it is subject to varying delay since the other PRU core
and even the ARM core (through the OCP slave, for instance if the ARM is
pushing data to the PRU 8k or 12k DRAM) may also be contending for
I have a project down the road that will require fast writes from PRU to
ARM/system DRAM. But I'm not there yet.
For this project, my focus is on reading data (from SD card, eMMC, USB
stick, network, etc) into DDR and then pushing it to the PRUs and then
bit-bang out precise timing (using
On 2/9/2017 8:42 PM, William Hermans wrote:
>
> But the point is really this. If you need to get data out of the PRU's into
> userland Linux as quickly as possible. Maybe the way to pull that data ot of
> the
> PRU's memory is from the ARM(Linux ) side of things ?
No, you want to have the PRU
Anyway, my idea was something like this. In the past I've written a couple
different applications that have directly accessed peripherals registers
through mmap() + /dev/mem/. So I would imagine( again no hands on here )
accessing the PRU's memory directly from user space Linux could be
On Thu, Feb 9, 2017 at 6:56 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:
>You cannot "broadside" store the register file into the 8k or 12k data
>
> rams, only into one of the three scratch pad locations or directly
> into the other PRU's register file. Table 4-21 (of the AM335x
On 2/9/2017 7:37 PM, William Hermans wrote:
> However, the 8k memory used by each PRU core, as well as the shared 12k
> memory
> each PRU has access to is supposed to be single cycle read / write access. In
> fact each PRU core as I understand it has the ability to "broadside" all of
> it's
>
On Thu, Feb 9, 2017 at 4:20 PM, ags wrote:
> Continued review of documentation has caused me to wonder if I've missed a
> fundamental error in my thinking about what is and isn't deterministic when
> using the PRUs. The PRU-local 32-bit interconnect bus is itself a
Continued review of documentation has caused me to wonder if I've missed a
fundamental error in my thinking about what is and isn't deterministic when
using the PRUs. The PRU-local 32-bit interconnect bus is itself a shared
resource. If one PRU writes to its own DRAM, and the other PRU writes