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 Mittwoch, 23. Dezember 2015 20:27:22 UTC+1 schrieb Bill Gray: > > Hi, > > I am trying to debug a weird behavior. > > I have code running on PRU 1 that creates a specific waveform on 8 pru > output pins (pru1_0 - pru1_7). > > I am trying to confirm the accuracy of my PRU 1 code by running code on > PRU 0 that watches the pins on PRU 1 (physically linked) and measures their > period, duty, etc. against the CYCLE counter in the PRU0 control register. > > All is well and good except that some of my measurements are off by +-1 > instruction... so where I hope to see 1280 instructions in a period, I am > seeing 1279 or 1281. > > Interestingly this changes... apparently regularly? If I take the same > measurement over and over I will get measurements for about 2 seconds > where the result is -1 and then 2 seconds of measurements where the result > is +1... then back to -1, etc. > > One explanation for this is that there is a slight phase shift between the > PRU1 and PRU0 clocks. > > ...But that goes against my understanding that the PRU clocks are both > derived directly from the main CPU clock. > > Still, the phase shift explanation fits the data really really nicely. > > Is a phase shift between the PRU clocks even possible? > > Thanks, > > Bill > > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
