[time-nuts] Frequency counter questions
jimlux at earthlink.net
Tue Apr 25 08:53:07 EDT 2017
On 4/25/17 4:42 AM, Bob kb8tq wrote:
>> On Apr 25, 2017, at 1:24 AM, Orin Eman <orin.eman at gmail.com> wrote:
>> On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <kb8tq at n1k.org> wrote:
>>>> On Apr 24, 2017, at 6:54 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>>> kb8tq at n1k.org said:
>>>>> You have a “gate” from the GPSDO and a “signal” from somewhere else. If
>>>>> want the STM to do the whole thing, the “gate” pin needs to get the job
>>>>> in X +/- 1 cycles of the “signal” pin. Delay X (if it’s consistent)
>>>>> a problem. Having a
>>>>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
>>>>> MCU may or may not be able to hit things +/- 10 ns or even +/- 100 ns.
>>>>> Sometimes a “lower power” MCU with simple code is better at this than a
>>>>> multi core gizmo running a high level operating system.
>>>> Some of the counter/timer hardware has another register where the
>>>> will save a copy of the main counter when another signal happens. If
>>>> gate time is the time between two pulses rather than the width of a
>>>> pulse, then all the software has to do is read that copy-register before
>>>> next pulse happens.
>>> Works a bit better if the input is edge sensing rather than level sensing
>>> (copy on positive edge vs keep copying the whole time the input is high)
>> They are in my experience. You get the choice of positive edge, negative
>> edge and if you're lucky, both. I used the capture feature on PIC timers
>> back in the late 90s to capture automotive engine timing signals and log
>> engine timing etc., but that's another story.
>> But the big gotcha is that the external signal is going to be synchronized
>> to an internal clock, often by a couple of D flip-flops. This introduces a
>> delay of two to three internal clocks (it can be three if the D flip-flop
>> setup or hold time is violated and the first flip-flop goes metastable).
>> It was looking for where/how the synchronization was done on the STM32
>> timers that led me to the application note (AN4776) that I posted earlier.
>> FWIW, it's equally entertaining to work out when a write to a pin that's
>> designated as output actually appears on the pin. Immediately (subject to
>> propagation delays) never seems to be the answer for the ARM based chips
>> I've asked about. The answers tend to be of the form mumble mumble
>> pipelining mumble mumble…
> This is also is what gets you into limitations like the input clock to the timer being
> no greater than 1/4 the applicable MCU clock. The other key there being that the
> clock they use may be the I/O clock at 50 MHz and not the CPU clock at 200
> MHz. Indeed the information on this sort of thing may be 900 pages into a
> 1200 page document ….
> I’m not trying to say that I *know* this is the case on the F7’s. It is stuff I’ve run
> into on other ARM parts. It’s never easy to dig into. My take away has always
> been that for precision / deterministic stuff, go to a FPGA. Something like the
> FPGA / ARM combo’s might work. The cost for them always seems a bit
> crazy unless you need a *lot* of ARM <-> FPGA I/O horsepower.
It might be faster to just try some experiments. You could probably set
up an experiment with a signal generator or oscillator with a bit of an
offset so the zero crossing of the unknown slides across the phase of
the processor clock. Not to say that you'd uncover obscure corner
cases, but it *might* be easier than reading the 1000s of pages and
jumping back and forth in the doc between the description of the
"counter timer core" and the "clock distribution core" and the
"processor instruction timing" and the "input output multiplexer" and
the (well, you get the idea). I find that rummaging on the web for
some example code, getting it working, then modifying it seems to be a
good way - coming up with how to set all those configuration bits in
countless registers from scratch is a chore - some sort of starting
place is a good thing.
More information about the time-nuts