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! Where can I find > the leads to mess with? Perhaps I could overclock them? Oh the > possibilities!
The PRU clock is not available outside the chip. It is driven by an internal PLL (see the TRM sections 8 and 15 for details). > 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. The eCAP timers are in the PD_PER_L4LS_GCLK domain, which typically runs at 100 MHz. So you should have the same or better timing granularity as with the PRU. Yes, the PRU runs at 200 MHz, but you need at least a 2 instruction inner loop, which has a maximum effective frequency of 100 MHz. To use the hardware timers, refer to section 15.3 of the AM335x Technical Reference Manual (TRM), which shows how you can configure the eCAP timer to measure pulse timings. I suspect one of the methods shown in section 15.3.3.x will do what you need. Also note that in addition to the "standard" eCAP modules connected to the ARM core (referred to above), there is a dedicated eCAP module in the PRU domain which you might find easier to deal with (since you're writing PRU code for this already). The documentation is a bit fuzzy on the clock for the PRU eCAP module (or I didn't find the correct page/section). But it should be at least 100 MHz, and might even run at the 200 MHz PRU clock rate. Regardless, it's a *LOT* easier to measure pulse timing using hardware designed for that purpose vs. writing code and dedicating an entire PRU core to just measuring edges. And fortunately, the AM3358 is aimed at industrial control so it has several fancy timers (and capture/compare units, and quadrature encoder inputs, and PWM outputs, and other great stuff!) ready for you to use! :) -- Charles Steinkuehler char...@steinkuehler.net -- 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.
