Hello and thank you for the fast help. Here my answers for your comments:
Unless you carefully write kernel code to treat your DDR memory buffer > as DMA memory, you are almost certainly encountering caching effects. > I thought to have this done by getting the memory space from dma_alloc_coherent(). I will research if there is more needed to disable the caching but my understanding was that a DMA flagged space will never be cached because the ARM core can not know if something has changed. > I recommend instead of using a buffer in DDR memory, use the PRU data memories. As to my tests, writing from the PRU to the DDR memory only requires 3 cycles on the PRU and not more on a few million tries (L3 fast interconnect). However I do not know how long it takes for this memory to be available at the ARM... I can not do all work in the PRU code because I need to tag the rising edge with the Linux Kernel time. Therefore I need to find out the most deterministic way to get the counter value into the Kernel. I will do further tests. Maybe there is someone here who experienced the same road. I think tagging an event with the PRU (5ns) and set it into relation to Linux Kernel Time without losing to much nanoseconds should be one of the great PRU benefits. Thanks all -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
