PDA

View Full Version : Using Counter blocks for Reciproal Frequency Counter



jmg
01-09-2009, 08:37 AM
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 ?
[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) [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.

Mike Green
01-09-2009, 09:30 AM
The Prop II is still under development, none of its features are publicly defined in detail, and anything is subject to change.

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

jmg
01-09-2009, 10:15 AM
Thanks. Not as good as I had hoped...
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 ? ;)

Mike Green
01-09-2009, 10:31 AM
The polling loop time is 100ns. What kind of timebase were you hoping for?

The Prop II will have a polling loop time on the order of 12.5ns (160MHz clock & pipelined one instruction per clock cycle)

jmg
01-09-2009, 10:38 AM
Given that the Prop. mentions a 128Mhz PLL clock, I was hoping to be able to capture from
a timer clocking at that speed.

The PLL in the Prop II is likely to be faster again... ?

kwinn
01-09-2009, 11:38 AM
Please feel free to correct me if I am wrong, but it sounds as if you are trying to measure the pulse to pulse period. If that is the case then you can use the PLL clock to increment a counter at 128MHz for a granularity of 7.8125 nSec. If you want greater accuracy you could count for multiple pulse periods.

jmg
01-09-2009, 12:12 PM
Close - we do need to capture an edge, but one that has been divided by N.

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 Pilgrim (PhiPi)
01-10-2009, 02:52 AM
Unfortunately, the counters cannot be used to output a divided external frequency source without software assistance. The PLL and NCO modes can output a divided system clock, but not a divided input clock. The modes that accept inputs don't provide a divided output, only negative feedback from the input.

-Phil

jmg
01-10-2009, 06:20 AM
Thanks, rather what I suspected, but not what I hoped.... ( Bummer... :( )
Perhaps this blind-spot will be fixed in Prop II ? (if it is not already too late...)

Phil Pilgrim (PhiPi)
01-10-2009, 06:28 AM
Just out of curiosity, what is your input frequency range? What were you wanting to divide it by? What is your ultimate objective?

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 1/9/2009 10:34:20 PM GMT

jmg
01-10-2009, 06:56 AM
The objective is to construct a reciprocal frequency counter, described above, which has a wide dynamic range
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
[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 Pilgrim (PhiPi)
01-10-2009, 07:02 AM
As the frequency surpasses 1MHz or so, how important is the reciprocal measurement? Could you attain the desired precision simply by counting edges during a fixed time interval? What I'm imagining is a frequency meter that shifts gears from one approach to another when the frequency passes a certain threshold.

-Phil

jmg
01-10-2009, 07:16 AM
Possibly, but that requies a counter that can accept clocking off a pin, and then capture from a
another timer overflow (fixed gate time) .

I do not see an external-clock pathway to the Prop I counters ? (perhaps on Prop II?)

Phil Pilgrim (PhiPi)
01-10-2009, 08:30 AM
jmg said...
Possibly, but that requies a counter that can accept clocking off a pin, and then capture from a
another timer overflow (fixed gate time) .

Not if it's software mediated. That why I inquired about only doing the inverse clock for lower frequencies. Even with a software loop, you can get high edge resolution, since you can program a counter to count only when the input is high (half-cycle), for example. A similar, but more convoluted, trick can also be applied for edge-to-edge (full-cycle) timing. But neither interval-timing method would work at 10MHz, say, where edge counting could be used instead.

-Phil

jmg
01-10-2009, 08:44 AM
I'm a little unclear - are you talking about a way to configure the counter, or a software
solution ? With a SW edge following/counting.

I cannot see a way to edge count an external signal, with periodic capture, in HW alone ?

Phil Pilgrim (PhiPi)
01-10-2009, 11:23 AM
jmg,

"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:




CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

HOME = 1
INPPIN = 7

VAR

long count

OBJ

tv : "tv_wtext"

PUB main

tv.start(12)
one_second := clkfreq
cognew(@counter, @count)
repeat
tv.out(HOME)
tv.decn(count, 10)

DAT

org 0
counter mov ctra,ctra0 'Set up CTRA to count positive edges on INPPIN.
mov frqa,#1 'Count up by 1 for each edge.
mov time,cnt 'Initialize time.
add time,one_second 'Add one second.

:countlp mov prev_cnt,curr_cnt 'Save curr_cnt in prev_cnt.
waitcnt time,one_second 'Wait another second.
mov curr_cnt,phsa 'Read the counter.
sub prev_cnt,curr_cnt 'Find the count difference.
neg prev_cnt,prev_cnt
wrlong prev_cnt,par 'Write it to the hub.
jmp #:countlp 'Back for another.

ctra0 long %01010 << 26 | INPPIN 'Mode = "pos edge"; ina = INPPIN.
one_second long 0-0 'Number of clocks for one second.
curr_cnt long 0

time res 1
prev_cnt res 1




I 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

jmg
01-10-2009, 11:52 AM
Thanks for the example & test report !.
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.

Phil Pilgrim (PhiPi)
01-10-2009, 12:21 PM
Sure, you could count over a longer period or do a running average over several shorter periods — however you want to filter the results. (BTW, the one-count bobble was with a single oscillator. You will almost always get a one-count bobble no matter how stable and precise your system is.)

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:




CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

HOME = 1
INPPIN = 7

VAR

long count

OBJ

tv : "tv_wtext"

PUB main

tv.start(12)
cognew(@counter, @count)
repeat
tv.out(HOME)
waitcnt(clkfreq + cnt)
tv.decn(clkfreq / count, 10)

DAT

org 0
counter waitpeq zero,pinmask
waitpne zero,pinmask
mov curr_cnt,cnt

:countlp neg prev_cnt,curr_cnt
waitpeq zero,pinmask
waitpne zero,pinmask
mov curr_cnt,cnt
add prev_cnt,curr_cnt
wrlong prev_cnt,par
jmp #:countlp

zero long 0
curr_cnt long 0
pinmask long 1 << INPPIN

prev_cnt res 1




A 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

Leon
01-10-2009, 12:25 PM
jmg

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

jmg
01-10-2009, 12:29 PM
(BTW, the one-count bobble was with a single oscillator. You will almost always get a one-count bobble no matter how stable and precise your system is.)
said...


From the code I thought you had a 5MHz Xtal, and x16 PLL, for the Prop,
and then a 4MHz module as the Test Freq ?.

(ie two oscillators), with a single osc, you should get a 0ppm error ?

Phil Pilgrim (PhiPi)
01-10-2009, 12:39 PM
Yes, a completely separate oscillator for the counter input. I wanted it to be a fair test, after all! http://forums.parallax.com/images/smilies/smile.gif

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
01-10-2009, 02:02 PM
I'm not sure if a prescaler will work for the OP's application.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

jmg
01-10-2009, 02:14 PM
A prescaler is workable, but is then no longer a single chip solution,
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
01-10-2009, 03:24 PM
You probably need to look at an XMOS chip or a CPLD or FPGA, then, if you really need a 100 MHz single-chip solution now, especially if you have several channels.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Phil Pilgrim (PhiPi)
01-10-2009, 03:34 PM
jmg said...
Perhaps in Prop II ?

Sure, but when do you want it?

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

jmg
01-10-2009, 04:59 PM
A CPLD is probably the best match for most targets. XMOS is rather an overkill, and BGA to boot.

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.

BradC
01-11-2009, 12:12 AM
You can't be all things to all people. Someone, somewhere is _always_ going to turn around and say "But I want it to work *this* way, and it can't!". I'm sure that in adding gates required to perform your desired function on the new chip, another feature or configuration will have to be left out. It's all about compromise really.

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.

Phil Pilgrim (PhiPi)
01-11-2009, 01:14 AM
jmg said...
74LVC2G80 is rather hard-wired, and so locks-in a fixed division.

Not necessarily. There's nothing to say you can't input the /1, /2 and /4 signals to separate Propeller pins and use software to pick which one to use.

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

jmg
01-11-2009, 05:47 AM
I can only partly agree.

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.

Phil Pilgrim (PhiPi)
01-11-2009, 06:50 AM
jmg,

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

jmg
01-11-2009, 07:47 AM
Here is a summary of extension ideas to the Counters, just in case it is early enough to catch Prop II

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.