[time-nuts] Frequency counter questions
kb8tq at n1k.org
Tue Apr 25 07:42:50 EDT 2017
> 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.
> 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.
More information about the time-nuts