[beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-03-31 Thread Matthijs van Duin
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

[beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-19 Thread ags
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

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-16 Thread ags
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

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-10 Thread Charles Steinkuehler
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

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-09 Thread William Hermans
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

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-09 Thread William Hermans
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

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-09 Thread Charles Steinkuehler
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 >

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-09 Thread William Hermans
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

[beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

2017-02-09 Thread ags
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