[time-nuts] Frequency counter questions

[Bob kb8tq]

Hi
> On Apr 25, 2017, at 8:53 AM, jimlux <jimlux at earthlink.net> wrote:
> 
> On 4/25/17 4:42 AM, Bob kb8tq wrote:
>> Hi
>> 
>>> 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:
>>> 
>>>> Hi
>>>> 
>>>> 
>>>>> 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
>>>> you
>>>>>> want the STM to do the whole thing, the “gate” pin needs to get the job
>>>> done
>>>>>> in  X +/-  1 cycles of the “signal” pin. Delay X (if it’s consistent)
>>>> isn’t
>>>>>> a problem. Having a
>>>>>> +/- 1 cycle delay *is* a problem. The interrupt servicing structure in
>>>> the
>>>>>> 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
>>>> hardware
>>>>> will save a copy of the main counter when another signal happens.  If
>>>> your
>>>>> gate time is the time between two pulses rather than the width of a
>>>> single
>>>>> pulse, then all the software has to do is read that copy-register before
>>>> the
>>>>> 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.

Indeed the whole process of rummaging through a massive pile of docs on a cheap little part can be 
a major hassle. You often do better running their “configuration wizard” and just trying out the result. 
I’ve even run into cases where the wizard knows more about the part than the doc's do. When I go back
with questions, the answer is often “trust the wizard, ignore the doc’s”. That makes you feel really good
about spending a week digging through all that stuff …..

Regardless of how you do it, if the objective is an instrument you trust, there is no easy shortcut way
to get it all done. The corner cases will always pop up and get you down the road. If it’s a learning 
experiment to see what happens … go for it. 

Bob


> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.