Bill: If you are on the clock edge, and by definition all transitions occur on the clock edges, and most data is clocked in on a clock edge. Then a slight drift in power supply voltage or temperature can change things a few nano seconds, and you will move ahead or back one count. You are living on the edge so to speak. Or, if you can, throw an inverter in the external clock line between the source and measurement PRU, so they run a half clock cycle apart. If you can't fix it, break it big.
If you read the spec on a frequency counter, you see an accuracy spec, and a disclaimer plus/minus one count to deal with these effects. You really see it if you try to measure a counter's time base with the same counter. --- Graham == On Wed, Dec 23, 2015 at 4:02 PM, Bill Gray <[email protected]> wrote: > 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 instruction. The +-1 > thing is not going to be a problem from an application perspective, I just > want to know what is going on so that I can properly account for it. > > There are a number of things that it could be, but a phase shift seems > like the best fit at this point. > > I thought about the notion that we are on the same clock edge, but that > doesn't fit quite right in my mind. If things were truly on the same clock > edge... or even 2ps off, then given that everything is running in the same > way every time, that 2ps should hit and get registered the same way each > time. It just doesn't make sense that it is dancing this way and that... > or at least that doesn't make sense given what I know about how > microcontrollers work. Perhaps there is more to the story than I am aware > of. > > B > > > On Wednesday, December 23, 2015 at 1:44:00 PM UTC-8, Graham wrote: >> >> 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 generate and measure on the same clock edges. Very >> tiny time shifts can move you a whole clock cycle. >> --- Graham >> >> == >> >> >> On Wednesday, December 23, 2015 at 1:27:22 PM UTC-6, Bill Gray wrote: >>> >>> 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 a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/zhCplP-SEok/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
