Hello,
I am using a Beaglebone Black. When i measured the number of PRU clock
cycles needed for the execution of various assembler instructions, I found
surprisingly large values for memory access. Here follows a list, in which
one cycle corresponds to a delay of 5ns as expected:
Most operati
On 1/3/2014 7:05 PM, Lenny wrote:
>
> Can anybody confirm the long DDR (and other delays if possible) readout
> times that I have measured? Does anybody have an explanation for these
> large delays?
Yes, I did some testing of the read and write latency to GPIO pins, the
results are in my PRU so
Thanks a lot. These delays are quite disappointing. Is it possible to
shorten these delays by using e.g. DMA to transfer data from a peripheral
(in my case the TSC_ADC) directly to PRU memory?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you
On 1/5/2014 3:50 PM, Lenny wrote:
> Thanks a lot. These delays are quite disappointing. Is it possible to
> shorten these delays by using e.g. DMA to transfer data from a peripheral
> (in my case the TSC_ADC) directly to PRU memory?
It should be possible to DMA into the PRU data memory, and ind
Charles great answer
Lenny - rule of thumb is if you have to go outside of the PRU, it will be
both slow and non-deterministic because you have to go over the l3
interconnect. Because of this if you need tight timing behavior you should
not make any outside-of-pru memory accesses. I got arou
Very nice findings!
Do you have a broader list of instructions and their duration?
And/or is there any official or unofficial documentation where these delays
could be taken from?
Also, you mentioned the PRU DRAM only - does it take the same time for the
shared memory?
Thanks a lot!
--
For more
