Using Counter blocks for Reciproal Frequency Counter
jmg
Posts: 15,172
Some questions on the Counter blocks, and the limits.
(AN0001 is sparse on other uses.)
Q: How does the Propellor II Counter differ from the Propellor ?
[noparse][[/noparse]Presumably it has a higher PLL max & Fi MAX - any other differences/enhancements planned ? ]
Q: In designing a reciprocal Frequenct Counter, you commonly need
TWO counters coupled together. One divides the Fi to a nominal timebase,
(might be ~100ms, or ~1sec), and the edges from this, are used to
capture a free-running Timer.
Frequency is then : CyclesDivided byCounterA/TimeDiffCounterB
Some range-find step may be needed, to first decide the appx ip Freq
Q: Can such a connection be done, with the Counter modules ? :
ie
- Divide a Pin by N (or 2^N is ok) [noparse][[/noparse]To what Max Pin frequency ?]
- Trigger a capture of another high MHz clocked Timer, from that counter output
- It might also clear the Timer, on Capture,
Q: what edge jitter is on the PLL multipliers ?
An ideal system will not lose edges, or time-ticks, and so allow more extended
precision over a longer time-base. - so a system refreshing at 100ms, can
also do a valid 10 second, or 100 second calculation, to give more digits of
precision.
(AN0001 is sparse on other uses.)
Q: How does the Propellor II Counter differ from the Propellor ?
[noparse][[/noparse]Presumably it has a higher PLL max & Fi MAX - any other differences/enhancements planned ? ]
Q: In designing a reciprocal Frequenct Counter, you commonly need
TWO counters coupled together. One divides the Fi to a nominal timebase,
(might be ~100ms, or ~1sec), and the edges from this, are used to
capture a free-running Timer.
Frequency is then : CyclesDivided byCounterA/TimeDiffCounterB
Some range-find step may be needed, to first decide the appx ip Freq
Q: Can such a connection be done, with the Counter modules ? :
ie
- Divide a Pin by N (or 2^N is ok) [noparse][[/noparse]To what Max Pin frequency ?]
- Trigger a capture of another high MHz clocked Timer, from that counter output
- It might also clear the Timer, on Capture,
Q: what edge jitter is on the PLL multipliers ?
An ideal system will not lose edges, or time-ticks, and so allow more extended
precision over a longer time-base. - so a system refreshing at 100ms, can
also do a valid 10 second, or 100 second calculation, to give more digits of
precision.
Comments
The counters cannot be directly coupled. What is intended is that a program can monitor one counter and, when triggered programmatically, can do something with the other counter. The program is deterministic and high speed, so you can compensate for the time it takes to react to the one counter. CNT is a free running 32 bit counter run off the system clock (normally 80MHz) and can easily be used to time other things. Most instructions execute in 50ns with an 80MHz system clock and you can check a counter for zero and react to it within one instruction·to capture the system clock (TJNZ to self takes 50ns when successful, 100ns when the test fails). You'd adjust the captured value to compensate for any additional instructions needed and reset the counter for the next event, possibly adjusting the initial count also to compensate for additional instructions. Since the execution time of the routine is deterministic, you can compensate for it.
Post Edited (Mike Green) : 1/9/2009 1:36:03 AM GMT
If it needs SW-assist, the polling loop time will define the time-granuarity,
and a coarser timebase, is fewer bits-per-second of
resolution.
Perhaps it is not too late to 'fix' the Propellor II ? [noparse];)[/noparse]
The Prop II will have a polling loop time on the order of 12.5ns (160MHz clock & pipelined one instruction per clock cycle)
a timer clocking at that speed.
The PLL in the Prop II is likely to be faster again... ?
Reading both AN001 and data sheet, it looks almost do-able ?
Data says "Each counter module can control or monitor up to two I/O pins "
So, if we used BPIN as a Fin source, in FreqGenerate mode, and output
that divided frequency to APIN, which can then be edge-captured from a fast-clocked timer.
(80MHz on Prop I)
It would be a 2 pin solution, but that's likely to be tolerable.
Less clear, is if you are allowed to clock counters from BPIN, in FreqGen mode.
No examples show this as a clock source, they all use SYSCLK
Examples do show edge capture from APIN, and nothing to say it cannot
be driven from the chip, whilst capturing.
I think the inability of the Divider to clock from BPIN is what trips us up ?
(Might be fixed in Prop II ? )
Post Edited (jmg) : 1/9/2009 5:05:35 AM GMT
-Phil
Perhaps this blind-spot will be fixed in Prop II ? (if it is not already too late...)
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/9/2009 10:34:20 PM GMT
and a nearly constant precision, in digits per second.
As this is a building block / instrumentation use, frequency range target is as wide as possible (ideally only silicon
limited). > 100MHz is a nice sounding round number !
We can get a two-chip solution, using an Analog Devices ADF4xxx series Synthesiser
[noparse][[/noparse]these have a nice test mode, where you can bring either divider chain, out to a pin.]
- but we need a ADF4xx per Fin channel, so for multiple channels, it sort of runs away on us.
The division range is 1..2^N, but can be tolerated as binary steps.
Like a voltmeter, it does need a range-decide step, to get the best precision.
Also on the wish-list is precision phase measurement (can be over many cycles)
For that I think we need a time-difference totalised over many cycles, and the
total time, totalised over the same many cycles. Phase is then Td/Tt
There, I suspect Edge-detect is ONLY on APIN, and there is no mention of A-B edge...
-Phil
another timer overflow (fixed gate time) .
I do not see an external-clock pathway to the Prop I counters ? (perhaps on Prop II?)
-Phil
solution ? With a SW edge following/counting.
I cannot see a way to edge count an external signal, with periodic capture, in HW alone ?
"In hardware alone" means something a lot different on the Propeller than on a single-processor micro. That's because a single cog, with its counters and other resources, along with software, can substitute effectively for a more traditional hardware peripheral. Here's an example that counts edges for one second, yielding a frequency in Hertz:
[b]CON[/b] [b]_clkmode[/b] = [b]xtal1[/b] + [b]pll16x[/b] [b]_xinfreq[/b] = 5_000_000 HOME = 1 INPPIN = 7 [b]VAR[/b] [b]long[/b] count [b]OBJ[/b] tv : "tv_wtext" [b]PUB[/b] main tv.start(12) one_second := clkfreq [b]cognew[/b](@counter, @count) [b]repeat[/b] tv.out(HOME) tv.decn(count, 10) [b]DAT[/b] [b]org[/b] 0 counter [b]mov[/b] [b]ctra[/b],[b]ctra[/b]0 'Set up CTRA to count positive edges on INPPIN. [b]mov[/b] [b]frqa[/b],#1 'Count up by 1 for each edge. [b]mov[/b] time,[b]cnt[/b] 'Initialize time. [b]add[/b] time,one_second 'Add one second. :countlp [b]mov[/b] prev_cnt,curr_cnt 'Save curr_cnt in prev_cnt. [b]waitcnt[/b] time,one_second 'Wait another second. [b]mov[/b] curr_cnt,[b]phsa[/b] 'Read the counter. [b]sub[/b] prev_cnt,curr_cnt 'Find the count difference. [b]neg[/b] prev_cnt,prev_cnt [b]wrlong[/b] prev_cnt,[b]par[/b] 'Write it to the hub. [b]jmp[/b] #:countlp 'Back for another. [b]ctra[/b]0 [b]long[/b] %01010 << 26 | INPPIN 'Mode = "pos edge"; ina = INPPIN. one_second [b]long[/b] 0-0 'Number of clocks for one second. curr_cnt [b]long[/b] 0 time [b]res[/b] 1 prev_cnt [b]res[/b] 1I drove this code with a (nominal) 4MHz TTL oscillator and got a one-count bobble between 4,000,056 and 4,000,057.
-Phil
Addendum: The accuracy of such a frequency counter is dependent, of course, upon the accuracy of the processor clock. In your app, you will probably want to drive the XI pin with a precision TCXO.
Post Edited (Phil Pilgrim (PhiPi)) : 1/10/2009 3:33:11 AM GMT
Appx 14ppm is not too bad between two generic parts.
I guess with SYSCLK of 80MHz, this has a max of 40MHz count , as it needs to
sample the edges of APIN (one hi, one low)
- but at lower freqs the digits/second rather degrades....
With no deadtimes (no missing edges), you could run this at 100ms, and do a 10sec, (or 100sec)
background calculation, for extended precisions ?
My maths says 40MHz fits inside 32 bits, up to 107.37 seconds.
Here's a program that measures period and converts to frequency for display. With an 80MHz clock, it should work reliably a little beyond 1MHz, with 12.5ns precision:
[b]CON[/b] [b]_clkmode[/b] = [b]xtal1[/b] + [b]pll16x[/b] [b]_xinfreq[/b] = 5_000_000 HOME = 1 INPPIN = 7 [b]VAR[/b] [b]long[/b] count [b]OBJ[/b] tv : "tv_wtext" [b]PUB[/b] main tv.start(12) [b]cognew[/b](@counter, @count) [b]repeat[/b] tv.out(HOME) [b]waitcnt[/b](clkfreq + [b]cnt[/b]) tv.decn(clkfreq / count, 10) [b]DAT[/b] [b]org[/b] 0 counter [b]waitpeq[/b] zero,pinmask [b]waitpne[/b] zero,pinmask [b]mov[/b] curr_cnt,[b]cnt[/b] :countlp [b]neg[/b] prev_cnt,curr_cnt [b]waitpeq[/b] zero,pinmask [b]waitpne[/b] zero,pinmask [b]mov[/b] curr_cnt,[b]cnt[/b] [b]add[/b] prev_cnt,curr_cnt [b]wrlong[/b] prev_cnt,[b]par[/b] [b]jmp[/b] #:countlp zero [b]long[/b] 0 curr_cnt [b]long[/b] 0 pinmask [b]long[/b] 1 << INPPIN prev_cnt [b]res[/b] 1A realistic threshold for switching from period measurement to frequency counting is probably around 1MHz. I tried this with a 2MHz oscillator divided by two and got a consistent reading of 1,000,000.
-Phil
If you really need 100 MHz capture, look at the XMOS controller. It costs more than the Propeller and uses lots more power, though. An FPGA is another option.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/10/2009 4:32:09 AM GMT
Further testing with the period measurement also revelaed a ±1 count (±12.5ns) bobble. This translates to a 1.25% frequency error when measuring a single period at 1MHz. So you will definitely want to measure more cycles at this frequency.
-Phil
Addendum: For measuring frequencies beyond 40MHz, there's nothing wrong with adding an external prescalar. It would be a lot easier and cheaper than going to an XMOS or FPGA.
Post Edited (Phil Pilgrim (PhiPi)) : 1/10/2009 4:45:50 AM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
and gets worse for multiple channels.
What we really want, is a smarter Counter block, with more clocking and capture choices.
Perhaps in Prop II ?
We have found the Analog Devices ADF4xxx series Synthesisers, can be used as nice
prescalers, and they are reasonably easy to source.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Why do you need something as complcated as an ADF4xxx? To accommodate a 100MHz signal with the Prop I, you have only to divide by 4. A 74LVC2G80 can do this at up to 160MHz for only 16 cents (quan. 1000) per channel with a minuscule footprint.
-Phil
74LVC2G80 is rather hard-wired, and so locks-in a fixed division.
(it also lacks a pre-amp, which is a nice 'for-free' feature of the ADF4xxx)
Just seems a pity to have to band-aid around what is largely a nice 32 bit counter,
for want of some simple, but omitted, logic pathways.
I've certainly bumped up against several limitations of the current chip, but then I'm trying to make it do things that probably never even crossed the collective minds of the responsible parties. I sure have a hell of a lot of fun _trying_ to shoe-horn it in though!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I agree with Brad: there are necessary limits to what any one chip can do. The Propeller has a nicely-rounded set of capabilities; but for any particular task, some augmentation may be required. That's life. The fun part is figuring out the minimal solution to a problem.
-Phil
If no one bothers to document what a part CANNOT (but should) do,
then devices would never improve!!.
Sure, we have to make what we want, from what we can get, but part
of that process, is to also feed-back, what would be better....
Many uC devices DO allow clocking, and capture, from external pins, and the Logic
needed to do so is quite minimal.
Fewer allow cross-couple of counters, but chip designers are becoming more aware that is
also a useful feature.
A couple of designs I have done, we output to a pin, and cross-coupled counters that way.
My experience with the Propeller indicates that it requires a new way of thinking about the line between hardware and software. Just because a certain function is not hard-wired into the silicon does not mean that the capability is missing. The clock functions that you mention as lacking in the Propeller's hardware can be made up in "software". But in the Propeller, software can be more akin to microcoding than to programming in the sense we traditionally think of it. One reason so many of these functions are hardwired into simpler controllers is that, with a single CPU, there simply isn't time to perform them in software. In a sense, such controllers are multiprocessors in their own right, except that each processor (excepting the CPU) performs a single function. In the Propeller, this distinction between various processor capabilities has been stripped away, leaving us with more of an empty stage upon which to perform its magic.
It's taken me awhile to come to this way of thinking. When I first encountered the Propeller, I, too, was a little taken aback by the dearth of hard-wired peripherals, being more accustomed to those available in PICs, for example. But I've come 'round to realize that, rather than being handed a fixed set of tools, we've been given the tools to make our own tools. It's very emancipating.
The Prop I has 32 counter modes defined by five "mode" bits in the CTRx registers. There is room in the I-field for six bits. Perhaps there simply wasn't room in the silicon for 32 more modes. One has to draw the line somewhere. Even then, the counters are an extremely capable resource, and I'm constantly amazed at the different ways they can be coerced to do things they probably weren't designed for. I think we can look forward to even greater things with the Prop II. But it will come along well before I run out of new tricks for the Prop I to perform!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 1/10/2009 10:56:48 PM GMT
a) Allow a Both edges mode
b) Allow MSB and Carry to drive the pin, in more modes (not just NCO mode)
c) Allow Counter capture from a pin-event, not just from SW
d) add some Phase modes to the Logic
a) b) and d) have quite low silicon cost
c) may require a 32 bit holding register, still relatively low cost.