On 4/25/17 4:42 AM, Bob kb8tq wrote:
Hi
On Apr 25, 2017, at 1:24 AM, Orin Eman <orin.e...@gmail.com> wrote:
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq <kb...@n1k.org> wrote:
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
kb...@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.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
