There should be no shift between both PRUs clocks.
Other possibilities: are your PRUs communicating with each other or with
the main application e.g. via PRU shared RAM? In this case it may be
possible there are some wait states necessary to synchronise in case of
parallel accesses.
Am
You should really have your test equipment running in a different clock
domain than your device under test, and then trigger off your unit under
test.
Very small phase or time differences between the unit under test and the
test equipment can lead to major data differences.
You are trying to
Thanks Graham.
Yeah, I know. The thing is that having the two share the same chip makes
things really fast. In my app I need to make about 125M different
measurements, so the difference between a 1ms test and a 10ms makes a huge
difference.
In fact, I don't need accuracy down to a single
Thanks so much guys.
The suggestion of using two BBB is great for getting the test program off
the same clock domain. The issue there for me is speed. The easy way to
get two BBBs working together would be to have them talk via ethernet.
This would be quite slow compared to my current setup
Bill:
I don't think the PRU clocks are externally available.
I don't know what your interface looks like, but if there was a clock line
involved in the data transfer, or marking when data is valid, I would look
at inverting or adding some delay in that line going to the receiving PRU.
If your
On 12/23/2015 5:17 PM, Bill Gray wrote:
> Fascinating! Thanks guys.
>
> Graham,
> Frequency counting is exactly what I am trying to here, and +-1 is exactly
> what I am seeing, so that makes perfect sense. I was not aware that the PRU
> clocks were physically available on the BBB! What fun!
Fascinating! Thanks guys.
Graham,
Frequency counting is exactly what I am trying to here, and +-1 is exactly
what I am seeing, so that makes perfect sense. I was not aware that the PRU
clocks were physically available on the BBB! What fun! Where can I find
the leads to mess with? Perhaps I
Could you use a second BBB as the capture device instead? That would isolate
the PRUs from each other and possibly allow for the HW capture that was
mentioned.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
