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 overclock them? Oh the possibilities!
Charles, I'm not sure that I am understanding your suggestions correctly. I think that the hardware timers present a couple of problems. Please correct me where I am wrong. First, I think they run at max 25Mhz, so they have a resolution of 40nS, this is 4x worse than the +-5nS resolution I'm currently getting using my CYCLE clock scheme... clock edge problems included. Also, and perhaps more importantly, I need to measure the phase shift between the waveform on various pins and so I would need to start and stop the hardware timer with 2 different signals. Is this possible? Simple? My uniformed instinct is hard and slow. I'm also interested in the Ethernet "wall clock" idea. I just read up on it, and it seems to be another 200Mhz clock, just like the CYCLE counter. I'm under the impression that the CYCLE counter does not stall (that is what the STALL counter is for) and so I'm not sure what the ethernet counter would provide... if I needed a second counter it would be super great, but for this app one is enough. Thanks again, Bill On Wednesday, December 23, 2015 at 2:37:43 PM UTC-8, Charles Steinkuehler wrote: > > Have you looked at the wall clock differences, or just the number of > instructions executed as a proxy for the time taken? It's possible > for PRU instructions to stall (accessing resources outside the PRU > domain, or when both PRU cores try to access the same resource). So > you might be seeing a timing effect (real-world signal propagation > time between the two PRU cores moving forward/backward a clock edge), > or you may be running a different number of instructions in the same > amount of time. Or both. > > You can use the Ethernet timer in the PRU as a "wall clock" that is > unaffected by any PRU instruction stalls, but if you're wanting to > rapidly and accurately measure time periods, use the hardware timers > in capture mode. That's what they're for, and you'll have single > clock cycle accuracy. The PRU will always have at least a few > instructions of uncertainty since it takes more than one instruction > to sample the value and capture the current "time". > > On 12/23/2015 4:02 PM, Bill Gray 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 > >>> > >>> > >>> > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- 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.
