Re: [time-nuts] Frequency counter questions
kb8tq@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.
--
These are my opinions. I hate spam.
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@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)
Bob
--
These are my opinions. I hate spam.
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.
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@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...
Orin.
Hi
On Apr 25, 2017, at 1:24 AM, Orin Eman orin.eman@gmail.com wrote:
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@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.
Bob
Orin.
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.
On 4/25/17 4:42 AM, Bob kb8tq wrote:
Hi
On Apr 25, 2017, at 1:24 AM, Orin Eman orin.eman@gmail.com wrote:
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@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.
Hi
On Apr 25, 2017, at 8:53 AM, jimlux jimlux@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@gmail.com wrote:
On Mon, Apr 24, 2017 at 5:16 PM, Bob kb8tq kb8tq@n1k.org wrote:
Hi
On Apr 24, 2017, at 6:54 PM, Hal Murray hmurray@megapathdsl.net wrote:
kb8tq@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
So the STM App note An-4776 teaches how to use an external clock and it looks pretty accurate in implementation. I’ve read thru the code and it looks easy to implement. Now I just need to bring another signal in and count it. I’ll be working on some code this afternoon to implement the method.
I also found a 5335 for cheap and ordered it. It was listed on eBay as being in “excellent” condition though both pictures had all the lights lit so I can only assume it is stuck in power on reset or test. I’ll see when it gets here.
As far as measurement techniques, if I use my scope and sync to a known signal using the trigger on my 3336, it looks like I can measure to .001hz pretty reliably. So using the STM application, the 5335 and the scope + 3336, I should be off and running.
I’ll report back in a few days.
Jerry
Hi
Keep in mind the previously stated limitation - Your GPSDO is only just
so accurate. If you could read 0.001 Hz on a 100 MHz signal in a second,
the GPSDO would not be anywhere near good enough as a reference. Keeping
track of that sort of stuff is one reason a lot of companies train you very early
in converting everything to PPM / PPB / PPT rather than talking about Hz. It’s
a lot easier to note that 1 ppt is past what a GPSDO will do at 1 second than
listing out all the various fractional Hz / MHz signals that are at the limit.
——
The main weak point on the 5335 is the input circuit. With the attenuator set
to 0 db, you can fry it with a 5V signal. Back when it was new and 5V TTL
was all over the place, it was a major risk. Today it’s less of a risk, but still
worth being aware of. An accidental connection to +12 is also a good way
to nuke it ….With the attenuator set as you normally would for a 5V or 12V
signal there really isn’t much risk.
Bob
On Apr 25, 2017, at 2:41 PM, Jerry Hancock jerry@hanler.com wrote:
So the STM App note An-4776 teaches how to use an external clock and it looks pretty accurate in implementation. I’ve read thru the code and it looks easy to implement. Now I just need to bring another signal in and count it. I’ll be working on some code this afternoon to implement the method.
I also found a 5335 for cheap and ordered it. It was listed on eBay as being in “excellent” condition though both pictures had all the lights lit so I can only assume it is stuck in power on reset or test. I’ll see when it gets here.
As far as measurement techniques, if I use my scope and sync to a known signal using the trigger on my 3336, it looks like I can measure to .001hz pretty reliably. So using the STM application, the 5335 and the scope + 3336, I should be off and running.
I’ll report back in a few days.
Jerry
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.
Do typical frequency counters start their gate in phase with the incoming signal? I guess the
answer would be, "It depends." I was just thinking about how I would program the STM32F7
counter I am designing.
btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
out of the two I will have.
Jerry
Hi,
On 04/26/2017 06:29 AM, Jerry Hancock wrote:
Do typical frequency counters start their gate in phase with the incoming signal? I guess the
answer would be, "It depends." I was just thinking about how I would program the STM32F7
counter I am designing.
No. The start of the gate arms the "start" event where you time-stamp
the start event. The end of the gate arms the "stop" event. Variation
can be that you start counting the gate time and arm it with a start
event. Typically the internal gate time is counted in the coarse clock,
so the time-resolution as given by interpolators always guarantee that
the wished gate-time and actual gate time is never really the same.
Rather, gate time is a guidance value but you then measure the actual
length, and neither start or stop is on the same edge.
btw, Gilbert, a local time-nut, sold me a 5335 today so I will be able to buiild one great one
out of the two I will have.
Not a bad first counter. It still does some tricks that none of my other
counters do, and I kind of have a bunch of them by now.
Cheers,
Magnus